在Git中重新部署远程分支机构


135

我正在使用中间的Git存储库来镜像远程SVN存储库,人们可以从中进行克隆和操作。中间存储库有每晚从上游SVN重新建立基础的主分支,我们正在开发功能分支。例如:

remote:
  master

local:
  master
  feature

我可以成功地将功能分支推回远程,并得到我期望的结果:

remote:
  master
  feature

local:
  master
  feature

然后,我重新设置分支以跟踪遥控器:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

一切都很好。从这里我想做的是将功能分支重新建立到远程主机上的master分支,但是我想从本地计算机上完成。我希望能够做到:

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但这可能只是演示性的事情。

我是否缺少某些东西,或者完全以错误的方式进行处理?避免在远程服务器上进行重新基准并不是至关重要的,但是这使得修复来自重新基准的任何合并冲突变得更加困难。


我有同样的问题。我想启动一个分支变基模型(像这样)。然后,我注意到我犯了一个错误: 如果要重新设置基准(在将其重新建立到主数据库上之前,不应该将更改推送到远程功能),因此请向该功能提交一些代码。现在,您想将其推送到远程功能。做到这一点:-如果需要,您应该提取并拉出您的主数据。-如果您的功能中没有对母版进行某些更改,则应该改用母版。现在,您可以推送该功能,不会有任何问题。
马库斯

Answers:


185

这取决于该功能是由一个人使用还是由其他人使用。

如果是您,则可以在重新设置基准之后强制执行推送:

git push origin feature -f

但是,如果其他人在处理它,则应该合并而不是基于master进行重新设置。

git merge master
git push origin feature

这样可以确保您与合作伙伴拥有共同的历史。

从另一个角度来说,您不应该进行反向合并。您正在执行的操作是使用不属于该功能的其他提交污染功能分支的历史记录,从而使该分支的后续工作更加困难-是否需要重新定基础。

这是我有关此主题的文章,称为每功能分支

希望这可以帮助。


29
为+ 1 if others are working on it, you should merge and not rebase off of master,rebase最好只在私有分支上使用。
亨德拉·乌齐亚

6
替代git push origin feature -f,您也可以删除远程功能并再次推送功能
Markus

2
将master合并到您的分支中将创建合并提交,并且在推送更改后,它将与master的任何其他打开的功能分支发生冲突。
史蒂文

为+1 git push origin feature -f。在某些情况下,即使是在远程分支机构中也可能需要执行重新设置基准。症结在于知道您在做什么。我们应该接管您可能要删除远程回购中的提交。
恩格拉

33

很高兴您提出了这个主题。

这是git中的重要内容/概念,git用户中的一小部分将从了解中受益。git rebase是一个非常强大的工具,使您可以将提交压缩在一起,删除提交等。但是与任何强大的工具一样,您基本上需要知道自己在做什么,否则可能会出错。

当您在本地工作并弄乱本地分支机构时,只要您没有将更改推送到中央存储库,就可以做任何您想做的事情。这意味着您可以重写自己的历史记录,但不能重写其他历史记录。通过仅弄乱本地资源,不会对其他存储库造成任何影响。

这就是为什么要记住,一旦您提交了提交,就不要在以后重新建立它们的基础,这一点很重要。之所以如此重要,是因为其他人可能会加入您的提交并将他们的工作基于对代码库的贡献,并且如果您以后决定将内容从一个地方移到另一个地方(重新设置基础)并将其推送更改后,其他人就会遇到问题,必须重新构建代码基础。现在,假设您有1000个开发人员:)它只会导致很多不必要的返工。


因不良语言而被投票
Powers

1
更新了我的语言。
ralphtheninja

5

因为您feature是基于new的master,所以您的本地feature不再是快速转发origin/feature。因此,我认为,在这种情况下,通过执行可以覆盖快进检查,这是很好的git push origin +feature。您也可以在配置中指定

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

如果其他人在上工作origin/feature,他们将被此强制更新打扰。您可以通过合并在新的避免master进入feature,而不是基础重建。结果的确是快速的。


1

您可以使用的--force选项禁用检查(如果您确实确定知道自己在做什么)git push


15
问题是,我不确定我是否真的知道自己在做什么:)
kfb 2011年

@r_:请阅读我的回答。它可以帮助您了解自己在做什么:)
ralphtheninja 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.