11 Answers
11

Moving to a new branch

WARNING: This method works because you are creating a new branch with the first command: git branch newbranch. If you want to move commits to an existing branch you need to merge your changes into the existing branch before executing git reset --hard HEAD~3 (see Moving to an existing branch below). If you don't merge your changes first, they will be lost.

Unless there are other circumstances involved, this can be easily done by branching and rolling back.

# Note: Any changes not committed will be lost.
git branch newbranch # Create a new branch, saving the desired commits
git reset --hard HEAD~3 # Move master back by 3 commits (GONE from master)
git checkout newbranch # Go to the new branch that still has the desired commits

But do make sure how many commits to go back. Alternatively, you can instead of HEAD~3, simply provide the hash of the commit (or the reference like origin/master) you want to "revert back to" on the master (/current) branch, e.g:

git reset --hard a1b2c3d4

*1 You will only be "losing" commits from the master branch, but don't worry, you'll have those commits in newbranch!

WARNING: With Git version 2.0 and later, if you later git rebase the new branch upon the original (master) branch, you may need an explicit --no-fork-point option during the rebase to avoid losing the carried-over commits. Having branch.autosetuprebase always set makes this more likely. See John Mellor's answer for details.

Moving to an existing branch

If you want to move your commits to an existing branch, it will look like this:

And in particular, don't try to go back further than the point where you last pushed commits to another repository from which somebody else might have pulled.
– Greg HewgillOct 27 '09 at 3:23

91

Wondering if you can explain WHY this works. To me you're creating a new branch, removing 3 commits from the old branch you are still on, and then checking out the branch you made. So how do the commits you removed magically show up in the new branch?
– Jonathan DumaineAug 3 '10 at 18:28

123

@Jonathan Dumaine: Because I created the new branch before removing the commits from the old branch. They're still there in the new branch.
– sykoraAug 4 '10 at 8:28

79

branches in git are just markers which point to commits in history, there is nothing being cloned, created or deleted (except the markers)
– knittlAug 16 '10 at 11:32

191

Also note: Don't do this with uncommitted changes in your working copy! This just bit me! :(
– Adam TuttleOct 25 '11 at 3:59

You want to go back to C, and move D and E to the new branch. Here's what it looks like at first:

A-B-C-D-E (HEAD)
↑
master

After git branch newBranch:

newBranch
↓
A-B-C-D-E (HEAD)
↑
master

After git reset --hard HEAD~2:

newBranch
↓
A-B-C-D-E (HEAD)
↑
master

Since a branch is just a pointer, master pointed to the last commit. When you made newBranch, you simply made a new pointer to the last commit. Then using git reset you moved the master pointer back two commits. But since you didn't move newBranch, it still points to the commit it originally did.

You do need --hard, because otherwise git leaves the changes from the reset commits in the working directory (or at least did for me).
– AndrewAug 22 '11 at 22:05

37

I also needed to do a git push origin master --force for the change to show up in main repository.
– DženanNov 26 '14 at 19:20

7

This answer causes commits to be lost: next time you git rebase, the 3 commits will be silently discarded from newbranch. See my answer for details and safer alternatives.
– John MellorApr 6 '16 at 22:47

6

@John, that's nonsense. Rebasing without knowing what you're doing causes commits to be lost. If you lost commits, I'm sorry for you, but this answer didn't lose your commits. Note that origin/master doesn't appear in the above diagram. If you pushed to origin/master and then made the changes above, sure, things would go funny. But that's a "Doctor, it hurts when I do this" kind of problem. And it's out of scope for what the original question asked. I suggest you write your own question to explore your scenario instead of hijacking this one.
– Ryan LundyApr 7 '16 at 3:20

Wasn't the OP trying to move from master to newbranch? If you cherry-pick whilst on master, you would be adding to the master branch -- adding commits that it already had, in fact. And it doesn't move back either branch head to B. Or is there something subtle and cool I'm not getting?
– RaveTheTadpoleJul 6 '12 at 2:48

6

