我们的团队在工作中热情地采用了rebase工作流程,但我们可能会有一点被带走,这就是这个问题的关键点:你是法官.
使用pull --rebase现在对我来说很简单.但是,我们还有多个人工作的大型功能分支.我们希望定期引入master上发生的变化.传统智慧会让我们合并,因为它是一个共享的分支.然而,在我们的反思中,我们决定改变那些分支机构.当然这需要大家的合作.工作流程如下:
1)rebaser与每个人协调,以确保他们全部签入并推入功能分支,然后要求他们不再在该分支上工作,直到他们全部清除.
2)rebaser将功能分支重新绑定到master上,删除远程功能分支(git push origin:feature),然后推送新的,重新定义的功能分支(git push origin功能)
3)rebaser让每个人都获取,更新他们的功能分支,然后删除他们的本地功能分支(git branch -D功能),然后创建一个跟踪远程功能分支的新本地功能分支.然后每个人都清楚了.
此工作流程正在运行,部分原因是我们是一个小组,工作中断很小.但是,我担心我们正在学习较差的Git习惯(重新定义共享分支),或者工作流程不能很好地扩展.
从好的方面来说,我们的存储库历史很可爱.
你觉得怎么样,Git大师？我们玩火还是摇摆合理的工作流程？
更新:
我问这个问题已经两年了,从那时起我的工作流程发生了变化.我们仍然经常做git pull --rebase,所以没有改变.这是常识,它可以防止所有难看的,令人困惑的迷你合并.(我们大多保持同步,所以成本很低git pull --rebase).
然而,除此之外,以及偶尔的纠正错误的英勇行动,我们已经超过了我们的疯狂.合并在大多数时候都很有意义.然而,肆意合并是有问题的,并且确实导致了我两年前关注的混乱,混乱的历史.
我们的解决方案有几个组件
主分支是"原始的".主题分支将合并进入,一旦完成,主题分支就会退出.换句话说,合并主题分支表示该工作已准备好进行生产,现在是主分支的一部分.看看我们的版本历史,很清楚发生了什么:主题分支被合并到主人,就是这样.
我们在必要时使用一次性集成分支.例如,如果我们有主题分支A,B和C,并且它们都没有准备好集成到master中,但是我们需要一起测试它们,我们只需创建一个QA分支(通常不在master下),然后合并A,B和C in.在某些时候,QA分支被删除或重新使用.关键在于它不是以任何方式永久保留,并且它与主分支没有相同的限制(您可以根据需要在主题分支中合并多次).如果历史变得过于混乱,您可以删除QA分支并重新开始(我们发现这种方法非常自然).
合并时,请始终使用git merge --no-ff.这与两年前我们对"线性承诺历史"的痴迷有着巨大的逆转,值得评论.现在我们已经放松了线性提交历史,并且看到合并是好的和有用的,我们已经开始依赖主题分支作为master的实际分支,而不仅仅是一系列提交最终成为master的提交. git merge --no-ff确保始终进行合并提交,即使没有必要也是如此.
我们对提交消息和分支有一个很好理解的约定,更重要的是,它交叉引用了我们的问题跟踪系统.我们的问题跟踪系统使用数字问题编号,对于任何功能(或缺陷),我们都有一个问题编号(例如1234).如果您正在处理该问题,那么您将创建一个分支_1234并启动每个提交消息"_1234: doing blah blah".它似乎有点过于强迫,但它确实对我们有效,并且显着减少/消除了混乱.
使用git包装器来鼓励工作流程粘合.这是我们目前正在努力的事情,但我们已经意识到完全有必要防止出现简单易懂的错误,例如分离出错误的东西(当开发人员从一次性创建主题分支时,我们最近遇到了彻底的灾难QA分支:该主题分支被批准上线,它被合并在......并且一些未被批准上线的转换器被吸入了.每当你做一些不寻常的事情时,我们的git包装器都需要确认(比如创建一个除了master之外的任何分支,创建一个不是名为_NNNN的分支,进行一个不以_NNNN开头的提交,等等).偶尔,我们确实需要做这些事情,所以包装器不会阻止它,但它确实让人们不小心做了他们不应该做的事情.
Lil*_*ard 24
这听起来像是过于复杂,不能很好地扩展.只是master定期合并到您的功能分支,然后当合并回主服务器,然后您可以首先执行rebase(删除中间不必要的合并)并合并回主服务器(大概是--no-ff为了产生合并提交).这只需要一个人处理rebase,他们不需要做任何协调,因为没有其他人需要强制更新任何东西(因为,可能是,分支将在合并之后被删除,而不是保留在重写的状态).您也可以决定完全跳过rebase,只需保留中间合并,这样可以更准确地反映您的开发工作流程,并消除产生实际构建的提交的风险.