tags:

views:

274

answers:

2

I've been searching around here for to look for an answer and it seems I may just be making incorrect assumptions on how git branches are supposed to work.

I have my master branch and I've created a feature branch called profiles where I'm doing some specific work to profiles. While working on profiles I've changed 5 or 6 files and added another 5 or 6 new files. I needed to switch back to the master branch to fix a quick bug and noticed all the new files and modified files where in there as well. I guess this makes sense since git isnt going to remove untracked files from the master branch and bring them back for my profiles branch since they are, in fact, untracked. But what about the changes to existing files. Why are they showing up in the master branch.

Whats the best practice here. I'm not ready to commit the changes locally yet. Should I just be stashing all these changes, switch to master, make the small fix, switch back to profiles then reapply the stash?

Any help is appreciated. Thanks

+2  A: 

They're not showing up in the master branch - if you did a hard reset and a clean, they'd disappear. Git is merely preserving your local modifications when you switch branches.

This is commonly useful; you might have realized you want to commit those modifications to a different branch than the one you're currently on. If the modifications conflicted with the difference between the two branches, git would refuse to switch branches.

You're right about the best approach, though - switching branches cleanly is in my experience one of the most common uses of git stash.

Jefromi
+6  A: 

"I'm not ready to commit the changes locally yet."

You must be a guy. Fear of committing. :)

But seriously, commits are local things that can be undone, redone, re-re-done at will. It's only when you push the commit somewhere else that you need to pay attention.

Plus, commits are visible to local tools like gitk, and can have diffs taken of them and can be rebased onto other commits, etc. It's a very powerful tool. Learn to use it.

I frequently do:

git add .; git commit -a -m 'WIP'

just to stash away everything in the current work tree if I think I might be interrupted. If I make a few more changes, I use:

git add .; git commit --amend

to update my "WIP" commit in-place. When I'm finally ready for the real commit, I just:

git reset --soft HEAD~; git reset

and now I can carefully control what the final commit will be.

Randal Schwartz
I have a horrible memory and like to use git to see where I am on my work (and with magit its even easier, and is incorporated in to my workflow). Really, you solution makes more sense though. Just commit more often. Just need to tweak my workflow a bit. thanks
Clarence
Just for clarification, is there any intended difference between `git reset --soft HEAD~; git reset` and `git reset HEAD^` ? As far as I can see they both reset HEAD and the index to the parent of the "WIP" commit ready to make a real commit using some or all of the working tree changes but I may have missed a subtlety.
Charles Bailey