-
Notifications
You must be signed in to change notification settings - Fork 33
Git
- 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
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
- A commit must do all and only what it pretends to achieve.
- Don't mix different topics.
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.
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.
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