Skip to content

Instantly share code, notes, and snippets.

@pavelfomin

pavelfomin/git-merge-vs-squash.md

Last active February 14, 2024 16:50
Show Gist options
  • Save pavelfomin/1048c1a39e6805aefed5b14d9a71bdf0 to your computer and use it in GitHub Desktop.
Save pavelfomin/1048c1a39e6805aefed5b14d9a71bdf0 to your computer and use it in GitHub Desktop.
Download ZIP
Advantages of using merge instead of squash in Git
Raw
git-merge-vs-squash.md

Advantages of using merge instead of squash for PRs:

  • if there is a chain of PRs, with PR1 (feature1 -> main) and PR2 (feature2 -> feature1) then when PR1 is merged, PR2's base is automatically adjusted to main (GitHub). I do not believe this will happen with a squash.
  • ability to check if the commits from other branches have been merged to main (using git branch -r --no-merge) which is especially useful for release/* deployment strategies if a file was first renamed and then modified in more than one commit (recommended approach for git to retain history), if these commits are merged then the history is retained. Otherwise, if squashed, git might consider the rename and update as old file deletion and new file addition (depending of the percentage of the changes).
  • If there are commits that logically address separate issues it's easier to understand such changes as individual commits in history rather than squashed result

However, there is definitely a case for squashing PRs when individual commits do not provide extra value and just create more "noise".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment