Keep a Changelog
Projects that still insist on maintaining a changelog file in git end up constantly fighting git's conflict resolution, and they make rebase almost completely unusable.<p>For an actual log of individual changes, that's what "git log" is for; any project that pre-dates git should "git mv ChangeLog ChangeLog.pre-git".  And if your "git log" output isn't highly readable, write better commit messages and group changes into more logical commits; once you stop breaking "git rebase -i", that gets a lot easier.<p>Some of this advice potentially makes sense, but for a NEWS file, not a changelog.  A NEWS file has one top-level heading per release, containing the release notes for that release, summarizing the key user-visible changes.  However, that file should <i>not</i> attempt to track every change, should <i>not</i> contain times or dates, and should get grouped in logical chunks rather than chronological order.<p>And while it can potentially make sense to update that file as part of the commit introducing a new user-visible change, that also reintroduces the same conflict and collaboration issues as a changelog, so personally I only update NEWS files right before a release.  I run a script that generates a properly formatted NEWS entry based on the version and git commit messages (turning each one into a markdown bullet-list entry with indentation), then edit the result to add headings, group entries under those headings, and delete any non-user-visible changes that don't merit a release note.