Skip to content
This repository has been archived by the owner on Oct 7, 2022. It is now read-only.
Nicolas Sebrecht edited this page Apr 2, 2016 · 1 revision

Git the correct way

Writing good commits

  • Use the imperative form: e.g. "fix", not "fixed".
  • A one-liner for the title of the commit. No capital letter at the beginning, no dot at the end.
  • The description of the commit after an empty line.
  • Explain what the patches do and why.

HINT: git commit --amend

Good history

When you intend a merge to the mainline by a maintainer, you intend your work to become part of the mainline. Reviewers have to read your commits. Later contributors might need to introspect the history. Make their job easy.

HINT: git rebase -i

Make atomic commits

  1. A commit must do all and only what it pretends to achieve.
  2. Don't mix different topics.

Polish your commits

Rewrite the history to make a nice history. History must be logical, easy to read and easy to understand.

If a reviewer has to look at the patches to understand what is done, you failed.

Workflow

Update your repository

HINT: git fetch + git merge

If the mainline goes ahead, you must follow the mainline. Writing patches on top of outdated code is probably not what you want.

Use topic branches

Working on the official mainlines is bad. Keep the official branches identical to what they are in the official repository.

HINT: git checkout -b topic, git rebase master

Clone this wiki locally