Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

PIVOTAL LABS
Standup 3/29/2011: Git it!

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.

Comments
  1. Jack Dempsey says:

    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.

  2. Snuggs says:

    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.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *