3 ms·
The idea that fast-forward merges are easier to follow is subjective. I find my --no-ff history easier to read. This author doesn't. What always using fast-for
by decklin 15y ago
The idea that fast-forward merges are easier to follow is subjective. I find my --no-ff history easier to read. This author doesn't.
What always using fast-forward merges really means is that you rebase each branch onto master once it's ready to be public. Therefore, instead of resolving conflicts when the branch is merged, the commits are rewritten to avoid introducing the conflict in the first place.
Sometimes, this is really simple -- I added a line in one spot, you added another line in the same spot, you merged first, so I rewrite my commit to add my line next to yours instead of merging and resolving the conflict. Sometimes, it's not -- maybe there's not even any text-level conflict, but your feature and my feature interact in subtle and unanticipated ways and something breaks. Now, there's no "good" point in my branch to refer to, because I rewrote it on top of something where (I didn't realize) it was never really going to work. The unit test I now need couldn't have existed because it involves things that, when I was developing the branch, didn't exist.
Rebasing first is trading off when you do that work. There's more to review when the branch is ready, and there's a stronger incentive to get it right the first time. I think this may work better for the "two founders deploying from master when they feel like it" scenario -- you pay for manageability with context switches. If you have a formal QA process, I think being able to distinguish between "this branch failed QA" and "the combination of these branches failed" may be more helpful -- you can parallelize work and hack on a different private branch.
Git, thankfully, does not force us to choose one model or the other :-)
- sandofsky 15y agoIn my experience, on large distributed projects the person integrating changes into master is rarely the same person who authored the change. For example, when Linux branches are pulled upstream, if your code creates a conflict your branch will just be rejected and you'll be told to fix. Rebase forces the author to solve more of these problems before submitting their change for integration. I don't think rebase is an end-all solution for the reasons you've described. It's perfect for medium sized changes you can easily verify afterwards. My day-to-day work usually falls into this category. In the case of larger sets of all-or-none changes, such as a site redesign, it makes perfect sense to maintain a parallel line of development. Cleanup probably isn't worth it, and the separate branch serves as documentation. You should consciously create a new public branch. In this case, I can understand wanting a "no-ff" merge for documentation. I think you should first consider tags, but sometimes it makes sense to set a stake in the ground with a placebo commit. The problem is that if you use "no-ff" all the time on trivial changes, then these branches lose meaning. This post wasn't supposed to be an embargo on "no-ff." My case is that people default to "no-ff" to pave over deeper issues.
- cpeterso 15y agoA --no-ff merge also makes reverting a change from master easier because there is just one commit. You don't need to dig through the log to find the first commit from the merged branch fast-forwarded onto master.
- fr0sty 15y agoDo you actually mean "revert" there or are you talking about rewinding? using "git revert <merge_commit>" is very nasty[1]. using 'git reset <before_bad_merge> is less so. [1]http://kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt http://kernel.org/pub/software/scm/git/docs/howto/revert-a-f...