This works very well if you accidentally commit the wrong, non-master branch, when you should have created a new feature branch.
– juliancFeb 27 '14 at 16:47

4

+1 for a useful approach in some situations. This is good if you only want to pull your own commits (which are interspersed with others) into a new branch.
– Tyler V.Oct 1 '14 at 17:11

7

It's better answer. This way you can move commits to any branch.
– skywinderNov 5 '14 at 8:32

8

Is the order of cherry picking important?
– kon psychApr 23 '15 at 22:04

Current directory. I guess this would work only if you are in a top directory.
– aragaerMar 28 '14 at 5:35

1

The local push is grin-inducing, but on reflection, how is it different to git branch -f here?
– jthillAug 5 '14 at 0:15

2

@GerardSexton . is current director. git can push to REMOTES or GIT URLs. path to local directory is supported Git URLs syntax. See the GIT URLS section in git help clone.
– weakishNov 25 '14 at 10:24

26

I don't know why this is not rated higher. Dead simple, and without the small but potential danger of git reset --hard.
– GodsmithFeb 6 '15 at 14:56

4

@Godsmith My guess is people prefer three simple commands to two slightly more obscure commands. Also, top voted answers get more upvotes by nature of being displayed first.
– JS_RiddlerOct 22 '15 at 15:43

First it discards the 3 most recent commits (--keep is like --hard, but safer, as fails rather than throw away uncommitted changes).

Then it forks off newbranch.

Then it cherry-picks those 3 commits back onto newbranch. Since they're no longer referenced by a branch, it does that by using git's reflog: HEAD@{2} is the commit that HEAD used to refer to 2 operations ago, i.e. before we 1. checked out newbranch and 2. used git reset to discard the 3 commits.

Warning: the reflog is enabled by default, but if you've manually disabled it (e.g. by using a "bare" git repository), you won't be able to get the 3 commits back after running git reset --keep HEAD~3.

(if you prefer you can write @{-1} - the previously checked out branch - instead of oldbranch).

Technical explanation

Why would git rebase discard the 3 commits after the first example? It's because git rebase with no arguments enables the --fork-point option by default, which uses the local reflog to try to be robust against the upstream branch being force-pushed.

Suppose you branched off origin/master when it contained commits M1, M2, M3, then made three commits yourself:

M1--M2--M3 <-- origin/master
\
T1--T2--T3 <-- topic

but then someone rewrites history by force-pushing origin/master to remove M2:

M1--M3' <-- origin/master
\
M2--M3--T1--T2--T3 <-- topic

Using your local reflog, git rebase can see that you forked from an earlier incarnation of the origin/master branch, and hence that the M2 and M3 commits are not really part of your topic branch. Hence it reasonably assumes that since M2 was removed from the upstream branch, you no longer want it in your topic branch either once the topic branch is rebased:

M1--M3' <-- origin/master
\
T1'--T2'--T3' <-- topic (rebased)

This behavior makes sense, and is generally the right thing to do when rebasing.

is because they leave the reflog in the wrong state. Git sees newbranch as having forked off the upstream branch at a revision that includes the 3 commits, then the reset --hard rewrites the upstream's history to remove the commits, and so next time you run git rebase it discards them like any other commit that has been removed from the upstream.

But in this particular case we want those 3 commits to be considered as part of the topic branch. To achieve that, we need to fork off the upstream at the earlier revision that doesn't include the 3 commits. That's what my suggested solutions do, hence they both leave the reflog in the correct state.

This answer says "Do NOT do this!" above something that no one suggested doing.
– Ryan LundyApr 16 '16 at 21:41

1

Most people don't rewrite published history, especially on master. So no, they are not dangerously wrong.
– WalfSep 14 '16 at 6:59

3

@Kyralessa, the -t you are referring to in git branch happens implicitly if you have git config --global branch.autosetuprebase always set. Even if you don't, I already explained to you that the same problem occurs if you setup tracking after performing these commands, as the OP likely intends to do given their question.
– John MellorSep 16 '16 at 2:36

