How can I temporarily checkout to another branch when merging?

Question

I am currently merging branchA and branchB, there are many conflicts, and I have only settled part of them.

However, I want to checkout to another branch of this repo to handle some other problems.

If I run git merge --abort , I will lose all previous work.

So I wonder if there are some ways that I can "stash" my merge state, checkout to another branch, doing some fix and commits, and then checkout back to my merge state, and continue merging?

Answer 1

TL;DR

Use git worktree add .

Longer

You can't. There is something you can do instead , but first let's expand a bit on this "you can't" thing.

This is something of a problem with Git: when you have an unmerged state, the "un-merged-ness"—the fact that there is an incomplete merge, along with what's incomplete about that merge—is stored in exactly one place, which is in Git's index . (Git also calls this thing the staging area , referring to how you normally use it, and—rarely these days, mostly in flags like git rm --cached —the cache . All three names refer to the same thing, and because of the incomplete merge case, I usually use the term index , because it has no apparent meaning.)

There is a lot to know about Git's index, but the main thing to keep in mind is that the index, or staging area, always holds the proposed next commit , in Git. You cannot make a commit—which includes the inability to run git stash as well, as git stash just makes commits—when the proposed next commit is all internally-confused-all-to-heck the way it is when there's a merge conflict. So you can't make any progress until you solve the merge conflict.

So, what can you do? Well, the trio you have with any normal everyday Git clone—the repository, the index, and the working tree— is a trio. As John V suggested in a comment , you can make another clone, which gets you another trio: <repository, index, working-tree>.

Since Git 2.5, however—with an important fix in Git 2.15 that means you should upgrade your Git if you're behind ¹ —there's been another, less resource-intensive way to deal with this: each Git repository can have added working trees . Each added working tree comes with a new index that's private to that particular working tree.

Hence, the initial clone gets you:

• repository
• primary <index, working-tree> pair (where you can pick a branch to work on / with)

and each added working tree made with git worktree add gets you:

• secondary <index, working-tree> pair (where you should pick one branch to work on / with, that's different from all other working trees, and stick to it)

while using the repository you got when you made the initial clone. So this is "as good as" a new clone, except that:

• it's "better" because there's just the one shared repository, and
• it's "worse" becauase there's just the one shared repository.

If the "better-ness" outweighs the "worse-ness" for you—and it does for almost everyone almost all of the time—use git worktree add . If not (or you don't have git worktree add for some reason), use a separate clone.

---

¹ The bug here is that if you use git worktree add to add a new working tree, and begin working there and then pause for more than two weeks or so, versions of Git between 2.5 and 2.15 can actually lose data. It's really pretty rare and hard to trigger this bug, but I ran into it myself once. So with Git versions of 2.5.0 or later but pre-2.15, if you do use git worktree add , try to finish all your added working tree work within a week or so and then remove (and prune) the added working tree, to avoid the possibility of triggering the bug.

Note that the explicit git worktree remove command wasn't in the original git worktree ; in fact, it was added in Git 2.17. The original design said that you should just manually remove it when done, and run git worktree prune to make the main repository notice that it was gone.

The underlying bug is that the main repository failed to scan each added working trees' HEAD and index. These are actually stored in the repository that goes with the main working tree, so they're available even if the working tree isn't (if it is, as the documentation says, "stored on a portable device... [that] is not always mounted") and should always have been scanned. Someone just forgot.