3 ms·
I've seen two main arguments to that workflow. One argument, and which I hear often, is that they want to keep the git history clean. The other argument is th
by mhitza 5y ago
I've seen two main arguments to that workflow.
One argument, and which I hear often, is that they want to keep the git history clean.
The other argument is that keeping things rebased & squashed allows you to do reverts easily.
I personally don't mind the merge commits cluttering the history, and especially when working on a longer lived branch I will always prefer merging-in changes rather than constantly rebasing and fixing same conflicts ad nauseam.
- altonen 5y agoIf you use git-rerere you don't have to fix the same conflicts over and over again
- unicornmama 5y agoYou can do reverts just as easy with merge commits. git revert -m 1 $commit You can also visualize a clean history with merge commits. git log —-first-parent The only argument I’ve heard that holds weight is that GitHub’s UI squashes the merge commit history into a linear view.