暂时跳过子模块中的提交

Question

假设现有的Git跟踪模块（M）具有提交M1-M2-M3。

我有一个应用程序（A）的Git存储库，提交A1-A2-A3。存储库包含M作为子模块（git submodule add URL DIRECTORY），但它不是最新的M - 而是使用较旧的提交M1（subproject commit 187cac115b5f4fdeb39c25c79e882d30ee9624be）。

我的问题是：我想使用提交M3的内容，但有一段时间我不能使用提交M2。这种限制最终会通过，但目前它是无法克服的。那么，我的选择是什么？

如果M不是子模块而是A的一个分支，那将很容易：

1. Cherry-pick M3进入A3，形成A4。
2. 当M2的限制通过时，将M3合并到A4。

有了子模块，我不知道。唯一的＆＃34;直接＆＃34;我能想到的解决方案涉及以下步骤：

1. 在M1处创建分支B.
2. Cherry-pick M3进入B，形成M4。
3. 将B合并到M3，形成M5。
4. 将M推入其存储库。
5. 在A中，更新M。
6. 在A中，结帐M4。
7. 当M2的限制通过时，结账M5。

然而，这涉及M的变化，这很大程度上取决于M的所有者是否愿意接受他们，他没有真正的理由（因为这些变化不会带来任何变化）但M）的额外复杂性。我更倾向于一个我不必强加给M的解决方案。

有间接解决方案，可能：

1. 在M3处创建分支B.
2. Reverse-commit M2进入B，形成M4。
3. 将M推入其存储库。
4. 在A中，更新M。
5. 在A中，结帐M4
6. 当M2的限制通过时，结账M3。

这对M的侵入性要小得多，这很好。然而，它使分支B永远不合并，我认为这是一个非常糟糕的情况（因为我使用未合并的分支列表作为一种＆＃34; TODO列表＆＃34;）。

处理这种情况的最佳方式是什么？

感谢。

Answer 1

您可以通过在不再需要时删除它们来避免使用未合并的分支。

我会发现你的第一个解决方案很奇怪，因为M5是一个基本上没有附加价值的合并。它会污染您的版本历史记录。

我要做的是：

1. 在M1处创建分支B.
2. 樱桃挑选M3进入B，形成M4。
3. 将B推送到存储库
4. 在A中，结帐M4。
5. 当M2的限制通过时，使用old_something标记M4，按下标记，然后删除分支B（也来自远程仓库）。

这样，与另一个人的回购的唯一交互是你创建一个新的（临时）分支，然后他留下了一个标签（没有未合并的分支，但是一个标签。没有真正的区别，但如果你使用todo列表的未合并分支，这解决了你的问题）

实际上，我会说子模块的情况是更好而不是A的分支。您现在不会通过不必要的合并来污染您的版本历史记录。