If you're working for a company (and therefore a repository shared amongst a team) - the "why" is often "because there's a ticket that needs doing."
For that, we use the ticket reference as the branch name (feature branching, in effect). That one piece of information, tells the reviewer "why" that change is being done, and allows them a convenient way to check the "what" vs the requirements given.
So we actually use the git commit as "a non-technical summary of the change" - which later in the build/release pipeline, we collate commits between release X and Y, build a changelog from the commit messages, and notify others in the business.
The "what" is the diff, the "why" is the ticket we're working on, the commit message itself then tells others in the business "when" this feature was available to them. We get a human readable changelog for free, just by making commits.
I know this strategy and it is better than, 'Updated README'.
Unfortunately ticket references might be short lived (new ticket system) or not always accessible (only available online and with vpn). So I would not rely too heavily on this.
Short non technical description sounds good though.
If you're working for a company (and therefore a repository shared amongst a team) - the "why" is often "because there's a ticket that needs doing."
For that, we use the ticket reference as the branch name (feature branching, in effect). That one piece of information, tells the reviewer "why" that change is being done, and allows them a convenient way to check the "what" vs the requirements given.
So we actually use the git commit as "a non-technical summary of the change" - which later in the build/release pipeline, we collate commits between release X and Y, build a changelog from the commit messages, and notify others in the business.
The "what" is the diff, the "why" is the ticket we're working on, the commit message itself then tells others in the business "when" this feature was available to them. We get a human readable changelog for free, just by making commits.
I know this strategy and it is better than, 'Updated README'.
Unfortunately ticket references might be short lived (new ticket system) or not always accessible (only available online and with vpn). So I would not rely too heavily on this.
Short non technical description sounds good though.
If a new ticket system comes in, a new feature branch (from the previous feature branch) is easy.
If the ticket system isn't available, remote changes probably aren't either, so a PR / MR isn't possible.
Yeah, but the code and the repo is there. I can work, but not understand the commit 😉
It's a bit of an edge case, but living in Germany and traveling by train teaches you not to rely on your internet connection 😅
Isn't that the edge case that gave rise to the ability to edit commit messages after the fact? ;)