Quote:
Originally Posted by OmgGlutten!
a mistake people make on git is when they rebase off master and master has a bunch of merge conflicts with the code they have written, they should first squash all of their commits on their branch before rebasing/merging into master otherwise they could end up in a situation where they have to deal with merge conflicts for twenty different commits, which could take all day.
I believe commits should document granular changes. If your feature branch requires 4 changes, it should be spread out among 4 commits.
If you have organized commits, then you shouldn't have merge conflict nightmares (no worse than 1 squashed commit). For example, I see a lot of people do this:
commit 1: Add x
commit 2: blah
commit 3: Undo x or replace it with y
In reality, commit 1 should be amended with 3 or vice versa. Otherwise, yes, this can potentially generate 2 conflicts when rebased.