The comic is from Daniel Stori. It is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
The time...
For further actions, you may consider blocking this person and/or reporting abuse
If you work with Jira, It's also nice to prefix your commit with the ticket number, e.g.
XYZ-123: add the thingThat way you can easily navigate to the corresponding ticket and see why the change was made.
I love linking like this, but it also proves problematic over time as teams move PM software and context is lost. For the most part, I'm trying to get in the habit of writing commits that include the sufficient context to explain why a change was made without relying on a ticket.
... definitely makes for longer commits though /shrug
Maybe put ticket number in the footer of commit message? So it stays linked, but wouldn't clutter up git log since you can't tell at a glance what XYZ-123 means, when viewing git log output.
Nice advice 👌
You can share your git commit conventions in the team via e.g.:
add this into your "~/.gitconfig"-file
example: github.com/voku/dotfiles/blob/mast...
Just to confirm - this is a template, but does not act as a linter, correct? So, you could pair this with something like
commitlint(github.com/conventional-changelog/...)Waouh! Didn't know about it, thank you for sharing!
Checkout a package called commitzen. I've been using it professionally alongside Jira and it's made the commit messages very clean and meaningful.
In addition, utilizing a Changelog and proper versioning is super helpful.
Thank you for sharing about commitzen.
I could not agree more!
What a great article!
Usually, I do all my projects on my own, hence my commit habits and good practices are roughly none and this is felt when I work with other colleges in a team, like in a university project...
This article presents itself as an awesome way to start improving these collaboration skills!
Thank you!
Sure, side projects are a good way to practice. I try to pay attention on these details so it helps potential contributors 👌
It is easier to apply on professional work if it is already an habit 👍
Thanks for taking the time writing about this important topic. We also implemented a convention and at the time we were inspired by the following (old) blog post chris.beams.io/posts/git-commit/ . Combining this with some custom convention for the projects needs is very powerful!
Excerpt from the post:
A properly formed Git commit subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here
For example:
Notice how this doesn’t work for the other non-imperative forms:
Remember: Use of the imperative is important only in the subject line. You can relax this restriction when you’re writing the body.
I really like the depth you decided to go. You had emphasized the value of the message and the explained how it added value to other tools.
I joined dev.to specifically to help get this point across.
Git is a Communication tool
Jesse Phillips ・ Dec 12 '18 ・ 2 min read
Thank you for sharing. I definitely added your series in my reading list 🙌
Great article!
The only part that I was missing and I would like to understand more on, is once you decide on your project commit message conventions, how do you verify everyone (including yourself) is following it?
BTW, funny story - I actually wrote a really similar post a few months ago:
datree.io/resources/git-commit-mes...
I have come across recommendations to write commit messages in present tense by some people and past tense by some other.
For example,
Any preferences in the tense of the commit message?
Great article, thanks! I always have problems with the commit messages. Especially in the new projects. So often it comes to:
rm -rf .git
git init
git commit -am "Initial commit"
:D
Thanks again :)
Glad it please you 😄
I wonder if it is safe, if it is ever done, to rename a commit message? -- help.github.com/en/github/committi...
One more wonder, is, how often should I commit?
It depends if someone or something depend on this commit identifier. Amending a commit and push force it will change the commit identifier.
In my opinion you should commit as often as possible. It will help you split your code 👌 Keep in mind you must commit only working things. The first four points in the following article git-tower.com/blog/version-control... describe well what is a good commit 👍
Really nice article! I really love the tips you gave and the convention examples you mentioned.
I think the gitmoji convention must bet a lot of fun to use, although I never used it professionally so far.
thanks for sharing! 👍
Thank you, I use it on professional project. It really depends on your team and the common rules you commit to. In my opinion emojies are compatible with professional project since we already use it a lot in chatting tools at work 😄
Conventional Gitmoji commits the missing part 🐳
You can't be more right!
But will you remember why you made those changes in six months time?
If your stuff is open source I would recommend paying attention on your commit history if you want to attract some contributors 😄
Thanks for Sharing! Iˋm looking forward to use your guiding tips in my future projects! ☺️
Glad it helped you!
Husky has something to offer here. It can help automate these things
Sure, automate this kind of checks is nice 👍
Great article ! Well documented with great sources !
Thanks Thomas for your review 🙏
I think a well structured commit history helps potential contributors. Nice initiative!