2013-11-03 113 views
19

我有一个远程存储库,我已经拉出并分支。我希望通过对主人所做的更改保持最新的分支。我正在考虑下面的工作流程,这是否有意义,还是有更好的方法来做到这一点?保持与主人的分支最新

  1. 初始分支和结帐:

    git checkout master 
    
    git pull 
    
    git checkout -b my_branch 
    
  2. 做一些工作my_branch,然后定期:

    git checkout master 
    
    git pull 
    
    git checkout my_branch 
    
    git merge master --no-ff 
    

重复步骤2,根据需要,定期推向远程my_branch

然后,当准备好合并回:

git checkout master 

git merge my_branch --no-ff 

声音好吗?

回答

16

您可以简化您的命令:

1.

git fetch 
git checkout -b my_branch origin/master 

2.

git fetch 
git merge origin/master 

git fetch更新远程分支,通常没有必要有当你没有的时候,一个分支的本地副本计划在这个分支上工作。

设置​​3210后可以省略--no-ff

git help config说:

merge.ff 
     By default, Git does not create an extra merge commit when merging 
     a commit that is a descendant of the current commit. Instead, the 
     tip of the current branch is fast-forwarded. When set to false, 
     this variable tells Git to create an extra merge commit in such a 
     case (equivalent to giving the --no-ff option from the command 
     line). When set to only, only such fast-forward merges are allowed 
     (equivalent to giving the --ff-only option from the command line). 

注意git pull只是一个git fetchgit merge组合。

通常你只是想要git pull --rebase这本质上是git fetchgit rebase,并创建一个更清洁的历史。

是否有任何理由让你的“周期性推动”?如果没有其他人在同一个分支上工作,那完全没问题,只需要在完成所有工作后推动。

+0

感谢您(和克里斯托弗)的回复。为了回答你的问题,没有理由让周期性推动,而不是作为备份,以防我的盒子死亡。而且,如果有人希望我的代码能够完成他们自己的工作 - 不完全可能,直到我的代码进入主服务器,再在公共分支上进行重新绑定可能会导致麻烦,所以我明白(但我不确定为什么确切) – larryq

+1

rebases是一把双刃剑。一方面它们往往导致更加清晰的历史。另一方面他们创建了基本上是旧内容的全新提交。如果你推动你的提交,其他人可以(理论上)在这些提交上构建自己的更改。如果您稍后决定重新提交您提交的内容,则基本上会使旧提交无效并对其进行所有更改。 - 即使你删除旧的分支,另一个可能会推动他的更改,因此也会推动旧的更改,这会导致重复的提交和解决混乱。 :) – michas

+1

再次,非常感谢。我一直在阅读关于'git pull --rebase',并不是100%,如果我在当前(比如说)'my_branch'中调用它会发生什么。在这种情况下,命令从'my_branch'遥控器拉出来,然后重新绑定到......哪个分支?因为我没有在命令中的任何地方提及它,所以我不会假设主人。 所以它必须重新绑定'my_branch',这对我来说听起来有点奇怪,因为我总是重新设计了两个独立的分支。但我认为这是可能的,现在我想起它,为什么不呢? – larryq

8

我会建议使用rebase工作流程。因此,而不是使用git pull您应该使用git pull --rebase

我会做同样的功能分支。所以,而不是做一个git merge master --no-ff我会使用git rebase master。但是,如果功能分支旨在在开发过程中与同事共享,则最好将主分支定期合并到功能分支中。

但说实话,我在一个小团队工作,如果我们需要一起工作在一个功能分支上,并且我们需要把它和主人一起更新,那么我们暂停我们的工作一段时间(并且沟通这个过程很清楚),主人和力量的重新组合推动特征分支。但是,对于更大的团队来说,这并不成比例。但是,我发现使用在主服务器上重新绑定的功能部件而不必处理来自主服务器的合并更方便。

请务必阅读。

Git workflow and rebase vs merge questions

相关问题