Ask for Help
“Is there a better way to work on a feature, set that feature set aside, do a small change, check that small change in, then resume work on the feature, all using Git?”
git stash was originally used. There were also suggestions to use a feature branch or use one of the Git GUI tools (gitx, tower, smartgit, gitti) that let you partially stage your changes then check in. Or git-friendly workflow scripts or the ol’ reliable git cherry-pick.
After many experimentations at handling this situation I’ve settled on a simple methodology:
If only one or two files are slightly changed, I’ll stash, get things done, then git stash pop.
If more files are changed, especially if there’s a combination of untracked, tracked, and staged changes, I find a quick feature branch makes the most sense. There’s a lot to be said for things sitting “in front of you” in a branch that you can easily come back and continue on.
I’ve seen too many situations where the return stash popping of your temporary changes conflicts and gets into a difficult place to clean up…and at that point if you lose your work, it’s much harder to get back than simply resetting back to your feature branch’s first commit.
March 29, 2011 at 6:04 pm
Why not just checkout a new branch at a “safe commit” then do “small bit of work”. Then call on my best friend (and should be yours too) good ol’ Rebase. I’ve YET to see any situation (as far as history goes) that rebase cannot get me out of.
P.S. We should all be doing feature branches anyways (let alone having linear production history). I’ve worked on some projects where the repository looks like the NYC subway system.
March 30, 2011 at 6:48 pm