diff options
| -rw-r--r-- | happy-patching/happy-patching.org | 36 | ||||
| -rw-r--r-- | happy-patching/happy-patching.pdf | bin | 101542 -> 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 Binary files differindex ab3a76d..920da7a 100644 --- a/happy-patching/happy-patching.pdf +++ b/happy-patching/happy-patching.pdf |