我们的团队在工作中热情地采用了一个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的成本很低。
然而，除了这一点，以及偶尔的纠正错误的英勇行动，我们已经超过了我们的疯狂。合并在大多数时候都很有意义。然而，肆意合并是有问题的，并且确实导致了我两年前所关注的混乱，混乱的历史。
我们的解决方案有几个组成部分：
主分支是＆＃34;原始＆＃34;。主题分支将合并，一旦完成，主题分支将停用。换句话说，合并主题分支表示该工作已准备好进行生产，现在是主分支的一部分。看看我们的版本历史，它非常清楚发生了什么：主题分支合并为主，以及那个。
我们在必要时使用一次性集成分支。例如，如果我们有主题分支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开头的提交等）。偶尔，我们确实需要做这些事情，所以包装器不会阻止它，但它确实让人们不小心做了他们不应该做的事情。
答案 0 :(得分：24)
听起来它过于复杂，不能很好地扩展。只是将master定期合并到您的功能分支中可能要简单得多，然后当合并回主服务器时，然后您可以先执行rebase（到删除中间不必要的合并）并合并回master（大概与--no-ff一起产生合并提交）。这只需要一个人处理rebase，他们不需要做任何协调，因为没有其他人需要强制更新任何东西（因为，可能是，分支将在合并之后被删除，而不是保留在重写的状态）。您也可以决定完全跳过rebase，只需保留中间合并，这样可以更准确地反映您的开发工作流程，并消除产生实际构建的提交的风险。