Make your Git history great again

Either write something worth reading or do something worth writing.Benjamin Franklin

Don’t write messages, no one can understand it.

If you don’t give the git commit messages importance and try to skip it by any rubbish words, tomorrow you and your team will skip your commits as not readable, meaningless, useless.

You lost one of the main goals of distributed version-control / Git.

Don’t Write such trash:

Developers who don’t care with repository log, don’t care with their code

Believe it or not, some developers don’t care about their history.

They have an unbelievable ego when I argued with them, that is wrong and they should leave it as its called “History”, leave a great history.

It is really dumped and disgusting to find such a history in any kind of history, which is unreadable, doesn’t help anyone after an hour of pushing it.

case study for bad commit messages: don’t be a dump and write a shit, no one can read it anymore.

Hints to level up the Git commit messages:

1- As a team, You should define a git commit message templet/style across team members, to improve the quality of git commit messages.

2- As a team, You should define the commit message convention, like define a set of commit types (Implement, Fix, Refactor, Remove, Document, Test, Release).

3- As a Team considers the Git commit messages in merge request/pull request.

4- Start your Git message with title whenever it is possible.

5- Define a commit message meta-data such: issue tracking IDs, tickets ID, pull request numbers.

Rules for a great git commit message style

Separate subject from the body with a blank line

Separate with a blank line

• Make it clear and simple, separate between title and body with a blank line, and don’t separate between body lines with blank lines.

Do not end the subject line with a period

Avoid punctuation as you can, it is a title

• If we consider it as title, titles have no period.

Capitalize the subject line and each paragraph

• Fix crash in login scenario according to Crashlytics crash id xxxxx.
• Refactor login screen after upgrading to Kotlin.

Use the imperative mood in the subject line.

• Fix crash in login scenario according to Crashlytics crash id xxxx.
• Refactor login screen after upgrading to Kotlin
• As a hint: try to make your subject complete the statement of “If applied, this commit will”

for example:

• If applied, this commit will refactor login screen after upgrading to Kotlin
• If applied, this commit will update to Kotlin version 1.3.11
• If applied, this commit will remove deprecated API
• If applied, this commit will release version 1.0.0

Wrap your subject to 50 characters.

it is not a newspaper article, keep it short

• Write a commit message title not more than 50 characters, try to keep it simple and clear.
• 50 characters as a limit are ok but consider 72 the hard limit.

Wrap body lines at 72 characters

Avoid long body, try to keep it short & descriptive as you can.

• Try to minimize your message body, best writing which is less, clear and descriptive.
• Use the message body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

when you write your body try to answer those question for yourself first:

• Why did we need this commit?
• How did this commit apply to code?
• Did the commit refer to ticket id, issue id, crash id(Meta-data) or any references?

Resources:

• https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
• https://chris.beams.io/posts/git-commit/#seven-rules

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.