Question

How can you git-checkout without overwriting the data?

I run

 git checkout master

I get

error: Entry 'forms/answer.php' would be overwritten by merge. Cannot merge.

This is surprising, since I did not know that Git merges when I git-checkout. I have always run after the command separately git merge new-feature. This seems to be apparently unnecessary if Git merges at checkout.

Was it helpful?

Solution

Git is warning you that forms/answers.php has changes in your working copy or index that have not been committed.

You can use git-stash to save your changes then git-stash apply to restore them.

The common use case of git-stash is that you are working on changes but then must temporarily checkout a different branch to make a bug fix. So you can stash your changes in your index and working copy, checkout the other branch, make the bug fix, commit, checkout the original branch, and git-stash apply to restore your changes and pick-up where you left off.

OTHER TIPS

Git does a 2-way merge of uncomitted changes when switching branches (using git checkout <branch>), but ordinarily it does only trivial (tree-level) merge.

Besides git-stash solution by Karl Voigtland, you can give additional options to git checkout, choosing one of the following options:

  • Tell git to try harder to merge uncomitted changes into branch you switch to with -m / --merge option. With this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.

  • Tell git to overwrite uncomitted changes, throwing away local changes with -f option. Warning: uncomitted changes will be lost!

You can do a git reset --soft to make your HEAD point to the new branch, but leave all the files as they are (including the ones that were changed in the new branch). Then you can use git checkout to checkout just the files that you really want from the new branch.

       git reset [<mode>] [<commit>]
           This form resets the current branch head to <commit> and possibly updates the index (resetting it to the
           tree of <commit>) and the working tree depending on <mode>. If <mode> is omitted, defaults to --mixed.
           The <mode> must be one of the following:

           --soft
               Does not touch the index file or the working tree at all (but resets the head to <commit>, just like
               all modes do). This leaves all your changed files "Changes to be committed", as git status would put
               it.
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top