| > Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change? Almost. Most often it's: - Working on solving problem A
- Notice problem B
- Start to solve problem B
- Notice I'm getting distracted from A, and return to finish it.
- Want to commit my fix for A, but don't want to lose or forget the partial work on B. Two different approaches I might take in this situation, depending on whether B is related to A. 1. If they are related (eg, B depends on A), use `add --patch` to commit A, then finish and commit B.
2. If unrelated, use `git stash --patch` to stash B, then commit A, then switch to a different branch to finish B. Honestly, I see the point of both stash and staging, but not both together. Too many tools for the same job. On my long list of projects to do is a git porcelain that combines some of these concepts (eg, stash and working directory which would be tied to a branch): - Each branch would have a single stash.
- When you check out a new branch, all uncommitted changes are automatically stashed.
- If the branch you're switching to has anything stashed, that stash gets popped.
- Any current workflow that involves stashing can be replicated by using a branch instead of a stash. This way, branches can be thought of as "state of the working directory", which is more intuitive with the branching tree model, imo; commits are a snapshot of the repo at that point in time; and the staging area is just a way to choose what should be included in those commits. |