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.

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:

• Always leave the second line blank.
• Don't end the summary line with a period - it's a title and titles don't end with a period.

Some others:

• Add a commit description, there is normally something else useful to add.
• Include the issue you are fixing to make use of Github feature to close them automatically

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. 😉

The portuguese version was written before the main English version that is available in this repository.

Things that need update:

• More detailed explanations in some sections
• Better source referencing
• Double checks of missing translation or typos

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

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?

Translate to Bahasa

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!

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 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:

• ~/.gitcommit.template

# 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

• Setting it up

git config --global commit.template ~/.gitcommit.template

Now, running git commit will always bring up that template loaded in the editor.

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

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 😉

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.

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?

Rebase drawbacks were added in #9 to English and Portuguese languages.

Help needed for a German translation.

Hello.

Doing some Git log archeology quite often, I always struggle to find why a commit was done rather than what it does:

• a first line to summary why this commit was done
• a longer description to make explicit the context of the why given in the first line. This description summary how things were done.
• if necessary, a list of files with a summary of what was wrong specifically to this file and the tricky parts

This way:

• git log --oneline master shows why pull requests where accepted
• git show aaafffeee shows what is done by a commit

So, 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.

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, 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.

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?

#8b1a1f13a6

#8195c4c08

Almost all sources regarding the commit summary message suggest using the imperative. Unfortunately, in his otherwise very nice and often cited article on commit message, will also advocating the imperative Chris Beams made the mistake to suggest that a commit message should also be able to complete his "help sentence": If applied, this commit will ....

As the imperative in English is always the same as the infinitive, imperative summaries used in this way will correctly complete the sentence with the english will future form (but will no longer be imperative).

This does not work at all in many (probably most) other languages, however. Although being cited on numerous places, it leads to confusion as soon as languages other then english are used (for example, in this guide, in the german version, the example sentences are like Korrigiert den Methodennamen der InventoryBackend Kind-Klassen which is not imperative (imperative would be 'Korrigiere den Methodennamen der InventoryBackend Kind-Klassen`).

As in other languages, using a help sentence as advocated by Chris beams would lead to grammatically totally different forms of summaries, I suggest completely removing the 'help sentence' from the guide.