4 ms·

Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that po

Merge commits stop being interesting when you have thousands of people working on a codebase and you have tens or hundreds of thousands of branches. At that point clean, linear history is much, much simpler to understand.

pseudalopex 8y ago
If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.
- cryptonector 8y ago
  Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.

pseudalopex 8y ago

If you mean a squashed history, I agree. At that scale I think the advantages outweigh the disadvantages.

cryptonector 8y ago
Not squashed, not exactly, more like: clean and linear. Linear means: no merge commits. Clean means that a sequence of commits like this: Add feature XYZ Fix bug I just found around that code Fix typos in XYZ Fix bug in XYZ Add tests for XYZ Fix another bug I found around that code Fix bug in XYZ fixup! Add feature XYZ fixup! Fix bug I just found around that code becomes: Fix bug ... (not related to XYZ) Fix second bug ... (not related to XYZ) Add feature XYZ You would do this by doing something like `git rebase --autosquash origin/master`, then `git rebase -i origin/master` to reorder the remaining commits as above. Reword the commits to add ticket IDs to the commit subjects for all of these, if you have this as a requirement or have an issue tracker. Force push your branch, do one last round of build, test, review, and push when all looks good (else rinse, repeat). Maybe you'll realize that XYZ is two features, not one, and then you might split that up into two commits (again, using `git rebase -i`, mark that commit for "edit", `git reset HEAD^`, `git add -e`, `git commit -m 'Feature WXY'`, then `git add`, then `git rebase --continue`. Some commits got squashed, maybe some got split, and all got reordered. The resulting history is easy to read. This takes a bit more work. But once you get into this workflow, it begins to become second nature, and you get good at it and it doesn't slow you down. The benefits are well worth the learning curve, and it's not that steep.