merge commits better than squash commits

todo: update date when written out

people use squash commits and rebases because they want their commit history to be clean. is this just for vanity?

merge commits are better:

• more granular blames
  • see both the commit level context (eg formatting or a bug fix) and PR
    • it is not helpful to see “feat: add xyz feature” next to a line in a file that seemingly has nothing to do with the feature
    • i would rather see “format” so i know to just click view previous instead of investigating the commit
    • if it’s just “fix bug” then i have the option to go to the commit page and click on the PR link
  • GitHub links to PR that commit is part of
  • while PRs should be small, they are not always so in practice
    • especially in the earliest PRs of the repo when the project starts out, since that’s where
  • from experience at ACM and internship
  • if you rename and rewrite a file i believe keeping the granular commits allows GitHub to track where the previous file history was / include it in the blame (while squashing will turn it into a delete + add)
• why squash commits on feature branches into main?
• easier to split PR into multiple steps and merge upstream PRs into later PRs without conflicts

only benefit of squash commits is to keep .git folder small (eg if you accidentally commit node modules in a PR then delete it)

looking online, the benefits of squash commits are:

• if you want to assume every commit builds / use git bisect, then squashing avoids broken intermediate wip commits
  • bisect is valid
  • for the former you could just only consider merge commits to main
    • can also use a commit message convention or pre commit hooks

should limit argument to just GitHub interface rather than git CLI (because GitHub shows PR info on hover)

• arguably GitHub PR metadata is just as part of the repo history as the commits because PR discussion
• issue numbers don’t work well in the terminal either

when do people look at commit history? is there research on this

PRs should be small. but in practice for one reason or another some PRs end up very big (are there statistics on this)

do people use bisect or blame? can’t bisect on GitHub but blame is harder to use in git i guess

---

particularly relevant since LLMs can generate massive PRs that should be split up

---

git and github are made for merge commits. rebases and squash merges are a hack for people who care superficially about a “clean git history” as if anyone’s actually looking at it

why people use squash commits

• easy to view high level overview of changes via merged PR titles

  • valid, github UI can’t do this (outside of network view)
  • but can use CLI git log --first-parent or better git UI
  • can configure default merge message to be PR title in github repo settings

• easy to undo a damaging PR

  • github has a button for generating a PR revert
  • in git: git revert -m 1 HEAD~1

why squash bad:

• git blame is less useful
  • can see associated PR of a commit on github
• hard to split large PRs
• granularity when feature branch is merged

why rebase bad:

• git is not intended for rebases; the UX is bad. theirs/ours is flipped; you’d never encounter this if you stick with merge commits
• force pushing breaks github “changes since last review” button

the only valid scenario for squash commits is for public open source repos where collaborators may sneak in diffs in intermediate commits. but for repos within a team (e.g. in a company) this is not a concern