【发布时间】：2017-11-17 11:02:24
【问题描述】：
为什么我们必须在 Git 中解决冲突后立即进行定期提交？
如果我在冲突解决后修改了一些其他文件，然后将它们一起提交怎么办？
有什么区别？
【问题讨论】：
-
我不是 100% 清楚你在问什么。你在问为什么告诉 Git 你已经解决冲突的命令没有像
git resolved这样的不同名称，而是你也用来进行正常单亲提交的git commit？
【发布时间】：2017-11-17 11:02:24
【问题描述】：
没有“区别”。
如果合并以一个或多个冲突结束，它会尽可能地合并，然后停止，通知您这些冲突。
解决这些冲突后，您的任务就是提交最终的合并提交。
原因是合并冲突解决步骤是通过调用其他 git 命令、外部冲突解决工具、手动和视觉检查文件等手动执行的。这不是一个交互式过程，因此 git 不会挂起在它正常提交之前等待你完成解决冲突。它只是说“我停在这里，完成后提交”。
如果除了解决这些冲突之外，您还进一步更改了磁盘上的文件并添加了这些更改然后提交，它只会将所有内容一起提交。这没什么特别的。
合并提交与任何其他常规提交一样，只是它（通常）有两个父级而不是一个，除了它是一个具有所有花里胡哨的完全常规提交。事实上，它是由 git 执行的合并操作，准备了提交引入的所有更改，这只是一个细节，您可以通过暂存正确的更改并告诉 git 与两个父级提交来手动 100% 自己构建合并提交。
因此，您进一步修改文件与不这样做之间的区别在于，合并将包含更多更改，而仅包含 git + 冲突解决添加的内容。
不多也不少。
【讨论】：
-
抱歉在这里发表评论，但不确定如何在评论中标记您的名字。您关闭我的问题和相关答案并没有说明如何修复 Deserealize 部分。
您必须进行提交，因为合并的最后一步是（通常是在幕后）提交，当存在冲突时，git 会退出该步骤。因此，与其针对这种情况创建新的命令或子命令，不如决定让您在整理完索引后完成最后一步。
您可以进行冲突解决以外的更改。有时这对于正确解决冲突是必要的。 git 不可能“知道”您所做的更改是否真的需要解决冲突。我想它可以检测到不在冲突标记内的更改并发出警告，但是硬停止会阻止在某些冲突情况下的合法解决方案，而且似乎不值得付出额外的努力参与警告。因此，开发人员被信任去做他们应该做的事情。
此外，您是否知道您可以专门告诉 git 不要提交合并，以便您可以在提交之前编辑合并结果（即使没有冲突）？你可能不应该，但你可以。
请注意，在合并中进行并非实际冲突解决的更改可能会在以后产生负面影响，因为这些更改在某种程度上“隐藏”在合并提交中，因此您必须知道要查找它们。
但是 git 是一个强大的工具，通常它希望你知道如何使用这种能力。与您想要的父母一起提交您想要的内容的能力是这种权力的一部分。
【讨论】：