romulooliveira / commit-messages-guide Goto Github PK
View Code? Open in Web Editor NEWA guide to understand the importance of commit messages and how to write them well
License: Creative Commons Attribution 4.0 International
A guide to understand the importance of commit messages and how to write them well
License: Creative Commons Attribution 4.0 International
I think it will be really helpful if some details about adding a git commit template was added. This way when they do git commit
the editor will pop up with the template inside.
For instance:
# Summarize changes in around 50 characters or less
#
# Write the messages in imperative form:
# If applied, this commit will <commit message>
#
# Example:
# If applied, this commit will use InventoryBackendPool to retrieve inventory backend
#
# More detailed explanatory text, if necessary. Wrap it to about 72
# characters or so. In some contexts, the first line is treated as the
# subject of the commit and the rest of the text as the body. The
# blank line separating the summary from the body is critical (unless
# you omit the body entirely); various tools like `log`, `shortlog`
# and `rebase` can get confused if you run the two together.
#
# Explain the problem that this commit is solving. Focus on why you
# are making this change as opposed to how (the code explains that).
# Are there side effects or other unintuitive consequences of this
# change? Here's the place to explain them.
#
# Further paragraphs come after blank lines.
#
# - Bullet points are okay, too
#
# - Typically a hyphen or asterisk is used for the bullet, preceded
# by a single space, with blank lines in between, but conventions
# vary here
#
# If you use an issue tracker, put references to them at the bottom,
# like this:
#
# Resolves: #123
# See also: #456, #789
git config --global commit.template ~/.gitcommit.template
Now, running git commit
will always bring up that template loaded in the editor.
Hello.
Doing some Git log archeology quite often, I always struggle to find why a commit was done rather than what it does:
This way:
git log --oneline master
shows why pull requests where acceptedgit show aaafffeee
shows what is done by a commitSo, instead of:
Use InventoryBackendPool to retrieve inventory backend
I think it's better to have
`Inventory` is slow and heavy for the backend
We call the backend several times and `Inventory` open and close a connection
at each call which is slow to execute and add load to the backend to open
connections and authenticate them.
We switch the part `Foo` of the software to `InventoryBackendPool`
which open once a connection pool with the backend and maintain them open
and reopen them if they close unexpectidly.
Ref: #42
Regards.
The portuguese version was written before the main English version that is available in this repository.
Things that need update:
I find in general a good practise to write in the commit message
Closes https://github.com/RomuloOliveira/commit-messages-guide/issues/32
Instead of
Closes #32
What do do you think? should we update this in the guide?
Hi,
Thanks for your great guide, but I am just curious that why you do not follow some of the rules in you commit messages?
These should use the imperative form, isn't it?
I think it would make more sense that under the section 'What is a "commit"?' the image (png) "Checkins over time" should have the numbers in the "Version" (top row) match up with the commit files. For example under, "Version 2" we have commits/files labeled "A1" and "C1".
I think it would be more intuitive and clearer for the reader to have the numbers be the same.
I really like the guide. My only concerns are on the recommendation of squashes and rebases without mention the drawbacks of change the history.
May I patch some comments on this subject?
If I do, I will need help translating it to Deutsch.
I think this is wrong...If I understood well the guide haha.
Mantieni la lingua in modo consistente
Per i proprietari dei progetti: scegli una lingua e scrivi tutti i messaggi di commit in quella lingua. Sarebbe l'ideale se fosse la stessa lingua con cui si scrivono i commenti nel codice, la stessa predefinita per l'applicazione, ecc.
Per chi collabora: scrivi i messaggi dei tuoi commit rispettando la stessa lingua della history dei commit.
# Corretto
ababab Aggiunge il metodo use
al modello Credit
efefef Usa InventoryBackendPool per recuperare il backend dell'inventario
bebebe Fix method name of InventoryBackend child classes
Here the languages are mixed, even the advice says that you have to use one single language.
Hi,
Great guide! The source material gives a lot more context to this piece. You've covered every aspect on commits, but I think a little bit more emphasize on usage of git log and git status would make a huge difference. Though this is mentioned in the source materials, having this before rebase and merge will provide more clarity.
Adding shortcuts for logs would enable insights to effectively rebase or merge commits as well.
A few shortcuts you could add,
git log --oneline
git log --all
git log --graph
git log --stat
git log -p
Hi, I see this guide is very helpful, but the truth that there are a few Vietnamese peoples know this guide. I want to translate this guide to Vietnamese so that it can be popular in Vietnamese developer community. I have read CONTRIBUTING.md carefuly. I hope I can help by adding a README_vi-VI.md file for Vietnamese version.
Thank you all for this nice guide! It's a good introduction for beginners to git.
Since it seems to become more a general git-guide than a "how to write good commit messages"-guide it may be better to rename the project.
It also may be better to reorganize some things, because the jump from "good commit message" to "rebase vs merge" was a bit confusing for me as a first-time reader. Maybe adding some kind of TOC or something...
What do you think about this proposal?
I really like the guide, it is really complete and I would like to link it from some of my projects. I think there is still place for some improvements.
Some things taken from https://github.com/erlang/otp/wiki/writing-good-commit-messages:
Some others:
This are also standard thing, so would be great to add them. Are you up for a PR? I have the felling that every of us is writing is own commit guide in his projects, while we could have one general one. At the end we all write the same things. It would be nice to have some kind of community guide. It would be better and it will save all of us time. ๐
Great guide! โค๏ธ
I think there is an issue with the license. This is not software, but documentation. I think that the Apache license doesn't apply and that you should use a content license, such as CC-BY-4.0.
Check: https://choosealicense.com/non-software
It may be great that you update it ๐
Rebase drawbacks were added in #9 to English and Portuguese languages.
Help needed for a German translation.
As mentioned in #50 the whole project would have much more readability, if a TOC is added.
Since it is easier for new readers to follow along the topics of the chapters and it provides a better navigation for readers, that want to lookup a single point, it would improve the quality of the whole project.
Translate to Bahasa
Reviewing translations is a valuable work. I'd like to be able to acknowledge and enhance this type of contribution.
https://allcontributors.org/
https://github.com/all-contributors/all-contributors
Thanks for putting this guide together! We've been using emoji in our commit messages for an easy shorthand way to see what a commit is about. It's fun, and helps me break down what I've done in the commit. In addition, it lets me know when I'm maybe making too large of a commit, since it's best limited to two emoji. The author of the repo writes:
Using emojis on commit messages provides an easy way of identifying the purpose or intention of a commit with only looking at the emojis used. As there are a lot of different emojis I found the need of creating a guide that can help to use emojis easier.
https://gitmoji.carloscuesta.me/
I thought it might fit under the "Other interesting stuff" section.
Thanks for considering!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.