Change log from git commits

Git commits aren't the perfect way to communicate change logs, however it gets better each phase.

Phase 1:

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"

Ex. git log v4.2.5...v4.2.8 --no-merges --format=%B --reverse| grep "$changelog"

Phase 2:

Branch naming conventions.

bugfix, hotfix, feature followed by appropriate commit messages will generate changelog in standard unix style:

Example

=====

Fixes:

• Fixed an issue with sandwich. It won't need sudo now.
• Removed the bug which paints your face.
• Removed the bug causing blood cancer.

New features:

• 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.

=====

Phase 3:

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.

Phase 4:

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.

Phase 5:

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.