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.
来源：https://stackoverflow.com/questions/5414477/should-i-remove-the-list-of-conflicts-in-my-commit-message-after-doing-a-manual