How to commit part of file in Git

Original Article ↗ Hacker News Discussion ↗

Splitting changes into small, focused Git commits is praised as vital for debugging, code review, and safe rollbacks, yet many developers either squash entire pull requests or bundle unrelated edits together. Commenters compare workflows that enforce atomic, always-green commits with those that favor one-commit-per-PR histories, and they debate the merits of command-line tools like `git add -p` versus GUIs and IDE integrations (VS Code, JetBrains, Magit, lazygit, etc.) for staging parts of files. Overall, the conversation highlights that mastering partial commits and thoughtful history shaping is a core but often neglected skill in professional software development.

Commit granularity & value of good history

  • Many argue that splitting changes into small, coherent commits is underrated and very useful, especially for debugging and reverting outages.
  • Others note that in practice some teams rarely revert specific commits; instead they roll back deployments or write a new “fix” commit.
  • There’s strong sentiment that crafting good commits (and learning Git well) is an underappreciated skill, tied to broader concerns about software quality vs “just ship it” productivity.

Squash vs incremental commits, and reverts

  • One camp prefers squash-merge per PR:
    • PR is the unit of review, not each intermediate commit.
    • Results in a linear, bisectable history without broken intermediate states.
    • Squashes help remove noisy “fix typo / actually works” commits and rewrite a single good message.
  • The opposing camp favors non-squashed, atomic commits:
    • Each commit should build and pass tests, easing bisect and fine-grained reverts.
    • Squashing can lose important context (e.g., file moves and refactors) and makes serious bug-hunting harder.
  • Some point out that if squashing yields unreadable blobs, the PR is probably too big or mixes concerns.
  • Separate thread on merge strategies:
    • Some recommend using rebase on feature branches but merge commits on the main branch, yielding both grouped PR commits and linear per-commit history (--first-parent vs --no-merges).
    • Others simply revert to the last good release rather than hunting individual bad commits.

Tools and workflows for partial commits

  • Strong divide over CLI vs GUI/TUI:
    • CLI fans: git add -p/--patch, plus cousins in git reset and git checkout; praised as fast, ubiquitous, and good for forcing careful review. Options like “split” and “edit” allow fine-grained staging, including single-line edits.
    • Critics: find git add -p’s interactive UI confusing, context-poor, and inferior to line-based selection in GUIs.
  • Popular alternatives mentioned:
    • TUI/CLI: lazygit, tig, stgit, git gui, git-cola, git-crecord, magit (Emacs), vim-fugitive.
    • IDE/GUI: VS Code (“stage selected ranges”, but with past CRLF bugs), JetBrains changelists, GitHub Desktop, SourceTree, Sublime Merge.
  • Several note that partial staging is easy and ergonomic in modern IDEs, and that different tools suit different workflows.

Broader quality vs speed tension

  • Some argue that “being productive” often means shipping quickly at the expense of code and history quality.
  • Others emphasize the long-term cost of “crappy” protocols and code, which become hard to replace once widely adopted.