如何在git monorepo中进行合并？

问题描述

假设我在产品A上工作。我的同事在产品C上工作。每个产品都依赖于两个产品（库B）之间共享的库。

这些组件以传统的monorepo方式作为一棵扁平树存储在SCM中。

我和我的同事开始开发一种功能，该功能会影响所有三个组件。因此，我们从主干创建了一个分支，然后开始使用该功能。此功能需要一些时间，并且需要多次提交。每次提交都会影响同一提交中的A和B组件，或者同一提交中的B＆C组件，或者分别影响这三个组件之一。

最后，我们使该功能在两种产品之间起作用，是时候将其合并回“行李箱”了。由于在开发分支上花费的时间，所有三个组件在主干分支上均已更改，从而使此合并成为“大”合并。

问题是，我没有资格处理组件C（不是我的产品）的合并。我的同事无法处理组件A（不是他的产品）的合并。

在像Subversion这样的SCM中，可以逐个文件地进行合并，这不是问题。我可以合并A＆B，然后我的同事合并C。但是在Git中，这是不可能的。这是因为Git仅在提交级别执行合并，因此将尝试同时合并所有三个组件。那么我们如何将分支合并回主干？

我的第一个想法是以某种方式重写历史记录，或者将每棵树分离到它自己的分支中，或者通过对提交进行重新排序，以使所有A提交都是连续的，然后是B提交，然后是C提交。这将使我们能够进行单独的合并。但是后来，我们失去了最初发生的一切。有可能新的提交无法建立，或者测试无法进行。为了使用该系统，我们不得不失去所有这些，这对我来说似乎不是一个很好的权衡。

另一个选择是让我们俩在一起在同一终端上进行合并。 （说实话，这可能不是一件坏事）。但是，如果我的产品出现问题，需要花费一些时间来处理，那么我的同事也会被推迟。

我知道像Microsoft这样的公司都有git monorepos。他们如何处理这个问题？

解决方法

考虑PR，您可以创建PR，并请您的朋友查看与他们命令相关的部分...。如果有意见，请您多加注意，直到大家满意为止。

,

我认为基本的答案是，合并必须在单独的分支中进行，在合并到“主干”之前，该分支允许混乱或不完整。

另一种解决方案是团队遵循基于主干的开发（请参见trunkbaseddevelopment.com），并将工作分解为较小的块，可以通过功能标记等随意打开和关闭这些块。