Storytelling with ‘git log’
The git log command can be a very useful tool to tell a clear story of the evolution of your Software. In fact, a single read though it can be enough to understand the how and the why of the current state of your project. Take into account the following options:
Follow a chronological order
Commit the changes in a chronological sensible order. Commits focusing on related components of your application should be recorded one after another. Following the history of a file should be as smooth as possible.
Use both, the short and the long message features of the commit command to record a clear explanation of what, how and why has changed. Don't be afraid of being verbose. Reading the messages should be enough to understand a change, and using the diff tool should no longer be necessary.
Separate the commits by type and context: a refactor, a fix, a typo correction. Separate actual logic changes from coding style changes.
By branching off, you create a sub-story of a certain change. The merge commit then indicates when that sub-story crossed paths with the main story.
Good organized commits can be used to teach and to learn. Think of it as a step-by-step tutorial, tracking the exact changes of a component.
# Git commands git add --patch git add --interactive git commit --amend/--interactive/--squash/--fixup git rebase --interactive # Pretty log alias: git log --pretty='format:%Cgreen%h%Creset %s' --graph
After all, which of the following logs tells you a better story: