Commit Rules

• Some Principles
• Commit Message
  • First Line
  • Full Message
• Types of Commit
• Commit Message Template

Some Principles

The commits should respect this following principles :

• Atomic
  • Your changes should concern one, and only one, purpose
    • TIPS: if you describe your commit with an “and” you should split it
    • e.g. “Upd: feature X to do something and fix the bug about the feature N” should be splitted
    • TIPS: You can split with the command “edit” in an interactive rebase (git rebase --interactive MAIN_BRANCH)
  • Your changes should affect the minimum of code posssible in one commit
• Consistant
  • In a branch you should not have several commits with the same purpose
  • You should not fix something who hasn’t been merged into the main branch ; The commits should be merged instead
    • TIPS: You can merge with the command “fixup” or “squash” in an interactive rebase (git rebase --interactive MAIN_BRANCH)
• Stable
  • Your commit should break nothing, that means, if we change the working directory to this commit (git checkout HASH_OF_THIS_COMMIT) nothing should be broken
    • TIPS: You can checkout and run your tests
• Clean
  • Don’t let useless stuff in your commit (such as debug variables only needed when you are developping)
    • TIPS: Read the things who will be commited before commiting it
      1. git add SOME_FILE
      2. git diff --cached
      3. git commit
• Don’t repeat meta data
  • There are no need to say :
    • who have done the change
    • which files have been changed
    • date / time of the change
    • branch where it’s commited
  • All of this data are already stored in the commit or somewhere else

Commit Message

You should be clear on your commit message

First Line

When someone read the commit’s first line (git log --pretty=oneline --abbrev-commit) then one should understand what has been done ; this line should be 80 characters length or less

Full Message

When someone read the full commit message (git log) then one should understand what, how & why has been done

You should keep a blank line after the first line

You can be verbose, explain things, put links…

If you use a command to do the change (such as : sed) or generate (with a tool to scaffold / init a project) your file should write the command used in the long message of your commit

Types of Commit

• Fix
  • To use when a behavior of a feature is fixed
• Add
  • To use when a behavior of a feature is added
• Upd
  • To use when a behavior of a feature is updated
• Refacto
  • To use when a behavior of a feature is refactored ; such as: split a function but keeping the same logic
• Merge
  • To use when a behavior of a feature is merged

Commit Message Template

Type of commit: description of what has been done in 80 characters or less

Long description who describe :

• what has been done with more details
• how it has been
• why it has been
• why it has been this way