Git commits aren't the perfect way to communicate change logs, however it gets better each phase.
Tell developers to add
#changelog in their commit messages, if they want a message to go as a change log.
Release notes post deployment can be generated with the command:
git log prevTag...newTag --no-merges --format=%B --reverse | grep "#changelog"
git log v4.2.5...v4.2.8 --no-merges --format=%B --reverse| grep "$changelog"
Branch naming conventions.
feature followed by appropriate commit messages will generate changelog in standard unix style:
- Fixed an issue with sandwich. It won't need sudo now.
- Removed the bug which paints your face.
- Removed the bug causing blood cancer.
- You can now talk to dead people, via single click.
- Allows bilocation. You can be sleep and attend classes, at the same time.
- You can now fly to Asgard.
With git flow in place and some issue-tracker, you should be able to map commits and issues correspondingly. So, if issue-tracker has commit id or commit has issue id, release notes will automatically add it in bug-fix or feature based on the tag applied in issue-tracker. This also helps in emailing the corresponding people who filed the bug, or raised the feature request.
Add a tool to auto-generate context and add release notes by it's own consolidation. Get a human for reviewing final notes, before publish.
Read developer's mind and generate automatically. A chip can be inserted in developer's mind and can be activated when (s)he thinks about or works on the project.
While phase 5 is prone to errors and may not be perfect, it works the best.