1

@RockLee, yes, the general the way to fix such situations is to create a fresh branch (newbranch2) from a safe starting point then cherry-pick all the commits you want to keep (from badnewbranch to newbranch2). Cherry-picking will give the commits new hashes, so you'll be able to safely rebase newbranch2 (and can now delete badnewbranch).
– John MellorSep 16 '16 at 2:36

2

@Walf, you misunderstood: git rebase is designed to be robust against upstreams having their history rewritten. Unfortunately, the side-effects of that robustness affect everyone, even if neither they nor their upstream ever rewrite history.
– John MellorSep 16 '16 at 2:37

Much simpler solution using git stash

You want to keep file changes but don't particularly care about the mistaken commits messages, and

You haven't pushed yet, and

You want this to be easy and not complicated with temp branches, commit hashes, and other headaches

Then the following is far simpler (starting on branch master that has three mistaken commits):

git reset HEAD~3
git stash
git checkout newbranch
git stash pop

What this does, by line number

Undoes the last three commits (and their messages) to master, yet leaves all working files intact

Stashes away all the working file changes, making the master working tree exactly equal to the HEAD~3 state

Switches to an existing branch newbranch

Applies the stashed changes to your working directory and clears the stash

You can now use git add and git commit as you normally would. All new commits will be added to newbranch.

What this doesn't do

It doesn't leave random temporary branches cluttering your tree

It doesn't preserve the mistaken commits and commit messages, so you'll need to add a new commit message to this new commit

Goals

The OP stated the goal was to "take master back to before those commits were made" without losing changes and this solution does that.

I do this at least once a week when I accidentally make new commits to master instead of develop. Usually I have only one commit to rollback in which case using git reset HEAD^ on line 1 is a simpler way to rollback just one commit.

Don't do this if you pushed master's changes upstream

Someone else may have pulled those changes. If you are only rewriting your local master there's no impact when it's pushed upstream, but pushing a rewritten history to collaborators can cause headaches.

Thanks, am so glad I read past/through so much to get to here, cause it's a pretty common use case for me as well. Are we so atypical?
– Jim MackSep 10 '18 at 17:58

3

I think we're totally typical and "oops I commited to master by mistake" is the most common use-case for need to revert a handful or less of commits. Lucky this solution is so simple I have it memorized now.
– SlamSep 11 '18 at 19:58

4

This should be the accepted answer. It's straightforward, easy to understand and easy to remember
– Sina MadaniNov 28 '18 at 0:53

This doesn't "move" them in the technical sense but it has the same effect:

A--B--C (branch-foo)
\ ^-- I wanted them here!
\
D--E--F--G (branch-bar)
^--^--^-- Opps wrong branch!
While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)
A--B--C (branch-foo)
\
\
D-(E--F--G) detached
^-- (branch-bar)
Switch to branch-foo
$ git cherry-pick E..G
A--B--C--E'--F'--G' (branch-foo)
\ E--F--G detached (This can be ignored)
\ /
D--H--I (branch-bar)
Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:
A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
\
\
D--H--I--J--K--.... (branch-bar)

But then you have to deal with the revert scenario, which, depending on your circumstance, can be a lot trickier. If you revert a commit on the branch, Git will still see those commits as have taken place, so in order to undo that, you have to revert the revert. This burns quite a few people, especially when they revert a merge and try to merge the branch back, only to find that Git believes that it's already merged that branch in (which is entirely true).
– MakotoApr 7 '16 at 16:15

1

That's why I cherry-pick the commits at the end, onto a new branch. That way git sees them as new commits, which solves your issue.
– teh_senausApr 7 '16 at 17:18

This is more dangerous than it first seems, since you're changing the state of the repository's history without really understanding the implications of this state.
– MakotoApr 7 '16 at 19:25

4

I don't follow your argument - the point of this answer is that you're not changing history, simply adding new commits (which effectively undo the redo the changes). These new commits can be pushed and merged as normal.
– teh_senausApr 8 '16 at 10:33

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).