Very though out set of guidelines, thank for this. As I learn more optimized workflows and git usage solely through terminal these days I have come to the realizations that even the tips mentioned here seem obvious and considered good practice among many professionals they arent necessarily used by majority. So I do believe all of this is subjective to an extent because using git as objective means to accomplish version control and just that. I personally like conventional commits and have for years because of its simplicity. Keywords such as feat, fix, build, and docs tell me already what I need to know when searching history or how to version next release.
I've noticed that I split commits and make very verbose but clear messages for each commit, only to never use this afterwards.
Meanwhile my coworkers just commit with "lol" and get the same result. What I learned from this is that you don't need to split commits, just commit everything at once and add a "good enough" message. E.g. if you're working on a provider just use "Updated provider"
You migrate relevant parts of that diff into your workdir, test and commit.
Is it that hard? What is this question even? Do you lose consciousness and project awareness in these cases? Why someone must split all the work before it's needed, when it's only needed in 0.01% of all cases? Why wouldn't you do this job when the need to rollback arises? Good arguments for commit granularity exist, but this one makes little sense, like many others.
I've never worked on a team that had conventions for both commits and PRs. In general, the goal of such things is to help trace work across multiple systems, and for future research trying to track down old changes. All the places I've worked or consulted, they do that at the PR level, not the commit level. So PRs will start with a ticket #, commits are freeform.
That being said, some places do have commit standards. Just ask the team what they do when you start somewhere. Don't bring conventions in where a team doesn't use them - it just adds noise. If you or the team see how adding conventions can benefit your work, talk about it and make a decision together.
Good thing Microsoft has never been evil. Otherwise, one might be concerned about locking up your project's history in Github's/Microsoft's proprietary issue tracker (embrace, extend, extinguish!) rather than open source tools like Git that you can migrate out of.
Oh gosh yes, that sure would be dangerous to lock everything into Github. I've never worked on a team that did so, though. To be honest, I've never used Github's issue tracker at all. Seeing as PRs are also commits when they merge, PR-level tracking migrates just fine to any other system you'd like.
My advice is never use conventions for personal/solo projects - they do not matter.
When it comes to working in teams I actually do recommend them because during a code review you can - at a glance - read what each commit has done so you can familiarise yourself with the steps the developer took to reach the state in the PR.
For small teams I'm a big proponent of slimmed down version of Conventional Commits' standard. At our startup we would only really use these types: fix/feat/chore/docs/refactor/revert/ci/test.
Something simple like:
fix(ControlPanel): popover animation no longer causes layout shifts
Depends on the size of the project. Some informal convention can be pretty helpful when a personal projects gets sufficiently large, to the point where you may at some point have to look at the git log.
Yes you are right, well said! I suppose it's key to look at your project from a birds' eye view and try and estimate how large scale you expect it to be.
If you're building the next open source self-hosted facebook, yeah I think a convention is necessary. However, if you're building "my calculator app in Rust" then you're probably okay just doing commits "abcd123" just so that you can have remote code storage :^)
The only "convention" that exists is the Conventional Commits' one. It is sensible and compatible with some tools. As long as you write "fix:", "feat:" or "chore:" you'll be fine.
Don't overthink it though, it's a thing that is used in some open-source projects and companies. As long as you follow the rules of the project, you'll be fine. Same for the coding style and format, do like everyone else.
Half of it is automation to generate pretty changelogs if an audit ever happens. The other half is to make sure that devs know that rules are set in order to make them think about what they are doing. It seems a bit restrictive, but it's a good way to say "your commits should be clean and focused on one topic and one topic only."
Doesn't matter much. What works for me is it's easily skimmable. Rather than say "fix the command widget", it's better to say "command widget fixed". Because if you do verbs, most of your commits will start with "fixed" and stuff and won't be helpful when people actually try to read it.
Some people do require to do the whole fix:, chore:, docs:, refactor:, but I find this is more as some quality control tool rather than a documentation tool.
Ours is integrated heavily with Jira, so using the ticket number helps the most. We're likely to find commits/PRs from tickets, or jump to the ticket for the context of the commit. The other entry point is looking at git blame on an IDE, especially a funky looking line of code like `if (nonsense logic)` is causing a bug regression. When this happens, I want the ticket. I can immediately just paste the ticket number into Jira.
As always, different styles are suited to different cultures. Read everything here for ideas, but pick one that fits your culture the best.
Readit News
See https://jiby.tech/post/my-git-worfklow/
I like to think of this not as giving an order to the codebase, but as casting a spell.
Meanwhile my coworkers just commit with "lol" and get the same result. What I learned from this is that you don't need to split commits, just commit everything at once and add a "good enough" message. E.g. if you're working on a provider just use "Updated provider"
How do you want to roll back a change of a specific feature if multiple works are committed at once.
Is it that hard? What is this question even? Do you lose consciousness and project awareness in these cases? Why someone must split all the work before it's needed, when it's only needed in 0.01% of all cases? Why wouldn't you do this job when the need to rollback arises? Good arguments for commit granularity exist, but this one makes little sense, like many others.
I hope that is what they mean!
That being said, some places do have commit standards. Just ask the team what they do when you start somewhere. Don't bring conventions in where a team doesn't use them - it just adds noise. If you or the team see how adding conventions can benefit your work, talk about it and make a decision together.
When it comes to working in teams I actually do recommend them because during a code review you can - at a glance - read what each commit has done so you can familiarise yourself with the steps the developer took to reach the state in the PR.
For small teams I'm a big proponent of slimmed down version of Conventional Commits' standard. At our startup we would only really use these types: fix/feat/chore/docs/refactor/revert/ci/test.
Something simple like:
fix(ControlPanel): popover animation no longer causes layout shifts
is perfect
If you're building the next open source self-hosted facebook, yeah I think a convention is necessary. However, if you're building "my calculator app in Rust" then you're probably okay just doing commits "abcd123" just so that you can have remote code storage :^)
Don't overthink it though, it's a thing that is used in some open-source projects and companies. As long as you follow the rules of the project, you'll be fine. Same for the coding style and format, do like everyone else.
Some people do require to do the whole fix:, chore:, docs:, refactor:, but I find this is more as some quality control tool rather than a documentation tool.
Ours is integrated heavily with Jira, so using the ticket number helps the most. We're likely to find commits/PRs from tickets, or jump to the ticket for the context of the commit. The other entry point is looking at git blame on an IDE, especially a funky looking line of code like `if (nonsense logic)` is causing a bug regression. When this happens, I want the ticket. I can immediately just paste the ticket number into Jira.
As always, different styles are suited to different cultures. Read everything here for ideas, but pick one that fits your culture the best.
https://git-scm.com/book/ms/v2/Distributed-Git-Contributing-...
https://git-scm.com/docs/SubmittingPatches#describe-changes
For examples of projects that do this very well, I usually point people to the Linux kernel (for which Git was invented) and Go.
https://www.kernel.org/doc/html/latest/process/submitting-pa...
https://go.dev/doc/contribute#commit_messages