进行手动合并后，是否应该删除提交消息中的冲突列表？
假设我运行 git pull ，并且存在 git 无法自动合并的冲突。
在我手动合并更改并运行 git commit 后，我是否应该保留 git 在提交中生成的 Conflicts: 部分（作为手动合并这些文件的记录） ，或删除它（因为冲突没有被提交）？
我永远不确定最佳实践是什么 - 警告是为了确保您解决冲突，还是实际记录在提交消息中？
Say I run git pull and there is a conflict that git cannot automatically merge.
After I manually merge the changes, and run git commit, should I leave the Conflicts: section that git generates in the commit (as a record that those files were manually merged), or removed it (as the conflict is not being committed)?
I'm never sure what best practice is - is the warning there to make sure you fix the conflicts, or to be actually logged in the commit message?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这似乎是一个个人意见类型的问题，所以我会回答我的意见[-;
我保留了
冲突部分，以提醒大家这次合并产生了冲突。有时我没有正确处理冲突，稍后会产生一些不希望的效果，因此很高兴能够查看提交历史记录并看到文件中存在冲突。This seems like a personal opinion type of question, so I'll answer with my opinion [-;
I leave the
Conflictssection alone as a reminder down the road that this merge produced conflicts. Occasionally I don't handle the conflicts appropriately, and it will produce some undesired effect later, so it's nice to be able to look through the commit history and see that there was a conflict in a file.我认为最好的做法是始终描述您为什么要进行提交。当合并冲突时，我会声明你正在合并冲突。但我认为准确列出所有冲突是什么并不重要。始终考虑从现在起两年后重新阅读它：关于您正在承诺的内容，您想要阅读什么。这是很好的一般性建议，无论是关于冲突还是只是功能或错误修复。
I think the best practice is to always describe why you're doing the commit. When merging conflicts, I'd state that you're merging conflicts. But I don't think it's critical to list exactly what all the conflicts are. Always think in terms of re-reading it 2 years from now: what is it you'd want to read about what you're committing. This is good general advice, whether it's about conflicts or just features or bug fixes.