moving committed (but not pushed) changes to a new branch after pull

Question

I\'ve done a fair bit of work (\"Your branch is ahead of \'origin/master\' by 37 commits.\") which really should have gone into its own branch rather than into master<

Answer 1

For me this was the best way:

1. Check for changes and merge conflicts git fetch
2. Create a new branch git branch my-changes and push to remote
3. Change upstream to new created branch git master -u upstream-branch remotes/origin/my-changes
4. Push your commits to the new upstream branch.
5. Switch back to previous upstream git branch master --set-upstream-to remotes/origin/master

Answer 2

What about:

1. Branch from the current HEAD.
2. Make sure you are on master, not your new branch.
3. git reset back to the last commit before you started making changes.
4. git pull to re-pull just the remote changes you threw away with the reset.

Or will that explode when you try to re-merge the branch?

Answer 3

A simpler approach, which I have been using (assuming you want to move 4 commits):

git format-patch HEAD~4

(Look in the directory from which you executed the last command for the 4 .patch files)

git reset HEAD~4 --hard

git checkout -b tmp/my-new-branch

Then:

git apply /path/to/patch.patch

In whatever order you wanted.

Answer 4

This should be fine, since you haven't pushed your commits anywhere else yet, and you're free to rewrite the history of your branch after origin/master. First I would run a git fetch origin to make sure that origin/master is up to date. Assuming that you're currently on master, you should be able to do:

git rebase origin/master

... which will replay all of your commits that aren't in origin/master onto origin/master. The default action of rebase is to ignore merge commits (e.g. those that your git pulls probably introduced) and it'll just try to apply the patch introduced by each of your commits onto origin/master. (You may have to resolve some conflicts along the way.) Then you can create your new branch based on the result:

git branch new-work

... and then reset your master back to origin/master:

# Use with care - make sure "git status" is clean and you're still on master:
git reset --hard origin/master

When doing this kind of manipulating branches with git branch, git reset, etc. I find it useful to frequently look at the commit graph with gitk --all or a similar tool, just to check that I understand where all the different refs are pointing.

Alternatively, you could have just created a topic branch based on where your master is at in the first place (git branch new-work-including-merges) and then reset master as above. However, since your topic branch will include merges from origin/master and you've not pushed your changes yet, I'd suggest doing a rebase so that the history is tidier. (Also, when you eventually merge your topic branch back to master, the changes will be more obvious.)

Answer 5

Alternatively, right after you commit to the wrong branch, perform these steps:

1. git log
2. git diff {previous to last commit} {latest commit} > your_changes.patch
3. git reset --hard origin/{your current branch}
4. git checkout -b {new branch}
5. git apply your_changes.patch

I can imagine that there is a simpler approach for steps one and two.

Answer 6

I stuck with the same issue. I have found easiest solution which I like to share.

1) Create new branch with your changes.

git checkout -b mybranch

2) (Optional) Push new branch code on remote server.

git push origin mybranch

3) Checkout back to master branch.

git checkout master

4) Reset master branch code with remote server and remove local commit.

git reset --hard origin/master