Git 藏匿两个分支

Question

This is the situation:

1. I made changes on branch A
2. git stash on branch A
3. git checkout B
4. Made changes on branch B
5. git stash on branch B
6. git checkout A
7. git stash pop on branch A

After step 7 of the list above, the changes I had made on branch A before stashing did not come back but the changes I had made on branch B popped on branch A. I used cmd z on branch A and the file went to its previous state, which had the changes I had made. It seemed the HEAD of branch A moved to the HEAD of branch B. The same happened when I git checkout B and git stash pop on that branch: branch B had all the changes made on branch A but not the changes I had made on branch B. I used cmd z again to revert to the branch state I needed.

This caused me a lot of problems for sometime, until I was allowed to commit code again on the project (nobody could commit for a while because there was an automated push to the server on commits and the manager didn't want new code in the server until they ran some tests). How can I pop only the changes made on the branches themselves and not changes made on other branches?

Answer 1

What git stash does is make a commit. ¹

Of course, what git commit does is make a commit. So why do we have git stash at all?

A significant difference between these commands is that the commits git stash makes are not on any branches . This allows you to stash when on one branch, then move to another branch and apply the stash there. In other words, it lets you move in-progress work.

You can often, but not always, move in-progress work anyway. See Git - checkout another branch when there are uncommitted changes on the current branch . When you can't , though, you can use git stash to deal with this.

On the other hand, if you want to "stash on a branch", as in your case, you are probably better off just making a regular commit, rather than a special stash commit. Such commits are easier to deal with, and also do not have a bug that git stash has . You are not likely to hit this bug but "regular commits are simpler and easier to deal with" (commits on branches, vs stashes) is a pretty good reason to avoid git stash .

If you prefer to use git stash anyway, note that each new stash "pushes" the previous ones up higher in a "stash stack". The old stash becomes stash@{1} , and what was stash@{1} becomes stash@{2} , and so on. When you drop (discard) or pop (attempt to apply, then discard) a stash, the stacked ones above it move back down—so if you were to git stash drop stash@{3} when you had stash@{4} and stash@{5} as well, you would be left with stash@{3} and stash@{4} now.

You can name any stash, including the most recent one, this way: stash@{0} means the same thing as stash . (Git actually implements all this using the reflog for stash .)

---

¹ In fact, it makes at least two commits, and sometimes three. The two commits store the index and work-tree state; the third commit, if present, is from -u or -a and stores the unstaged ( -u ) or all ( -a ) files. The work-tree commit is a very odd merge commit, with the index commit as its second parent and the third commit, if present, as its third parent. The first parent of the work-tree commit, and the sole parent of the index commit, is the commit that was current when you ran git stash .

If you draw commit graph fragments—which, any time you are doing anything complicated in Git, is a good idea—the index-and-work-tree commit pair kind of dangles off the original commit, with the refs/stash reference pointing to the pair, rather than the branch name. It looks almost like a small handbag, or a food cache hung from a tree branch to keep it away from bears, or some such, so I like to refer to this as a "stash bag".

Answer 2

Torek (as usual) provides an excellent answer, but I believe the succinct answer here is just to note that the stash contains data as a stack (LIFO). So when you pushed A's work and then B's work, it first pops B then A. So when you went back to A and then did the first pop, you got the saved B work.

Answer 3

Popping a stash re-applies that last stash regardless from which branch you stashed! So, the problem you are posting is that last stash that was created on branch B was re-applied on branch A. Next time, You have to specify which stash you want to pop.

Solution to the given problem:

1. Stash again the current status
2. Pop the stash that is before the last

That's all.

Answer 4

if you type git stash list something like this will be displayed based on your given situation

stash@{0}: WIP on branch-b
stash@{1}: WIP on branch-a

typing git stash pop will always get the stash@{0} node.

So, if you're in branch a and you want to apply your progress in that branch. Basing on the list, you should type:

git stash pop stash@{1}