Move the most recent commit(s) to a new branch with Git
GitGit BranchBranching and-MergingGit Problem Overview
I'd like to move the last several commits I've committed to master to a new branch and take master back to before those commits were made. Unfortunately, my Git-fu is not strong enough yet, any help?
I.e. How can I go from this
master A - B - C - D - E
to this?
newbranch C - D - E
/
master A - B
Git Solutions
Solution 1 - Git
Moving to an existing branch
If you want to move your commits to an existing branch, it will look like this:
git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch
You can store uncommitted edits to your stash before doing this, using git stash
. Once complete, you can retrieve the stashed uncommitted edits with git stash pop
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 above). 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 checkout master # checkout master, this is the place you want to go back
git reset --hard HEAD~3 # Move master back by 3 commits (Make sure you know how many commits you need to go back)
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!
Lastly, you may need to force push your latest changes to main repo:
git push origin master --force
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.
Solution 2 - Git
For those wondering why it works (as I was at first):
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.
Solution 3 - Git
#In General...
The method exposed by sykora is the best option in this case. But sometimes is not the easiest and it's not a general method. For a general method use git cherry-pick:
To achieve what OP wants, its a 2-step process:
#Step 1 - Note which commits from master you want on a newbranch
Execute
git checkout master
git log
Note the hashes of (say 3) commits you want on newbranch
. Here I shall use:
C commit: 9aa1233
D commit: 453ac3d
E commit: 612ecb3
> Note: You can use the first seven characters or > the whole commit hash
#Step 2 - Put them on the newbranch
git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233
#OR (on Git 1.7.2+, use ranges)
git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233
git cherry-pick applies those three commits to newbranch.
Solution 4 - Git
Most previous answers are dangerously wrong!
Do NOT do this:
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
As the next time you run git rebase
(or git pull --rebase
) those 3 commits would be silently discarded from newbranch
! (see explanation below)
Instead do this:
git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
- 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 thatHEAD
used to refer to 2 operations ago, i.e. before we 1. checked outnewbranch
and 2. usedgit 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
.
An alternative that doesn't rely on the reflog is:
# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~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.
So the reason that the following commands fail:
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch
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.
For more details, see the definition of --fork-point
in the git rebase and git merge-base docs.
Solution 5 - Git
Yet another way to do this, using just 2 commands. Also keeps your current working tree intact.
git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit
Old version - before I learned about git branch -f
git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit
Being able to push
to .
is a nice trick to know.
Solution 6 - Git
Much simpler solution using git stash
Here's a far simpler solution for commits to the wrong branch. Starting on branch master
that has three mistaken commits:
git reset HEAD~3
git stash
git checkout newbranch
git stash pop
When to use this?
- If your primary purpose is to roll back
master
- You want to keep file changes
- You don't care about the messages on the mistaken commits
- You haven't pushed yet
- You want this to be easy to memorize
- You don't want complications like temporary/new branches, finding and copying commit hashes, and other headaches
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 commit messages, so you'll need to add a new commit message to this new commit
- Update! Use up-arrow to scroll through your command buffer to reapply the prior commit with its commit message (thanks @ARK)
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.
Solution 7 - Git
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)
Solution 8 - Git
To do this without rewriting history (i.e. if you've already pushed the commits):
git checkout master
git revert <commitID(s)>
git checkout -b new-branch
git cherry-pick <commitID(s)>
Both branches can then be pushed without force!
Solution 9 - Git
Simplest way to do this:
1. Rename master
branch to your newbranch
(assuming you are on master
branch):
git branch -m newbranch
2. Create master
branch from the commit that you wish:
git checkout -b master <seven_char_commit_id>
> e.g. git checkout -b master a34bc22
NOTE:
The upstream for newbranch
would be origin/master
.
Solution 10 - Git
Had just this situation:
Branch one: A B C D E F J L M
\ (Merge)
Branch two: G I K N
I performed:
git branch newbranch
git reset --hard HEAD~8
git checkout newbranch
I expected that commit I would be the HEAD, but commit L is it now...
To be sure to land on the right spot in the history its easier to work with the hash of the commit
git branch newbranch
git reset --hard #########
git checkout newbranch
Solution 11 - Git
How can I go from this
A - B - C - D - E
|
master
to this?
A - B - C - D - E
| |
master newbranch
With two commands
- git branch -m master newbranch
giving
A - B - C - D - E
|
newbranch
and
- git branch master B
giving
A - B - C - D - E
| |
master newbranch
Solution 12 - Git
If you just need to move all your unpushed commits to a new branch, then you just need to,
-
create a new branch from the current one :
git branch new-branch-name
-
push your new branch:
git push origin new-branch-name
-
revert your old(current) branch to the last pushed/stable state:
git reset --hard origin/old-branch-name
Some people also have other upstreams
rather than origin
,
they should use appropriate upstream
Solution 13 - Git
You can do this is just 3 simple step that i used.
- make new branch where you want to commit you recent update.
git branch <branch name>
- Find Recent Commit Id for commit on new branch.
git log
- Copy that commit id note that Most Recent commit list take place on top. so you can find your commit. you also find this via message.
git cherry-pick d34bcef232f6c...
you can also provide some rang of commit id.
git cherry-pick d34bcef...86d2aec
Now your job done. If you picked correct id and correct branch then you will success. So before do this be careful. else another problem can occur.
Now you can push your code
git push
Solution 14 - Git
Most of the solutions here count the amount of commits you'd like to go back. I think this is an error prone methodology. Counting would require recounting.
You can simply pass the commit hash of the commit you want to be at HEAD or in other words, the commit you'd like to be the last commit via:
(Notice see commit hash)
To avoid this:
1) git checkout master
2) git branch <feature branch> master
3) git reset --hard <commit hash>
4) git push -f origin master
Solution 15 - Git
-
Create a new branch, which moves all your changes to new_branch.
git checkout -b new_branch
-
Then go back to old branch.
git checkout master
-
Do git rebase
git rebase -i
-
Then the opened editor contains last 3 commit information.
... pick
C pick D pick E ... -
Change
pick
todrop
in all those 3 commits. Then save and close the editor.... drop
C drop D drop E ... -
Now last 3 commits are removed from current branch (
master
). Now push the branch forcefully, with+
sign before branch name.git push origin +master
Solution 16 - Git
I was surprised that nobody recommended this way:
git checkout master
git checkout <commit hash from which you want to split>
git checkout -b new_branch
git rebase master
git checkout master
git reset --hard <commit hash you splitted>
to explain:
- step we checking out the commit where we want to split
- then from this commit creating a new branch
- doing rebase will synchronize new_branch and master. So now we have two same branches with same commits
- with reset on master, we cleanup last commits after split
- List item
Solution 17 - Git
Using Emacs' git porcelain Magit, you can do this simply by hitting b s
(magit-branch-spinoff). You'll be asked to enter a name for your new branch and once you hit enter, voila.
From the Magit documentation:
> This command creates and checks out a new branch starting at and tracking the current branch. That branch in turn is reset to the last commit it shares with its upstream. If the current branch has no upstream or no unpushed commits, then the new branch is created anyway and the previously current branch is not touched. > > This is useful to create a feature branch after work has already began on the old branch (likely but not necessarily "master").
Solution 18 - Git
I got to move 7 commits from one old-branch to a new-branch.
git checkout old-branch # in the example, master
git reset --hard h4sh # h4sh is the hash for the commit
git checkout -b new-branch
git push origin new-branch
After that, both branches were related to the 7 commits I have done. After git checkout new-branch
, I was getting fine git log
and git status
, but, when accessing the old-branch (git checkout old-branch
), I'd got the message "git is behind by 7 commits and can be fast-forwarded". What worked for me to erase this message was the followind:
git checkout old-branch
git status
> git is behind by 7 commits and can be fast-forwarded
git push origin old-branch -f
After that step, the last 7 commits was referenced only for the new-branch and the previous ones were referenced as old-branch and new-branch in the Bitbucket tree.
Solution 19 - Git
If you are a UI person like me and you are using Visual Studio. Then you can do the following: In my case, I want to take the latest commit to another branch.
- Right-click on the one (commit) before.
-
So all commit changes will appear in the Git Changes pane.
-
Now, stash your changes
- Go to your targeted branch or create a new one from the bottom right corner.
-
From "Git Changes" double click on your latest Stash.
-
"Stash details" pane will be opened. Click on "Pop", then resolve conflicts (if exists).
- And finally, commit your changes.
Solution 20 - Git
TLDR
git checkout branch_to_remove_commits
git reset --hard ${hash_of_new_tip}
git checkout -b branch_to_store_commits
# For each commit to move
git cherry-pick ${commit_hash}
git push --set-upstream origin branch_to_store_commits
# Switch back to last branch
git checkout -
git push -f
For me
git log --pretty=oneline -n ${NUMBER}
works best to identify the commit hashes in question.
Solution 21 - Git
Taking some ideas from other posts, avoiding anything to do with reset, and being ultra paranoid, my solution is:
- git branch
# changes are available in new branch - git push
# upload, you may need to mess with "--set-upstream", e.g. git push --set-upstream https:// / - check the new branch is in git via a GUI
- destroy current directory
- re-clone from git repository
I'm not proud, but I kept my data ;)