如果仍然存在未解决的冲突，是否有一种方法（最好是MacOS上的iTerm2）禁止提交/推送？在大多数GUI中，禁止发送未解决的冲突，但在命令行中则不允许。
我有很多使用CLI的开发人员，有时他们会推送未解决的冲突，在编辑器中使用git的人不会遇到此问题，因为编辑器不允许这种情况发生。
感谢您的见解：）
答案 0 :(得分：2)
这可能有点发麻，但是git 确实需要解决所有冲突，然后才能完成提交。但是，从git的角度来看，“已解决”表示“用户已针对包含冲突的路径发出了git add命令”。如果用户在保留冲突标记的情况下说“这已解决”，则git并不认为会更好。
坐在git之上的编辑器基本上没有什么不同。他们可能以不同的方式呈现冲突，或者以某种方式控制解决方案工作流程，即用户将不得不跳过箍以故意在完成的内容中留下冲突标记。但是，如果用户从字面上说解决的内容是
>>>>>>> their version
some change
-------
different change
<<<<<<< our version
任何通用工具都不能推翻它。
我的建议是，如果用户在不应该使用冲突标记（当然，几乎总是不应该使用）的情况下提交冲突标记，则可能是一个培训问题。我鼓励他们要么更多地了解git冲突解决方法，要么使用其他开发人员使用的其中一些工具，以使您更好地保护他们免受这些错误的影响。我认为，如果用户花时间学习足够好的git以使用命令行，那么他们将充分利用git的功能，但是如果他们不这样做，则可以在可能发生的众多错误之一周围添加“安全性”对命令行工具了解不足的使用……还不全面。
如果您仍然想增加这样的安全性，最好的选择是使用git hooks。您可以在源仓库中添加一个预接收钩子，这样它将拒绝任何包含提交的推入，这些提交包含包含冲突标记的文件。您还可以将其供个人存储库用作预提交过滤器，这样他们就可以及早发现错误，而不必等到他们试图承诺意识到自己的历史记录很差。
请注意，这样的挂钩对允许的内容进行了假设。如果脚本编写得当，这些假设并不算离谱。对于许多类型的内容，确实没有 提交冲突标记的充分理由。但是，作为一个（有点愚蠢的）示例，如果某人需要提交描述冲突状态的.txt文件，您的脚本是否能够分辨出这种差异并让其通过？
对于额外的安全层而言，潜在的优势案例是否值得，您只能为自己的项目回答。再次，我的建议是改为解决您的用户为什么首先犯这些错误的原因。