是否可以提交不完整的合并？我解决了一半的冲突。我同事的另一半更有资格应付。
也许同样好，甚至更好，是获取冲突块并将它们恢复为处于冲突状态的文件。然后，我可以使用冲突块提交合并，而我的同事可以抓住它，将文件恢复为“冲突”状态，然后从那里获取文件。
答案 0 :(得分：1)
简短的回答是“不，不可能”。
我一直在意要尽可能接近一个脚本。解决冲突期间，索引中每个文件有三个副本，而工作树中有四个副本。 （在HEAD中添加不可更改的副本，实际上每个文件都有五个有效副本-但我们只需要保存其中四个，因为{{1}中的一个}不能更改。）可以像HEAD那样保存每一个，这将允许通过常规Git机制传输“隐藏的进行中合并”。 1 这将涵盖大多数案例。但是，在部分解析的合并过程中，索引中有一些特殊信息（“ REUC”撤消条目）根本无法保留，并且 all 合并均无法记录有关高层冲突（例如重命名/重命名冲突）的一些重要信息，在执行此操作之前确实应该以某种方式公开。
如果您不需要撤消条目，那么我未编写的脚本可能可以解决问题，但是，我还没有编写它。 :-)但是，基本思想是将当前（合并冲突的）索引读取/复制为三个或四个无冲突的临时索引副本：每个阶段1条目一个，每个阶段2条目一个，以及每个阶段1条目。每个阶段3的条目。尽管也可以在此处使用原始索引，但对于所有0级条目，我们也都需要一个。添加最后一个临时索引以保存实际的工作树状态git stash，并在其中完成包含冲突标记的文件（如果有人使用{{1}，则可能对未跟踪的文件进行w提交） }？）。从所有临时索引文件中进行提交，以某种有用的方式将它们绑在一起，并向u提交，就像git mergetool从其HEAD和{{ 1}}提交。然后，执行git stash，就像执行i一样。
要恢复冲突状态，请先确保一切都干净，然后将每个提交读入临时索引。使用生成的索引文件来构建新的冲突索引，并在相应的阶段0、1、2和3中输入条目。使用工作树提交从保存的合并w提交中建立工作树状态（实际上可能首先这样做）。
1 今天在存储库之间传输git reset --hard提交在技术上是可行的，但是git stash的前端和内部工作方式使其有些棘手。由于此脚本（或至少是 a ）的要点是使传输正在进行的合并变得容易，因此无论脚本是什么，都需要提供一种机制和一些明确的指令来执行这个。