在Git中重新定位远程分支

Question

我正在使用一个中间Git存储库镜像远程SVN存储库,人们可以从中进行克隆和处理.中间存储库的主分支从上游SVN每晚重新定位,我们正在开发功能分支.例如:

remote:
  master

local:
  master
  feature

我可以成功地将我的功能分支推回到远程,并最终达到我的期望:

remote:
  master
  feature

local:
  master
  feature

然后我重新设置分支以跟踪远程:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

一切都很好.我想从这里做的是将功能分支重新绑定到远程主分支,但我想从我的本地机器上执行此操作.我希望能够做到:

git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

使远程主控分支与远程主服务器保持同步.但是,这种方法导致Git抱怨:

To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull诀窍但导致合并提交,我想避免.我担心消息会说明feature -> feature而不是,feature -> origin/feature但这可能只是一个介绍的事情.

我错过了什么,或者以完全错误的方式解决这个问题？避免在远程服务器上执行rebase并不重要,但它使得从rebase中修复任何合并冲突变得更加困难.

Answer 1

这取决于该功能是由一个人使用还是其他人正在使用它.

如果只是你,你可以在rebase之后强制推送:

git push origin feature -f

但是,如果其他人正在努力,你应该合并而不是脱离主人.

git merge master
git push origin feature

这将确保您与您合作的人员有共同的历史.

在不同的级别上,您不应该进行反向合并.您正在做的是使用不属于该功能的其他提交来污染您的功能分支的历史记录,使后续使用该分支的工作变得更加困难 - 不论是否变基.

这是我关于这个主题的文章,称为每个功能的分支.

希望这可以帮助.

Answer 2

很高兴你带来了这个主题.

这是git中的一个重要的事情/概念,一小部分git用户将从知道中受益.git rebase是一个非常强大的工具,可以让你将提交压缩在一起,删除提交等.但是,与任何强大的工具一样,你基本上需要知道你正在做什么或者某些事情可能出错.

当您在本地工作并乱搞当地分支机构时,只要您没有将更改推送到中央存储库,您就可以做任何您喜欢的事情.这意味着您可以重写自己的历史记录,但不能重写其他历史记录.只是搞乱你的本地东西,没有什么会对其他存储库产生任何影响.

这就是为什么重要的是要记住,一旦你推送了提交,你就不应该在以后重新设置它们.之所以这一点很重要,就是其他人可能会拉你的提交,并立足于对代码库的贡献自己的工作,如果你以后决定的内容,从一个地方到另一个地方(变基它),推动那些变化,然后其他人将遇到问题,并不得不重新调整他们的代码.现在想象你有1000个开发人员:)它只会导致很多不必要的返工.

Answer 3

因为你feature在新的基础上重新定位master,所以你的本地feature不再是快车origin/feature了.因此,我认为,在这种情况下完全可以通过执行来覆盖快进检查git push origin +feature.您也可以在配置中指定此项

git config remote.origin.push +refs/heads/feature:refs/heads/feature

如果其他人工作origin/feature,他们将被这种强制更新打扰.您可以通过合并在新的避免master进入feature,而不是垫底.结果确实是快进的.