Git-在处理具有多个团队成员的共享分支时重新设置基础/合并？

我最近换了一个新的雇主，在那里我们在更大的团队中工作，我们在功能方面与多个开发人员合作。按照Vincent Driessen的工作流程，我对在处理这些共享功能时如何处理合并/重基感到有点困惑

在我以前的雇主，我会创建自己的（本地）功能分支，每天从

master

重新设置基础。在这里，发布特性分支并从其他分支中引入更改是常见的做法。我的大多数同事都使用默认的git pull设置（这会导致合并，使用pull合并会污染分支历史）。我个人更喜欢使用

pull.rebase=preserve

设置来保持历史记录的干净，但这可能不适合他们的方法

我很困惑什么是正确的处理方法。我知道我不应该重新设置已发布分支的基础，所以我正在寻找一些反馈

这样做的正确方式是什么？我在考虑为每个功能创建一个分支（

featurexxx

），然后让每个开发人员从该功能分支（

localxxx

）创建自己的（本地）分支。他们可以正常工作，然后使用

--ff only

将其更改合并回

功能XXX

分支（在重新设置

本地XXX

的基址后）

这让我想知道：我如何才能防止

功能XXX

过时？我是否定期将

母版

合并回它？或者我会时不时地重新设定基准？这会对我的同事的分支机构产生什么影响

---

另一个提到定期将

master

合并到

feature XXX

中，并且仅在合并重新设置基础之前

我不确定您的

local

分支是否在增加任何实际价值。我假设您想要它们的原因是，您可以遵守团队策略中的字母“推动您的特性分支”；但是如果你将他们期望的功能分支上的工作转移到“本地”分支上，那么你就没有遵守政策的精神。另一方面，如果实际上不需要推动特性分支工作，那么根本不需要本地分支。（我马上解释原因。）

作为一名“新人”，加入了一个推动工作流程的项目特征与您过去经验不同的环境，我鼓励您花一些时间在这个团队的既定程序中工作。如果没有其他问题，这将让您体验到他们方法的缺点（如果您想说服团队改变，可以从中构建案例）。（不过，我不得不说，如果“合并就是污染”是你论点的全部核心，那么我最多只能站在那场辩论的“不在乎”阵营里。但我离题了……）

不管怎么说，你说了一些关于不重定被推的分支的话，这几乎是对的。（这是一个很好的经验法则，它会让你远离麻烦。）一个更完善的规则是，“不要以删除已推送的提交的方式重新设置基址”。或者“不要以将远程引用移动到无法访问其上一次提交的提交的方式重新设置基址”

因此，如果您在共享分支上，但不推动本地工作，那么使用基于重基的拉取是安全的，因为唯一要重写的提交是本地提交（将它们放在“获取的远程提交”之后）。缺点是，如果您有多个不想挤压的本地提交，并且您不想冒险推送一个会破坏构建的中间状态，那么您必须测试每个这样的中间提交。（国际海事组织的“违约承诺”——即使是中间承诺——比合并承诺更严重。）

---

从逻辑上讲，如果您创建了“本地”分支，那么在您将它们重新设置到主功能分支上之前，工作不会得到共享，因此实际上是一个分支中的六个分支和另一个分支中的六个分支。一旦你推送了提交，你就不能再对它重新设置基址，但是如果你一直在做基于基址的拉取，那就没关系了。

重述一下你说的：我可以继续做基于基址的拉取，而不会有太多问题。一旦我推动了我的提交，它们就成为上游分支历史图表的一部分，而重定基址也不会做任何事情，因为它是图表的一部分。比如说，大师的作品如何融合？我们会不断地将大师级的作品合并到（已发布的）功能分支中，还是会重新设置基础？或者，正如我在文章的第二个链接中所说的，在将我们的更改合并到主功能之前，不断地在主功能中合并，并重新设置功能分支的基础？如果一个分支是长期存在的，我会定期将主功能合并到它。用rebase做这件事真的不是一个好方法。您可以进行“挤压合并”，但当您最终将功能分支合并回主功能时，您将得到许多无意义的冲突。有些人不喜欢master的“无用的重复”合并，如果你在那个阵营，你可以看看git Reere（它允许你进行合并、测试、退出合并，然后在不手动重新解决冲突的情况下重新进行合并）。IMO的问题是，这再次使您容易破坏提交，但这是一种选择。