2012-06-29 71 views
10

读完这篇文章后,是有意义的变基收集到我的特性分支从主分支的变化: Git workflow and rebase vs merge questionsGIT重建一个合作的分支?

clone the remote repo 
git checkout -b my_new_feature 
..work and commit some stuff 
git rebase master 
..work and commit some stuff 
git rebase master 
..finish the feature 
git checkout master 
git merge my_new_feature 

这个伟大的工程,如果特性分支是本地的我的机器,我可以改写我喜欢历史。

但是,如果我在功能分支上与其他人协作,该怎么办?现在我们的功能分支被保存在远程存储库中,我们如何从主分支获取最新的变化到我们的功能分支?

那么我们合并?或者是否有另一种灵活的GIT方法来做到这一点?

在此先感谢!

回答

1

如果你单独工作,rebase什么也不做。你没有提交任何新的主人。

您的合并将是一个快进合并,你可以通过不检查出来有

git push . HEAD:master 

在所有无论你是与他人工作或没有,合并的工作,是在掌握到您的功能做分支是一个不好的做法。它被称为反向合并。不好的原因是你现在没有一份原子能工作。大师的历史现在与您的功能纠缠在一起,使用这个功能,比如重新绑定,在许多情况下都是不可能的。

您需要考虑分支策略以及您想实现的目标。这里是我的:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

你可以看到,每个分支开始从同一个地方。您有一个单独的集成分支和发布候选分支来混合和匹配您想要的功能,同时不会污染它们。

至于与同事合作的一项功能,取决于功能的多大(工作的粒度)。如果它很大,您可以将上述过程应用到该功能本身,并将每个任务分支。

如果这是一个小功能,您可以在该分支上合并或重新绑定 - 这并不重要。在这一点上,这取决于球队的感受。

+0

Dynmitruk:感谢您的文章和链接。从链接看,这听起来像樱桃采摘即将尽可能接近解决方案。感谢您的时间! –

2

没有切换到完全不同的工作流程,您的案例有解决方案。

关于从主分支到功能分支获取修复程序,正如您已经发现的那样,最好的方法是挑选那些特定的提交。但我更愿意拥有主题分支,即使是修补程序而不是在主线中修复,这样我就可以正确合并修复它们所阻塞的每个功能。

为了保持功能开发历史尽可能的干净和线性,所有合作者都必须使用git pull --rebase来获取更新,以避免无意义的合并提交。

如果您仍然想要通过当前主开发分支(用于持续集成测试或其他目的)重建合作特性分支或以任何其他方式重写其历史记录,则可以在特性完成/完成后执行此操作在合并到主分支之前,但您应该在新的独立本地/私人分支中执行此操作。

这里是如何从主重新创建的话题在一个新的分支变化(跳过樱桃纬):

$ git checkout -b feature_final feature # jump to a new branch for grooming 
$ git rebase [-i] master    # rebase topic changes onto master 

从那里是你做什么用衍合分支-push上游对于质量保证或直接合并为主人(如果您希望在历史中明确指出,则使用--no-ff)。