I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit.
Meh. I’d argue that info should be in a merge request, than in a commit comment.
Not certain how this organization does it, but a branch contain all the backstory and context. Commits are labels inside a branch, of which there can be many.
Well, there’s different workflows. Big organizations tend to meticulously craft these branches and then do a big bang merge at the end.
But for smaller organizations/teams, it’s usually more useful to merge as early as possible, i.e. work directly on a single branch together. This avoids complex merge conflicts and allows others to benefit from your work as early as possible.
In particular, smaller teams tend to also go together with smaller projects, where many features may be completed in a single commit, so there’s not much of a backstory to tell…
The proper way to organize a branch is as a logical sequence of sub-features - each represented by a commit. Ideally, the commits should not break the build while introducing its feature. In many such cases, each commit may have a back story - the tests you did, your decision process, online references (that apply only to that commit - something like stackoverflow answers), etc.
Branch messages don’t have the fidelity to capture such information. You may question the need for such detailed info. However, along with git blame and bisect, those commit messages are invaluable. I have lost count of how many times my own detailed commit messages helped me. And while I don’t usually look at others’ commits in such detail, I do read the details of commits that I’m interested in.
Git (and other VCSs) isn’t just a snapshot tool. It’s a history tool with the ability to capture history documentation. Honestly, Git is extremely underutilized in that capacity.
Meh. I’d argue that info should be in a merge request, than in a commit comment.
Not certain how this organization does it, but a branch contain all the backstory and context. Commits are labels inside a branch, of which there can be many.
Well, there’s different workflows. Big organizations tend to meticulously craft these branches and then do a big bang merge at the end.
But for smaller organizations/teams, it’s usually more useful to merge as early as possible, i.e. work directly on a single branch together. This avoids complex merge conflicts and allows others to benefit from your work as early as possible.
In particular, smaller teams tend to also go together with smaller projects, where many features may be completed in a single commit, so there’s not much of a backstory to tell…
The proper way to organize a branch is as a logical sequence of sub-features - each represented by a commit. Ideally, the commits should not break the build while introducing its feature. In many such cases, each commit may have a back story - the tests you did, your decision process, online references (that apply only to that commit - something like stackoverflow answers), etc.
Branch messages don’t have the fidelity to capture such information. You may question the need for such detailed info. However, along with git blame and bisect, those commit messages are invaluable. I have lost count of how many times my own detailed commit messages helped me. And while I don’t usually look at others’ commits in such detail, I do read the details of commits that I’m interested in.
Git (and other VCSs) isn’t just a snapshot tool. It’s a history tool with the ability to capture history documentation. Honestly, Git is extremely underutilized in that capacity.