我最近转到了一个新的雇主，我们在更大的团队中工作，我们与多个开发人员合作开展功能。遵循文森特·德里森的A successful Git branching model所描述的工作流程。在处理这些共享功能时，我对如何处理合并/重组感到困惑。
在我以前的雇主处，我会创建自己的（本地）功能分支，我每天都会从master进行修改。在这里，通常的做法是发布功能分支并从其他分支中获取更改。 Most 我的所有同事都使用默认的git pull设置（导致合并，使用pull-merge来污染分支历史记录）。我个人更喜欢使用pull.rebase = preserve设置来保持历史记录清洁，但这可能不适合他们的方法。
我很担心处理这个问题的正确方法是什么。我知道我不应该重新发布已发布的分支，所以我正在寻找一些反馈。
这样做的正确方法是什么？我正考虑为每个功能创建一个分支（feature-XXX），然后让每个开发人员从功能分支（local-XXX）创建自己的（本地）分支。他们可以正常工作，然后使用--ff-only将他们的更改合并回feature-XXX分支（在重新定位local-XXX之后）。
这让我感到疑惑：我如何防止feature-XXX陈旧？我是否定期将master合并到其中？或者我不时给它做什么改变？那会对同事的分支产生什么影响？
另一个Stackoverflow post提及定期将master合并到feature-XXX，并且只有才合并合并。
答案 0 :(得分：2)
我不确定您的local分支机构是否正在添加任何实际价值。我假设你想要它们的原因是你可以遵守团队政策中的“推动你的功能分支”的信件;但是如果你正在将他们期望的工作转移到那些特色分支到“本地”分支，那么你就不会遵守政策的精神。另一方面，如果您实际上不是 required 来推动您的功能分支工作，那么根本不需要本地分支。 （我会在一分钟内解释原因。）
作为加入营造工作流程的项目特征与过去经验不同的环境的“新人”，我鼓励您花一些时间在这个小组的既定程序中工作。如果不出意外，这将为您提供他们的方法的缺点（如果您想说服团队改变，可以从中构建案例）。 （不过，我必须说，如果“合并提交是污染”是你论证的全部症结，那我最多只能参加那场辩论的“不关心”阵营。但我离题了......）< / p>
无论如何，你说过一些关于不推销已推出的分支的事情，这几乎是正确的。 （这是一个不错的经验法则，它可以帮助你摆脱困境。）一个更精确的规则是，“不要以一种消除被推送的提交的方式进行重组”。或者“不要以将远程引用移动到无法访问其先前提交的提交的方式进行rebase”。
因此，如果您在共享分支上，但是您没有推送本地工作，那么您可以安全地使用基于rebase的提取，因为唯一被重写的提交是您的本地提交（将它们放在“取出的远程”之后）。这样做的缺点是，如果你有多个本地提交，你不想压缩，并且你不想冒险推动会破坏构建的中间状态，那么你必须测试每个这样的中间提交。 （而IMO“破损的提交” - 即使是中间的 - 比合并提交更糟糕的“污染”。）
从逻辑上讲，如果你创建了“本地”分支，那么在你将它们重新分配到主要特征分支之前，工作将不会被共享，所以它实际上只有六分之一和另外六分之一。一旦你推送了一个提交，你就不能再修改了它，但是如果你一直做了基于rebase的拉动，那么它就没关系了。