2011-06-22 39 views
2

假设我有以下情况:git-rebase:收敛两个不同的分支/库

存在User Foo的存储库主。用户栏会分散这个存储库,因此这两个存储库都是同步的。现在,用户栏实现了一个功能并创建了一个名为“barbranch”的本地分支。当用户Bar完成一个特性的时候,Foo提交并推送了一些东西到主存储库。所以基本上这样的情况如下:

A---B---C---D main repository 
     \ 
      E  forked repository (where C=E) 
      \ 
      F barbranch on forked repository 

现在在用户Foo的回购中如何恢复正常?

天真,我会说:

# switch to the local master and merge barbranch into it 
git checkout master 
git pull 
git pull upstream 
git push 
git merge barbranch 
# merge conflicts occur 
vi somefile 
git commit -a 
git rebase origin master 
# this conflict occurs again 
vi somefile 
git commit -a 
git status # says I'm on (no branch) ?! 
git push 
g it checkout master 
# conflict occurs again! 
vi somefile 
git commit -a 
git push 
# send merge request to user Foo 

最后这给了我三丑承诺,而不是一个。我发现。虽然我无法弄清楚确切的命令是什么,整个过程最终会如何。

回答

2

它取决于你想得到的树。

如果你想代表真正的工作历史上的树,你不应该用“变基”,但如果你想“线性化”与重订工作的唯一的“合并”

# on bar repo 
git fetch upstream 
git checkout master 
git merge upstream/master (fast-forward) 
git merge barbranch 
# resolve conflicts (adding resolved files) 
git commit 
git push upstream master 

,这里就是你应该这样做:

# on bar repo 
git fetch upstream 
git checkout master 
git merge upstream/master (fast-forward) 
git checkout barbranch 
git rebase master 
# resolve conflicts + commits (each commit will be processed separately: so you may need to do that several times if various commits are in conflict with the upstream) 
git checkout master 
git merge barbranch **(fast-forward after the rebase)** 
git push upstream master 
+0

谢谢,是的,我想要“线性化”版本。只是为了澄清一下:我在哪个分支上执行'git fetch upstream'? “解决冲突+提交”的每一步最后都是'vi somefile; git commit -a',对吧? – user694971

+1

您可以从任何地方获取。为每个冲突文件+最终的“git commit”解决冲突=(“vi”+“git add resolved_file”)。当多个文件发生冲突时,这种方式会更好:您可以每次都知道哪些冲突文件尚未使用“git status”解决。 –

+0

这真的很奇怪,我收到[this]这样的消息(http://pastebin.com/NFirzz6g)。虽然这个分支已经在问题的补丁被接受之前创建... – user694971

2

我认为以下情况应该适合您的情况。

  • 结帐主
  • 拉动分叉处到本地主
  • 手动修复的冲突
  • 提交关于解决冲突的变化
  • 推掌握

这实际上导致3次提交到您的主人(您将有提交E & F和您的冲突解决委员会T)。