切换到另一个分支而不提交

Question

I am working on a feature branch and have not finished the work there - Now I need to change to a different branch to fix something

for example

feat1 - 6+ files changed

When I checkout to feat2 branch, after git add . in feat1, git seems to carry over the staged yet uncommitted file changes.

If I commit these file changes in feat1, checking out to feat2 will not carry over those changes

How can I switch branches without committing file changes?

Answer 1

Stash them:

$ git stash save -u "Some logical description of the changes"
$ git stash list
stash@{0}: Some logical description of the changes
$ git checkout other-branch

When you're done, you can use git stash apply to apply the changes in your stash and keep the stash around, or git stash pop to apply the changes and remove the stash as long as there are no conflicts.

If you end up with multiple stashes at once you can apply or pop them in an arbitrary order using the stash@ string, eg git stash apply stash@{6} .

Answer 2

Most people recommend git stash .

I prefer just doing a git commit . You can always git commit --amend later. Just make sure not to push that particular commit. If it helps—and for me, it does—just make a branch for "work in progress on feature". For instance:

$ git checkout zorg
Branch zorg set up to track remote branch zorg from origin.
Switched to a new branch 'zorg'
... work ...

At this point, I realize I need to save the work-so-far and go do something else:

$ git checkout -b zorg-stones-1
Switched to a new branch 'zorg-stones-1'
$ git commit

Now everything is all nicely saved away on a local branch that I have named in a way that helps me remember what I was doing, when I come back later.

Often, I come back later to find that origin/zorg has been updated, so:

$ git fetch
[shows that origin/zorg is updated]
$ git checkout zorg && git merge --ff-only origin/zorg
[now local branch zorg is updated too; --ff-only is just for paranoia]
$ git checkout zorg-stones-1
$ git rebase zorg
[rebase messages here]

If the rebase does not go well (or I need to rework things), I use git rebase --abort (or just skip the rebase attempt) and then start a new zorg-stones-2 branch based on the updated zorg . When I'm good about it, I commit often enough and don't have to do a lot of git rebase -i zorg to fix it up a whole lot before doing git checkout zorg; git merge zorg-stones-N git checkout zorg; git merge zorg-stones-N to bring in the final version, ready to git push or whatever.

I often have a bunch of blah-mods-N branches to (eventually) delete this way. It's definitely true that stash ing is less branch-clutter-y. But I prefer to have everything I did accessible by name up until I deliberately toss it out.

Answer 3

You should use git stash

http://git-scm.com/book/en/Git-Tools-Stashing explains your exact case-scenario

Answer 4

Even if you did not finish your work I would suggest committing them.

Committing is always a good idea. - However, pushing is usually only a good idea when you are finished.

If your commits are not perfect you can always clean them up or combine them using something like git rebase -i before pushing them.