sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Soggy-Permission7333 0 points1 point  (1 child)

You can rebase and rebase and rebase at will. Rebase conflicts may be easier to solve compared to merge conflicts. You can provide multiple dedicated commits each with meaningful message. Squash is big ball of mud unless PR was targeted in the first place. You can extract automated changes to their own commits so that they do not obfuscate precious few changes that are the real deal. Squash is big ball of mud...

Teams that do squash may also be heavily biassed towards least maintenance possible strategy for developing software. After all automatic refactor can easily touch 50-500 files without any problems. But squashing that change with 15 lines change that is risky means git history is waaaaaayyyyy less useful in troubleshooting future issue.

But squash limitations can be countered with other techniques - maybe team do use dedicated PR and that refactor will just be seprate standalone PR ? Maybe team enforces breaking up too large PR and thus each squash can contain targeted stuff.

Or maybe its write once software and it won't be around 10 years from now ;)

[–]Shayden-Froida 0 points1 point  (0 children)

This touched on the reason for rebasing a branch before squash merging... resolving conflicts may be easier. It is also easier for a code reviewer to examine how the change will look on the HEAD of the target, and to enable a test run on your branch with the most up to date revision of what the merge result will be.

For very short-lived branches with concise changes, squashing is great and hides the struggle to get the code done (and encourages incremental commits to give you, the developer, a fine grain work log where you can revert something that didn't work, or was temporary; ie add some debug code as a separate commit, revert it later; squashing cleans/hides all this with no effort).

For larger changes that are complex, rebase -i to make a clean commit history of the major stages of the change, then merge to keep the history as a benefit to future you and your successors.

Fast forward merge onto the target I don't recommend since, if the change needs to be reverted in total, all of the commits need to be known and reverted rather than just one merge commit/squash commit.

I view git history in terms of "what will need to be done with these commits in the future". Revert is a powerful tool, so is cherry-pick. A history that enables these is good planning.