Things I know about Git commits

Original Article ↗ Hacker News Discussion ↗

Value of Commit History and Messages

  • Many see rich history and good messages as a “superpower”: essential for git blame, file history, understanding why code exists, and tracking down bugs.
  • Others barely use history, treating Git mainly as backup/collaboration. This is criticized as wasting Git’s capabilities and making future archaeology harder.
  • Minimal messages like “Fixes #12345” are widely disliked; they force dependence on external trackers. Some argue referencing a well-written ticket is acceptable, but others insist the log should stand on its own, especially across tool migrations or outages.
  • Commit history can partially substitute for formal documentation, though relying on it as the sole source is debated.

Atomic Commits, Squash Merging, and Review Strategy

  • “Atomic” is interpreted as each commit doing one meaningful, complete thing (including tests), and every commit on main being green.
  • Suggested workflow for bug fixes: first add a test that passes on current behavior, then a commit that changes the test and code to reflect the fix; the diff between those clarifies behavioral change.
  • Some push for separating refactors from feature/fix commits so reviewers can follow a narrative; PRs should “tell a story.”
  • There’s disagreement on squash merges:
    • Pro: cleans up “100 crap commits” into one atomic change.
    • Con: can break submodules, harms git bisect, and loses intermediate reasoning.
  • Debate over merge strategies: some prefer no merge commits (rebase + fast‑forward only); others want merge commits preserved to keep small, reviewable commits while still grouping features.

reflog, GC, and Recovering from Mistakes

  • git reflog is praised as the primary safety net for undoing bad rebases, resets, and other history edits; with it, people feel safe rewriting aggressively.
  • Some recommend disabling reflog expiration or automatic git gc to avoid losing recoverable commits; others suggest just extending reflog lifetime instead.
  • A few report rarely needing reflog, relying instead on habits like creating temporary branches or including commit hashes in the shell prompt.

Git Complexity, Education, and Tooling

  • Strong split: some argue developers should invest time to really learn Git; others say fixing “fucked” repos isn’t worth hours and just reclone.
  • Several criticize Git as overly complex and user‑hostile, with too many workflows and configurations; defenders say its power and ubiquity justify the learning curve.
  • GUI tools (e.g., TortoiseGit, magit, Lazygit, IDE integrations) are praised for making complex operations like interactive rebase, partial staging, and diff review more approachable.
  • Tips mentioned: git add -p plus --intent-to-add for new files, git log -L for function history, commit/message wizards, and Git helpers like GitFixUm and git‑extras.