[frou_dh]

Yeah. I like that and the approach is outlined in this short guide I found:

http://williamdurand.fr/2012/01/17/my-git-branching-model/

i.e. before merging a feature branch, always rebase it on the tip of the integration branch, then merge it in with --no-ff to record an explicit merge commit on the integration branch, even though a fast-forward is possible. This gets you the temporal straightforwardness of rebase while preserving the fact that there WERE feature branches and their commits are partitioned in history.

[khasinski]

You nailed it. Commit history is for people to read.

Check out git flow, you might like it. It could add even more structure and readability to your codebase history.

[frou_dh]

Do you agree with my edit? I'm no git pro, so still trying to get things straight in my mind.

[khasinski]

Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this branch or remove the entire feature.