拉动后移动的已提交(但未推送)更改到新分支 [英] moving committed (but not pushed) changes to a new branch after pull

问题描述

我已经做了很多工作(您的分支比'origin/master'领先37项提交.")实际上应该已经进入了自己的分支，而不是进入了master.这些提交仅存在于我的本地计算机上，还没有推送到origin，但是情况有些复杂，因为其他开发人员一直在推送到origin/master，而我撤消了这些更改.

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.

如何将我的37个本地提交追溯地移动到新分支上?根据文档，似乎git rebase --onto my-new-branch master或...origin/master应该执行此操作，但是两者都给我错误致命:需要单个修订". man git-rebase没有提供有关对rebase进行修订的内容，其示例也没有这样做，因此我不知道如何解决此错误.

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.

(请注意，这不是不是的如何将我的本地未提交的更改合并到另一个Git分支中?，因为这些问题处理的是本地工作树中未提交的更改，而不是本地已提交的更改.)

(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.)

推荐答案

这应该没问题，因为您还没有将提交推送到其他任何地方，并且您可以在origin/master之后自由重写分支的历史记录. .首先，我将运行git fetch origin以确保origin/master是最新的.假设您当前在master上，则应该可以:

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

...，它将把不在origin/master中的所有提交重播到origin/master中. rebase的默认操作是忽略合并提交(例如，您的git pull可能引入的合并)，并且它将仅尝试将每次提交所引入的补丁应用于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

...，然后将您的master重置回origin/master:

... 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

使用git branch，git reset等进行此类分支操作时，我发现经常使用gitk --all或类似工具查看提交图很有用，只是检查我是否了解所有不同的裁判指向.

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.

或者，您可以仅基于母版的位置(git branch new-work-including-merges)创建一个主题分支，然后如上所述重置master.但是，由于您的主题分支将包括来自origin/master的合并，并且您尚未推送所做的更改，因此建议您进行重新设置基准，以使历史记录更整洁. (此外，当您最终将主题分支合并回master时，更改将更加明显.)

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.)

这篇关于拉动后移动的已提交(但未推送)更改到新分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！