Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When merging a rebased feature branch, make sure to use merge --no-ff so that a merge commit is introduced even though fast forwarding could be done.


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.


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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: