Merging vs. Rebasing

Clean project history is overrated.<p>If you work on a sizeable team with code review before merge workflow, the tip of the repository will be moving faster than is pleasant or safe to rebase, and every so often, commits will exist in multiple different branches (in order to prevent blocking development pending a code review). You do not want to be rebasing commits such that they appear in multiple different branches with different hashes etc. It&#x27;s a recipe for pain. And being blocked until code is reviewed and merged is hardly more productive.<p>Even working like this, git bisect works just as well to find a commit, and git log on an individual file works just as poorly as it always does (e.g. changes in merge conflict resolution are hidden by default).<p>Rebase if the commits only exist in your local repo. That&#x27;s fine. But no more.

Rebasing isn&#x27;t just about a clean project history, IMO. I&#x27;d much rather find out about a merge conflict I&#x27;ve created when applying a small commit to the tip of master, than when smashing two development histories together.

For our (smallish, fast moving) team we disabled history rewrites on all branches on the server, have all the developers manage their git workflow using the (very awesome) osx app called gitup, and have everybody rebase and resolve conflicts before pushing. We always rebase and only merge in unusual circumstances where preserving the merge conflict resolution decisions might make sense (which almost never occurs). Everybody on our team including very junior developers and designers are able to quickly pick up this workflow and almost never have problems - and when they do it&#x27;s always obvious that they should get help from someone -- and typically this is exactly the scenario where some analysis is needed -- so its a good use of time for a second pair of eyes.

Where I work we merge with the no fast forward option - this keeps an accurate git feature topology where merges are represented as their own commit. We&#x27;ve found it gives us the best of best worlds: adding clarity&#x2F;readability to the history while avoiding problematic rebases.<p>I haven&#x27;t personally really noticed any downsides with that approach, can anyone else think of any?

We&#x27;ve started using mercurial evolve at my company. It feels like the best of both worlds. I can rebase and get all the nice clean history I want, but under the hood the original work is still there. It also allows for safely editing public history, without getting into a weird state where you edited a commit that someone else committed on top of.

rebase for lyfe! Just don&#x27;t force push on master.

I quite like that this outlines the benefits of both non-judgementally, and provides guidelines about when to use each in different situations. I&#x27;ve seen too many discussions where people argue that one is better than the other, when as I see it, they are two different tools and they both have legitimate uses. There&#x27;s a little overlap, a few cases where your own preferences can allow you to choose freely, but by and large they don&#x27;t really contend with each other. You can largely have a clean and accurate history <i>and</i> a feature branch workflow with PRs, while using both rebasing and merging.

Did anyone else to the following when they were new to git and had to rebase? 1 - Rebase. If no conflicts, great! otherwise, 2 - Abort rebase and merge.<p>:-)<p>When I started using git I remembered feeling overwhelmed by rebase because with a merge you only resolved conflicts once, whereas with a rebase you had to continually fix conflicts without knowing when it would end.<p>It took me a while to finally understand how rebase properly worked and I can finally use it correctly now.

Note: if you want to bring upstream changes into your fork, as in [1], use a rebase instead of a merge. Otherwise, you will be fighting with merge commits from now on.<p>[1] <a href="https:&#x2F;&#x2F;help.github.com&#x2F;articles&#x2F;syncing-a-fork&#x2F;" rel="nofollow">https:&#x2F;&#x2F;help.github.com&#x2F;articles&#x2F;syncing-a-fork&#x2F;</a>

Not sure how I feel about the not rebasing PRs rule, especially with CI on PRs becoming more common. I&#x27;d much rather have a PR get rebased than have an extra &quot;Fix whitespace to satisfy linter&quot; commit.

This article has been written a million times already. It&#x27;s another holy war. Vim, spaces, rebase. The sad part is that IMO merge people are on that side because they are afraid of rebase or don&#x27;t understand it.