Git

2903 readers

2 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

Follow programming.dev rules
Be excellent to each other, no hostility towards users for any reason
No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago

MODERATORS

Ategon

canpolat

jnovinger

Git Commit Creation (drewdeponte.com)

submitted 1 week ago* (last edited 1 week ago) by drewdeponte to c/git

4 comments fedilink hide all child comments

This is an article in which I explore the details and thinking that goes into how you should create git commits, and why. I like to think of it as the article I wish existed when I was just starting out over 20 years ago.

I wanted to cover all the things that you should think about at a high level. That way it at least could work as an entry point to deeper exploration of the particular areas if the reader isn’t completely sold or they want to just gain a deeper understanding. While at the same time trying to provide enough details to show why and how these choices are valuable. This is always a tricky balance.

Anyways, I would love any feedback on thoughts on how this could be improved.

Thanks

you are viewing a single comment's thread
view the rest of the comments

[–] Kissaki 3 points 1 week ago* (last edited 1 week ago) (1 children)

Given that it is high level, I assume you did not want to include this. I'll mention it here in a comment either way. Text form in the commit message.

I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It's very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"

Consistent imperative form is important to me too. The commit message examples talks about "Summary of changes", which has no verb, and so, may mislead to a different undesirable form of summarizing changes. ("Change xy" instead of "changed xy" or "[now] does xy [at runtime]" or "did z".)

I didn't fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.

[–] drewdeponte 2 points 5 days ago

First of thanks so much for the feedback. I very much appreciate it.

Conventional commit messages is something that I was contemplating putting in there. Though I consider it less of a core thing and more a layer that you can add on once you have the core stuff. I alluded to it in the following.

There are many more things you can include in your commit messages and the template to help you. Some people add explicit change log entries to their commit messages that are targeted at the consumers of the product rather than the developers. Others manage sign-off from peer developers through commit message standards they have defined, etc.

In my opinion, all these things can be valuable, and should be considered, but the above template really outlines the core that should always be present.

The Consistent imperative form is something I do follow and just forgot to put it there. I will have to figure out a way to work Consistent Imperative Form in there fully and Conventional Commits linked in that section I quoted above as an example. So people are at least able to go look into it further themselves.

Thanks again.