Should I remove the list of conflicts in my commit message after doing a manual merge?

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?

This seems like a personal opinion type of question, so I'll answer with my opinion [-;

I leave the Conflicts section 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.