在 git 中合并期间分布式冲突解决的最佳方法是什么？ 故意部分提交 没有好的方法可以做到这一点Git 可以做到这一点，只要你能提交冲突

如何解决在 git 中合并期间分布式冲突解决的最佳方法是什么？ 故意部分提交 没有好的方法可以做到这一点Git 可以做到这一点，只要你能提交冲突

假设如下：

1. 由多位设计师（DesignerA、DesignerB、DesignerC ...）组成的团队。

2. 主分支master

3. 两个功能分支featureA，featureB。

4. 在特征A中：
   4.1. DesignerA 修改./fileA。
   4.2. DesignerB 修改./fileB。
   4.3. DesignerC 修改了 ./fileC。

5. 在特征B中：
   5.1. DesignerA 修改./fileA。
   5.2. DesignerB 修改./fileB。
   5.3. DesignerC 修改了 ./fileC。

6. DesignerC 将 featureA + featureB 合并到 master 中：
   6.1.将 featureA 合并到 master：
   fileA、fileB 和 fileC 的更改会自动合并。

   6.2.将 featureB 合并到 master： fileC 的冲突由 DesignerC 解决 fileA+fileB 冲突，但设计者 A 拥有文件 A，设计者 B 拥有文件 B。

我的问题：

DesignerC如何通过部分合并的commit，让每个设计师解决自己的冲突？

说：

• 发送给设计师A：
  • 已解决 fileC
  • unresolved fileA - 处理
  • unresolved fileB - 保持未解决
• 发送给设计师B：
  • 已解决 fileC
  • unresolved fileA - 保持未解决
  • unresolved fileB - 处理
• 合并解决方案并推动掌握。

注意：

• 团队尝试尽可能简单地使用 git - 请避免在答案中使用花哨的 git :)
• temporary branches 的解决方案不是我想要的。

解决方法

没有好的方法可以做到这一点

这并不意味着您根本无法做到，但是您可以做到的所有方式目前都相当糟糕。基本问题很简单，根据您的计数方式，可以分为三个或更多部分：

• 您只能推送提交。
• 冲突解决发生在 Git 的索引中。
• 新提交是根据 Git 的索引进行的。
• 在解决所有冲突之前，您无法进行新的提交。

用户可以使用他们的工作树文件和/或插入到他们工作树或其他任何地方的附加文件来帮助解决，但从根本上说，存在冲突因为Git已经修改了它的索引，以便某些条目标记为“冲突”。要取消标记条目——以便你可以进行新的提交，前提是这是最后冲突——你必须解决冲突。

因此，要提交您可以发送给其他人以便他们可以解决他们部分冲突的提交，您必须首先解决所有部分冲突.现在你可以提交和发送提交，他们可以...... uhhhmmmm......撤消你对他们部分冲突的解决？除此之外，没有冲突了。

Git 可以做到这一点，只要你能提交冲突

不幸的是，您不能提交冲突。但是所有工具都存在于 Git 生态系统中。存在冲突是因为 Git 的索引具有非零阶段索引条目。用户的工作树也有可能代表部分分辨率的跟踪和/或未跟踪文件。如果我们能够获取其中的每一个——非零阶段条目，以及跟踪和未跟踪的文件——并利用它们进行提交，然后使用这些提交重新组合冲突的索引和工作树内容稍后，我们将拥有您想要的内容。

git ls-files --stage 输出显示了 Git 索引中实际存在的所有内容。我们只需要编写一个程序来获取此输出并创建多个单独的临时索引（每个索引不冲突，但允许另一个程序稍后构建新的冲突索引）并提交这些，以及另外一个或两个提交以保存工作树状态。这种大量提交——无论需要多少次来保存阶段 0、1、2 和 3 条目¹ 加上工作树状态——可能最好表示为一个伪造的合并，一个la git stash，然后通过一些参考为临时解决的状态建立索引，这些状态可以恢复以稍后恢复合并，refs/stash 的 la git stash。

与 git stash 的相似之处很明显，并且实现可能在某种程度上借鉴了旧的 git stash shell 脚本。这些提交的确切格式，以及要使用的一个或多个引用，需要一些思考和实验。

这个命令今天不存在。

---

¹理论上，例如，当索引中的第 1 阶段存在冲突条目时，可能会有多个文件具有某个特定名称，例如 path/to/file.ext。这将代表多个合并基础。实际上，Git 似乎没有利用这一点，如果确实利用了这一点，则不清楚如何知道 path/to/file.ext 的哪个版本与哪个合并基础一起使用：每个具有 stage-1 条目的文件必须有 N 个这样的条目，其中 N 是合并基的数量？例如，如果合并基数 #1 没有名为 path/to/file.ext 的文件，但合并基数 #2 有，那么索引槽中的哈希值会是多少？

这一切都会影响我们为处理这个问题而进行的 in-progress-merge“合并提交”的设计。

,

单独使用 git ：您不能共享冲突，我想到的解决方案包括创建临时分支，让每个设计人员独立修复其部分，然后将这些更改组合在一起。

---

其他解决方案：

• 让三位设计师处理同一个 repo 克隆（例如：亲自走到办公室、远程连接到工作站、在普通 ssh 机器上工作......）

• 如果文件数量很少（如您的示例中每个设计师一个文件？），请发送所述文件的“基本/我们的/他们的”版本的副本，并要求发回分辨率