Menu
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. These commits only exist on my local machine and have not been pushed to origin, but the situation is complicated somewhat in that other devs have been pushing to origin/master and I've pulled those changes.
How do I retroactively move my 37 local commits onto a new branch? Based on the docs, it appears that git rebase --onto my-new-branch master or ...origin/master should do this, but both just give me the error "fatal: Needed a single revision". man git-rebase says nothing about providing a revision to rebase and its examples do not do so, so I have no idea how to resolve this error.
(Note that this is not a duplicate of Move existing, uncommited work to a new branch in Git or How to merge my local uncommitted changes into another Git branch? as those questions deal with uncommitted changes in the local working tree, not changes which have been committed locally.)
919
Create a new feature branch, say feature, and then switch to that branch. Implement the feature and commit it to our local repository. Push to the feature branch to the remote repository and create a pull request. After other teammate's review, the new change can be merged into the master or release branch.
You must commit or stash those changes first before switching branches. You can think of stash as a drawer to store uncommitted changes temporarily. Stashing allows you to put aside the “dirty” changes in your working tree and continue working on other things in a different branch on a clean slate.
If you have uncommitted changes, the merge part of the git pull command will fail and your local branch will be untouched. Thus, you should always commit your changes in a branch before pulling new commits from a remote repository.
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.)
178
If you have a low # of commits and you don't care if these are combined into one mega-commit, this works well and isn't as scary as doing git rebase:
unstage the files (replace 1 with # of commits)
git reset --soft HEAD~1 create a new branch
git checkout -b NewBranchName add the changes
git add -A make a commit
git commit -m "Whatever" If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
