At my recent GitKon talk, I spoke about git commit and what it means to have good commits.
git commit is a command used to commit your code to a s...
For further actions, you may consider blocking this person and/or reporting abuse
Why are you so fixated in writing what you did? The 'What' is perfectly visible in the diff. I can see, that you updated the README. What I do not see is 'Why'. Why did you add that information? More often than not the why is more interesting and tells a better story than the what.
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? ;)
The key here is making sure whatever you are doing is understandable to your team. The "Why" is a perfect example of what you are doing. I love this! If you team hows what and why this is a great example of being a team player ❤️
You are the perfect example of making the world a better place one commit at a time!
I think this line in the article sums this up: "Why are you 'saving' your code at this point in time?"
If you think I should be more explicit let me know and I'll add it in 😄
So informative, I love it! I do commit like:
I don't know if this is good way to do, but nobody complaint about it unit now on my team. thank you!
My pleasure. Yeah this is good. It shows what is happening, and I love the fact you add a category in square brackets ❤️
I was making the commits as you mentioned in your post, but reviewing pr's I didn't see useful this approach, because is explicit what are you doing in your code, but no much why are you doing that code, so you can get additional information to get a better perspective.
Yeah I love this. Definitely reviewing PRs is where you should write the information. Ie. when you have a pull request, all the information about what you are adding and WHY should be in the PR rather than each commit. The PR is often a collection of commits so having a why is super important. This is something you should have in your contribution guide if it's an open source project, and something you should have as part of your guidelines for corporate closed projects.
Is it possible to write multiple line of commit messages in vs code visually (via version control on side bar)?