Document some guidelines for creating commits
This commit is contained in:
parent
8f85b5204c
commit
1379a2cc9f
|
@ -46,6 +46,32 @@ Create Your Patch
|
||||||
# create an account in JIRA and create a new issue;
|
# create an account in JIRA and create a new issue;
|
||||||
# attach the patch file(s) you created to the issue
|
# attach the patch file(s) you created to the issue
|
||||||
|
|
||||||
|
Guidelines for a Good Commit
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
To the extent possible and appropriate, address only one issue per
|
||||||
|
commit. When we review your commit, anything that doesn't need to be
|
||||||
|
there will only create confusion.
|
||||||
|
|
||||||
|
This means that, for example, unrelated refactoring or whitespace
|
||||||
|
cleanups should generally happen in separate commits. Whitespace
|
||||||
|
cleanup commits should not change anything other than whitespace, and
|
||||||
|
refactoring commits should strive to preserve identical behavior.
|
||||||
|
|
||||||
|
However, don't go overboard. A commit should do some identifiable
|
||||||
|
thing completely. If you're adding a new module, the build changes
|
||||||
|
for that module should go in the commit that adds the module itself.
|
||||||
|
If you're adding a feature, the feature should work after applying
|
||||||
|
that commit.
|
||||||
|
|
||||||
|
We don't need to see your missteps and corrections. Use `git rebase
|
||||||
|
-i` to squash those out of your history before submitting the commit
|
||||||
|
series to us. It should look like you got everything right the first
|
||||||
|
time.
|
||||||
|
|
||||||
|
Use `git log -p` to verify that each diff is correct and minimal, and
|
||||||
|
that your git author name is correct and complete.
|
||||||
|
|
||||||
Writing a Good Commit Message
|
Writing a Good Commit Message
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue