Hello devs, I'm going to share a few best practices for using Git more effectively. git? Yes, the git you're already familiar with. The code buddy,...
For further actions, you may consider blocking this person and/or reporting abuse
When working in a team with multiple developers on the same project, I find it best to also include your first name on the branch name itself - assuming at any given point of time there are at least 4-10 active branches (depending on the size of the team and product), it really helps a lot to find it. My personal favorite convention:
<FirstName>_<TaskNumber>_shorten-task-name- so Zohar_12345_Do-somethingCouldn't agree more! When I worked on complex web projects, there were typically a dozen or so branches created by different team members for various interfaces and other things. I used to include a short alias for myself at the end of a branch name.
Same here! I generally do « nfdiop/branch-name »
The notion of embedding metadata about the commit in the subject (ie "conventional commits") is misguided. Rather than putting such data in the subject line, stash it in a trailer. wrp.github.io/blog/2024/01/03/conv...
I don't think so; as I indicated in the conclusion, the conventional commit is not an obligatory practice; you can follow it in any way/extent you feel comfortable. If you are concerned about keeping consistency, I believe that is a small price to pay. The benefits of clean, organized commit histories and automated, rich changelogs and much more, feels significant to me.
Conventional commit already encourages including thorough explanation in the commit message body; formatting that is also a smart choice to match requirements like the tools you're talking about.
In the end, it's only individual or organizational choice to conform to such standards, and I never thought these conventions were mistaken or unnecessary.
I think you may be missing my point. I agree whole-heartedly that a clean, organized commit history is a desirable goal. Indeed, that is the entire reason that I discourage the practice of including meta-data in the subject line and instead encourage people to put that data in commit trailers. When projects attempt to place meta-data in the subject line, the formatting will inevitably be inconsistent.
By placing that data in trailers instead, there is some support from the tooling to ensure consistency and you gain a great deal of flexibility in viewing the data.
I apologize for misinterpreting your message. I appreciate that you are recommending a better technique than adding all meta data in the subject line; that is true. I believe we should introduce a modern or better approach to do this with solid reasoning, as many people still follow traditional methods.
Branch names: ticket ids with mix of git flow
Commit messages: conventional commits with descriptive messages - "Fix bug #67" means nothing and have zero value if you want to generate changelogs.
Sorry if you didn't find it useful! Maybe there are projects where this approach might help, such as for a project for tools that used by developers, in such cases referring issue number is enough or in similar situations.
Great work !
My commit messages:
Looks great! Were you able to do it consistently?
Well i enjoy writing good commit messages, and i am consistent from last HacktoberFest.
This is a really informative post! I've just recently gotten in the habit of naming my branches correctly, but I didn't realize there were conventions for it.
I'm glad you found it informative, and I'll attempt to do a follow-up on this.
How about Subject-First Commit Messages?
github.com/aaronjensen/software-de...
That is an interesting approach. This method is preferable when someone quickly checks the commit log for immediate information. Also, I believe it is preferable to put the type of commit as a prefix so that commits may be categorized with certain scripts or tools.
Anyway, it is a nice approach to describe, rather than lazy, on-the-go descriptions in the subject line.
Every git tool in existance (gitlens, vscode, Github, Jetbrains, etc) only displays the first line of a git commit message. There are some esoteric git options to show more but in practice nearly no one bothers to use and remember them.
Very rarely do you go through all the git commit text.
Being able to quickly summary that the commit is about is much more valuable. If you want to you can still include tags for automated ci, ticket number or a description afterwards.
Summary: subject first approach is the best one.
Agreed. Subject-first practice is a smart technique. I read in many places that a commit description should be able to complete this sentence:
I believe this is one of the reasons to use imperative mood in description.
Since you stated this, I also think subject-first is better; perhaps we should renovate these practices.
This post is so good for improve our practices!
coolThank for you appreciation!
How to write Git commit messages like a Pro!
Ritik Banger ・ Oct 10 '22
Great post!
Man if not this article, I would have kept my very bad naming conventions, which are mostly generic
Happy that you found it helpful; if not generic, we all follow some form of mixed conventions that we get from here and there:)
Hi Shinjith ! Thanks for sharing
You're welcome! I'm glad you found the post interesting.
cool article, i wonder if there is one for file naming too
Thanks! It is not a good idea to use the same file naming or folder structure across all technologies, but there are plenty of guides if you're seeking for a specific language or framework; I hope this helps.
I enjoyed this read and do agree that your points are effective disciplines for beginner and veteran developers to practice.
I'm glad you found this post informative and helpful!
you got some typos in there buddy
Loll! Too lazy to fix them, thought everyone would ignore :/. But atleast we can confirm this isn't AI generated
It's interesting you recommend inducing ticket number, e.g. for Jira, as to me it provides absolutely no value for the branch name (and browsing those). Tracking the issue is not limited to be included in the branch name; it can just be included in a commit message, the PR title or the PR description.
When going through branch names, who will find any value of something like
feature/SHOP-123or get a clue of the branch's purpose?Like I mentioned, I merely adapted & organised information from different references. I didn't try that approach where we use the ticket number like you said.
But maybe this is applicable to some project with strict handling of errors/bugs or so. I believe there might be some use cases for the same. I'm sorry if you didn't find it useful.