Git's staging area untangles mixed changes
Summary
Ryan Tomayko shows how Git's index bundles individual parts of files into clean commits even though the working copy contains several changes. Git also calls the index the staging area. Patches can be selected hunk by hunk.
Ideas
- Working copy, staging area and repository form three separate states.
- git add --patch takes over selected changes within a file.
- A commit does not have to contain the entire current working state.
- git diff --cached checks the prepared next commit.
- Interactive rebase reorders, combines and edits local commits afterwards.
- Topic branches isolate unfinished work without rigid advance planning.
Insights
- Tools should be able to repair today's mess instead of demanding yesterday's planning.
- A clean history and fluid experimentation are not mutually exclusive.
- An extra intermediate state creates control, even though it seems more complex at first.
- Commits document units of thought, not merely points in time when something was saved.
Facts
- Unstaged changes remain after a commit.
- git commit --amend changes the most recently created commit.
Recommendations
- Check the staged diff before every commit.
- Separate unrelated changes even within the same file.
- Only rewrite history that has not been published.
References
Links to the original source and the Web Archive open in a new tab.