summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--happy-patching/happy-patching.org36
-rw-r--r--happy-patching/happy-patching.pdfbin101542 -> 105315 bytes
2 files changed, 23 insertions, 13 deletions
diff --git a/happy-patching/happy-patching.org b/happy-patching/happy-patching.org
index 2888bc6..f5370e3 100644
--- a/happy-patching/happy-patching.org
+++ b/happy-patching/happy-patching.org
@@ -31,11 +31,11 @@
- Easier to understand *why* a change was made
- Easier to =git bisect= to find breaking changes
- Easier to =git revert= those breaking changes
+ - Easier to review pull requests
+ - Faster code review loop
* Commits
-** Guidelines
-
*** What's in a patch?
A patch:
@@ -93,8 +93,6 @@
`(("inputs" ,(serialize-inputs (package-inputs package)))
#+END_SRC
-** Short Log
-
*** Short Log
The first line of a commit log should:
@@ -107,21 +105,25 @@
in ("tests: Fix the frob." or "gradebook: Give everyone an A.")
- Always end with a period.
-** Log Body
-
*** Log Body
The body of a commit log should:
- Explain or justify the change
- For a bug fix, provide a ticket number or link to the ticket
- - Explain what changes were made at a high level (see: The GNU
- ChangeLog standard)
+ - Explain what changes were made at a high level (The GNU ChangeLog
+ standard is worth a read)
- Be word wrapped to 72 characters per line
-* Pull Requests
+*** Workflow
-** Guidelines
+ - Review the full diff before commiting (don't =git add= and
+ immediately =git commit=)
+ - Use before commit hooks to run linters such as Rubocop
+ - Use your =$EDITOR=, not the =-m= flag, for writing your commit
+ log
+
+* Pull Requests
*** Pull Requests
@@ -132,9 +134,15 @@
- Not contain *any* "fix up" commits ("Fix typo.", "Fix test.",
"Remove commented code.")
- Be able to be thoroughly reviewed by a single person (No massive
- patch sets containing weeks of work by multiple people)
+ patch sets containing weeks of work by several people)
+
+*** Code Review Goals
-** Workflow
+ - Shared responsibility between submitter and reviewer
+ - Prioritize code review
+ - Disassociate pull requests from being strictly tied to a
+ story/epic/task/etc.
+ - Make code review → QA → production phases happen faster
*** Programmer Workflow
@@ -151,7 +159,7 @@
*** Reviewer Workflow
- - Inspect patches individually in addition to looking at the full
+ - Inspect patches individually as opposed to looking at the full
diff in GitHub's web interface; each commit should stand alone
- Refer to coding conventions when pointing out style problems
- Follow up on changes made in response to your feedback quickly
@@ -166,3 +174,5 @@
https://www.gnu.org/prep/standards/html_node/Change-Logs.html
- On Code Review —
http://glen.nu/ramblings/oncodereview.php
+ - A Note About Git Commit Messages —
+ http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
diff --git a/happy-patching/happy-patching.pdf b/happy-patching/happy-patching.pdf
index ab3a76d..920da7a 100644
--- a/happy-patching/happy-patching.pdf
+++ b/happy-patching/happy-patching.pdf
Binary files differ