git: How do I overwrite all local changes on merge?

Here's the situation. I'm working on the master branch. I create file1 and commit. I create file2 and commit. Whoops. I may want to use file2, someday, but it's definitely not something that should be put in the master branch. So that I don't lose file2 I use

git checkout head~1
git branch new-branch
git checkout new-branch

so that I can continue developing. I add file3 to new-branch. If you've been paying attention, I've got two branches, master that contains "file1" and "file2" and new-branch that contains "file1" and "file3".

Now is the time to get the changes I've made back into the master branch. What's the best way to do this? I definitely want the head of the master branch to point at the files as they appear in new-branch, but I also don't want to lose the work I've done 开发者_Python百科in file2 by doing a reset, in case I want to use it.

Keep in mind this is a simplification. Instead of just three files, I've got a dozen files with tens of lines of code being changed all over the place all with multiple commits. I certainly hope the solution isn't to do a file-by-file merge/checkout, because that would be a huge pain.

Any ideas?

I'm working on the master branch. I create file1 and commit.

date >file1
git add file1
git commit -m 'added file1'

I create file2 and commit.

date >file2
git add file2
git commit -m 'added file2'

Whoops. I may want to use file2, someday, but it's definitely not something that should be put in the master branch.

Oops. Very simple. Make a new branch from where you are:

git checkout -b savingfile2

This will make the file2 change the commit for savingfile2. Now go back and unwind one step on master

git checkout master
git reset --hard HEAD~1

At this point, the commits leading up to master will reflect the addition of file1, and the additional commit between master and savingfile2 will be the addition of file2 to that.

If you make more changes to master, and then want to bring file2 back eventually, you'll want to rebase that side-branch onto the new master:

date >file3
git add file3
git commit -m 'adding file3'
date >file4
git add file4
git commit -m 'adding file4'

And now we finally want file2:

git checkout savingfile2
git rebase master # might need to fix conflicts here
git checkout master
git merge savingfile2 # will be a fast-forward
git branch -d savingfile2 # no need any more

That should do it.

What you should do is what you should have done when you noticed your mistake of commiting file2: undo the commit (instead of creating a new branch):

git checkout master
git reset HEAD^

This leaves file2 untracked and unharmed and possible modifications uncommited. Then you should (have) stash(ed) the uncommited modifications in case you want to use them later:

git stash save "modifications that should not be in the master branch"

Stashing gets rid of any local changes, which allows master to be made point to new-branch:

git merge new-branch

The goal here was to eliminate the divergence between the two branches, i.e. make master an ancestor of new-branch. This way no actual merging would have to occur, and the last command would just fast-forward the master branch (provided there are no local changes).

Since you didn't follow the optimal workflow described by Tomi Kyöstilä, but also since you didn' publish (push) anything yet, why not switch the two branches?
(provided everything is committed)

master and new-branch are just some pointers to some SHA1:

$ git checkout master              #start from master
$ git branch tmp                   # tmp points on master HEAD
$ git checkout new-branch          # switch to new-branch
$ git branch -f master new_branch  # master points at new-branch HEAD
$ git checkout tmp                 # switch back to *former* master branch
$ git branch -f new_branch tmp     # new-branch points at former master HEAD
$ git checkout master              # go to new master
$ git branch -D tmp                # remove tmp pointer

... and you're done.
(disclaimer: not tested yet, so try it with caution ;) )

See:

• a similar approach in the paragraph "Fixing mistakes without git-reset" of "Branching and merging with git",
• and also in this thread