When it comes to version control, Git is a very effective tool. However, like any other tool you have to use it the right way to get the most out o...
For further actions, you may consider blocking this person and/or reporting abuse
thank you for this info!! i won't write commit messages like
shfkgkdjejeneanymoreAlso, this is what squashing commits was made for (provided you are still on an isolated branch you can force push). Commonly squashed commits for me are:
Yep, well said.
Or updated Readme.md. I hate those commits.
Hehehe
😅
...wait, so
"...in which our hero bravely fixes an off-by-1 error because of arrays that begin with 0 instead of 1" isn't valid? 🤣
If you and your team are consistent in writing commit messages in the style of the Hero Journey, great!
It is valid and better than conventional commits
I’m adopting this!
The non-conformist in me is yelling "You can't tell me how to write my comment's FU! finger. While the part of me that wants to get a job is somewhat grateful, yet still put off. Future experienced me who knows what pipelines and automation are thinks the other two me's are stupid.
Fix(individualism)!: modify perspective
Modify perspective to magnifying the power of teamwork, inorder achieve gainful employment.
BREAKING CHANGE. Fix #fu-00100
Understood. It's good to find balance as you get more experience to know when to conform and when not to. Great point. Thanks for the post!
TBH I don’t like conventional commit messages because in my opinion commit messages should naturally speak about the change not needing a prefix to tell whats is the change itself. Try to automate something (CI/CD) via commit messages for me is a misuse, the message should say what the changeset is doing and not what to do with the changes
What your pipeline will gonna do with “fix: foo bar” change? Test or Deploy the code, does not matter the prefix. Breaking change? Ok the deployment process will stop by “reading” this prefix?
I do believe documentation, knowledge sharing, strong pipeline processes are more effective than conventional commit messages, and also I know this comment is fully of bias 🤣
agreed, relying on commit messaging for some CI/CD function is a misuse, and too risky. They're super hard to enforce anyway, and with standard/conventional commit messages there's still a lot of flexibility.
IMO conventional commits make scanning git history by humans much more effective. Adding any structure to something that differs so much per developer goes a long way. Teams can share scopes, types imply severity (or at least demand different levels of attention), and all of it forces us to easily give context that we often forget about.
My team of 6 uses Commitizen Conventional Changelog in our projects. No complaints so far.
I'd say it often depends of the developer team maturity and size, it could be helpful to enforce standardization.
But totally ok with the second part
This is a great format but better for branch descriptions as a branch fix or feature can have many, many commits. One I worked on the other day to add a nice drag and drop feature for files had about 120 commits by the time I was done. Still, the spirit of the format works well for any of the commit messages. Thanks for the post!
I'm afraid your first 2 examples aren't actually written properly, in that the description doesn't really convey what the commit does and one has to go read the body (which requires additional user actions when presented with a list of commits showing only the description, as is frequently the case)
Here are how I would have written them (still following conventional commits, that I dislike for… reasons):
(I'm sure they can be improved, this is only showing how what you put in the body would better fit in the description)
Honestly, I like your opinion a little better than OP's. Thanks for the post.
Yup, adopting good commit message leads to powerful automation workflow see below:
📜 Better collab flows w. (git) Conventional Commits
adriens for opt-nc ・ Feb 8 '23
Very good point!
Excellent article on the importance of well-crafted Git commit messages! As a developer, it's crucial to maintain an organized and informative commit history to ensure seamless collaboration and make the codebase more navigable.
To further improve your Git workflow, you may want to consider incorporating some tools to simplify the process of writing commit messages. For example, the Leiga IDE plugin can create code commit templates to easily bring issue information into Git commit messages, while also making it easy to update issue status, allowing developers to focus on work in the IDE: Leiga
Check out this CLI tool to help write your got commits for you!
github.com/di-sukharev/opencommit
Thanks for sharing
Fascinating. I'll add this to my extensive list of articles on "how to write a good commit message"
Asante bwana otieno. I've actually learned something new today🙏
Amazing! 😊 thanks! 🙏
This is extremely helpful!
thanks for sharing, there are some tools can help writing commit messages
I use
commitizento both provide a pre-commit hook and automate the questions to build a message.github.com/commitizen-tools/commit...
Awesome. This was really a game changer to committing properly now.
thanks for explaining this messages in detail, I didn't know it before.
The terms of "proper" git message is subjective topic. It depends on what organisation you working at. Conventional Commits, like it's name: Conventional. It just list of conventions about how you write/structure your commit message.
The question is, does the company public like Open Source project over there? If yes, sure you are in the right path. But, what if it's not? Using conventional commits just add another space for complexity (based my experience).
So, any better way?
Ofc, here's how:
I only use:
for all :-D
Ticketnumber which spawned the branch you are merging from + short description is enough in my experience. It's either redundant or totally unnecessary to add more info into a commit imo. Chances are very high it's not correct anyways because it differs from the actual implementation (as comments tend to do as well) and most of the time, people will step right to the code anyways.
Documentation of what and why should be in the ticket or in actual design decisions if necessary. Commit message feel too cramped and overloaded this way imo.
Comments do that not because of inherent nature of the comments, but because usually the implementation changes later, but comments are not updated. Commit messages are strictly for the point in time, so they do not suffer from this.
Absolutely true. Because we are used to read (and write) shitty commit messages. When you work with someone who actually writes useful and descriptive messages, you just read them. No special adapting required.
The conventional answer here is: what if you don't have access to the ticketing system? It is usually shrugged off because - why wouldn't you have it? It's 21st century and we have internet access everywhere. I was the one to dismiss this argument too.
However now I work on the project which switched from JIRA to Linear in it's early days. The links to JIRA tickets simply don't work (the tickets were migrated, but the naming convention changed during the process). And I have been scratching my had few times, wondering why the author made that change, with no chance to get any answer.
So "WIP" isn't a good commit message?
Thank You Ray, now I know how to write git commit messages properly.
Does this work with pre-commit?
No :((( i need a guideline
Some of the data's are not available on My git