在Git中重新设置远程分支 [英] Rebasing remote branches in Git

问题描述

我正在使用中间Git存储库来镜像远程SVN存储库，人们可以从中进行克隆和处理。中间存储库的主分支夜间从上游SVN重新分发，我们正在开发功能分支。例如：

 远程：
主人
 
本地人：
主人
功能
  

我可以成功地将我的功能分支返回到远程，并最终得到我预计：

 远程：
主人
功能
 
 local：
 master 
功能
  

然后重新设置分支来跟踪远程：

 远程：
主人
功能
 
本地：
大师
功能 - >原产地/特征
  

一切都很好。我想从这里做的是将功能分支重新绑定到远程主分支，但我想从我的本地计算机执行此操作。我希望能够做到：

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

要保持远程功能分支与远程主机保持最新状态。但是，这种方法会导致Git抱怨：

 要< remote> 
！ [被拒绝]功能 - >功能（非快进）
错误：无法将某些参考推送到'<远程>'
为防止您丢失历史记录，非快进更新被拒绝
合并在再次推送之前，远程更改（例如'git pull'）。有关详细信息，请参阅git push --help的快速转发部分的
'注意事项。 
  

git pull 合并提交，我想避免。我担心这条消息显示功能 - >功能而不是功能 - > origin / feature 但这可能只是一个演示文稿。

我是否错过了某些东西，或者完全以错误的方式解决这个问题？避免在远程服务器上执行rebase并不重要，但它可以更大限度地解决来自rebase的任何合并冲突更难。

解决方案

这涉及到该功能是由一个人使用还是其他人正在使用它。

如果只是你，你可以强制推出rebase之后推送：

  git push origin feature -f 
  

然而，如果其他人正在处理它，你应该合并

  git merge master 
 git push origin特性
  

这将确保您与您合作的人有共同的历史记录。

<在另一层面上，你不应该做反向合并。你正在做的是用不属于该特性的其他提交来污染你的特性分支的历史记录，使得该分支的后续工作更加困难 - 重新绑定与否。

这是我关于这个主题的文章，名为每个功能分支。

希望这有助于。

I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has it's master branch rebased nightly from the upstream SVN, and we are working on feature branches. For example:

remote:
  master

local:
  master
  feature

I can successfully push my feature branch back to the remote, and end up with what I expect:

remote:
  master
  feature

local:
  master
  feature

I then re-setup the branch to track the remote:

remote:
  master
  feature

local:
  master
  feature -> origin/feature

And all is well. What I would like to do from here is to rebase the feature branch to the master branch on the remote, but I would like to do this from my local machine. I'd like to be able to do:

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

To keep the remote feature branch up-to-date with the remote master. However, this method causes Git to complain:

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 does the trick but causes a merge commit that I'd like to avoid. I'm concerned that the message states feature -> feature rather than feature -> origin/feature but this may just be a presentation thing.

Am I missing something, or going about this in completely the wrong way? It's not critical to avoid doing the rebase on the remote server, but it makes fixing any merge conflicts from the rebase much harder.

解决方案

It comes down to whether the feature is used by one person or if others are working off of it.

You can force the push after the rebase if it's just you:

git push origin feature -f

However, if others are working on it, you should merge and not rebase off of master.

git merge master
git push origin feature

This will ensure that you have a common history with the people you are collaborating with.

On a different level, you should not be doing back-merges. What you are doing is polluting your feature branch's history with other commits that don't belong to the feature, making subsequent work with that branch more difficult - rebasing or not.

This is my article on the subject called branch per feature.

Hope this helps.

这篇关于在Git中重新设置远程分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！