git-lint 2.2.0 → 2.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1a0ccd4d14bc5a75b14ae5a825f5eec453a560bc3e6df2bc959bbcb90f626794
-  data.tar.gz: 5f64925793493c9cde59a4828666137ba6a5203f664d5b97ce994552b38fcb42
+  metadata.gz: 432f1e46b50a5ae86dc268318ea2a2cf720e68d57a00cbdc274d50379bbee24f
+  data.tar.gz: 5ca784153ebd07153c70b4e7452a7ef0e141b32789e5d4f1c0fb95d861d698b2
 SHA512:
-  metadata.gz: b295196574a134f2ae5a3989c71d7023998eaf96476055a8c511a3f5d684fbaf1d9456fe887389042d4f8a88fb0d7bce0ea8e1a5663c490c1cf7756b9d6384c8
-  data.tar.gz: 542818d4e2dced990b4231b53160e6c59272c1db908e309a10566210be26eeddb6213ec1f6581c75b078f6d8581e0b4f85827efe03d0f93ce9a216a8133c94a8
+  metadata.gz: 9f53f339560363704e3f35560d3ee5dc6b43012c9eadbf088cd580ddbd0738f6933a16f963406eeb882d2f0d951b95894f7c25a581582c3058074879ab12e3ba
+  data.tar.gz: b5cbe2dbe299a0f3690d64ceb6b2df00074d2112bdbb7bf93c031268705289db782118f19411f0083b592407fc071c84a5311deab01d6afd13e17592a03cb4de

data/README.adoc

@@ -747,9 +747,12 @@ Ensures the commit subject uses consistent prefixes that explain _what_ is being
 * *Updated* - Identifies what was updated. The commit should be as small as possible and _not add
   or fix_ existing behavior. This can sometimes be a grey area but is typically reserved for updates
   to documentation, code comments, dependencies, etc.
-* *Refactored* - Identifies what was refactored. The commit should be as small as possible and only
-  improve existing functionality while avoiding changes in behavior (especially to public API
-  that might effect downstream dependencies). Refactored code should never break existing specs.
+* *Refactored* - Identifies what was refactored.
+  link:https://thoughtbot.com/blog/lets-not-misuse-refactoring[_Refactoring is for changing code
+  structure without changing observable behavior_]. The commit should be as small as possible and
+  not mix multiple kinds of changes at once. Refactored code should never break existing
+  implementation behavior or corresponding specs because, if that happens, then one of the other
+  four prefixes is what you want to use instead.
 
 In practice, using a prefix other than what has been detailed above to explain _what_ is being
 committed is never needed. These prefixes are not only short and easy to remember but also have the
@@ -947,7 +950,7 @@ configuration disabled.
 
 === Tags
 
-* Use tags to denote milestones/releases:
+* Use tags to denote link:https://www.alchemists.io/projects/milestoner[milestones]/releases:
 ** Makes it easier to record milestones and capture associated release notes.
 ** Makes it easier to compare differences between versions.
 ** Provides a starting point for debugging production issues (if any).
@@ -972,124 +975,8 @@ configuration disabled.
 
 === Code Reviews
 
-There are three main objectives each code review should achieve:
-
-. *Joy* - The experience of working with you, receiving feedback, giving feedback, and demonstrating
-   a level of care influences others and encourages a collaborative environment that is fun to work
-   in. Use this time to build and reinforce trust amongst your fellow colleagues.
-. *Quality*: Ensures changes are of highest quality that adhere to team standards while enhancing
-   the customer experience and not disrupting their workflow.
-. *Education*: Provides a chance for everyone on the team to learn more about the architecture,
-   product/service, and how each member of the team implements a solution. This is your chance to
-   ask questions and learn how to be a better engineer so take advantage of it.
-
-In addition to the objectives above, the following guidelines are worth following:
-
-* Keep code reviews short and easy to review:
-** Review your own code first before submitting to others. By ensuring your are confident in the
-   overall implementation and the commits in terms of commit messages and implementation details,
-   you'll encourage higher quality feedback and show appreciation for the reviewer's time.
-** Provide a high level overview that answers _why_ the code review is necessary.
-** Provide a link to the issue that prompted the code review (if any) and any additional details
-   worth highlighting to guide the reviewer through the process.
-** Provide screenshots/screencasts if possible.
-** Provide any ancillary notes or points of interest worth highlighting for the reviewer.
-** Ensure commits within the code review are related to the purpose of the code review and avoid
-   mixing in changes that are ancillary to the primary objective of the code view. If you do have
-   changes outside of the scope of the current code review, open those changes up as a separate code
-   review instead.
-** Prefer code reviews at about 300 lines in order to keep the quality of the code review and defect
-   detection high. This also shows you value the reviewers time and attention away from their own
-   work.
-** Avoid working on a large issues without first getting feedback in order to not overwhelm/surprise
-   the maintainers. More discussion up front will help ensure your work has a faster chance of
-   acceptance.
-* Review and rebase code reviews quickly:
-** Maintain a consistent but reasonable pace -- Review morning, noon, and night.
-** Avoid letting code reviews linger more than a day. Otherwise, you risk hampering moral and
-   diminishing the productivity of the team.
-* Use emojis, with a format of `<emoji> <feedback>`, to identify the kinds of feedback used during
-  the review process:
-** 🍵 (`:tea:`) - Signifies you are starting the code review. This is _non-blocking_ and
-    informational. Useful when reading over a code review with a large number of commits, complex
-    code, requires additional testing by the reviewer, etc.
-** ⭐️ (`:star:`) - Signifies code that is liked, favorited, remarkable, etc. This feedback is
-    _non-blocking_ and is always meant to be positive/uplifting.
-** ℹ️ (`:information_source:`) - Signifies informational feedback that is
-    _non-blocking_. Can also be used to let one know you are done reviewing but haven't approved yet
-    (due to feedback that needs addressing), rebasing a code review and then merging, waiting for a
-    blocking code review to be resolved, status updates to the code review, etc.
-** 💭 (`:thought_balloon:`) - Signifies inquisitive intent that is _non-blocking_.
-    Useful when asking questions and/or probing deeper into implementation details to learn more.
-** 🔤 (`:abc:`) - Signifies detection of a misspelling with suggested correction. This is
-    _blocking_ feedback that is easy to correct.
-** 🎨 (`:art:`) - Signifies an issue with code style and/or code quality. This can be _blocking_
-    or _non-blocking_ feedback. It is up to the discretion of the author on how to address the
-    feedback but encouraged that the feedback is incorporated or at least discussed. Generally,
-    these situations are automatically detected via code linters but there are occasions where
-    there is ambiguity in which linters can't catch.
-** 🏛 (`:classical_building:`) - Signifies an issue with the architecture of the
-    implementation. This is _blocking_ and requires immediate correction. The reviewer should
-    provide a suggested solution and/or links to patterns, articles, etc. that might help the author
-    fix the implementation. Pairing is encouraged if feedback is vast and/or complex.
-** 🔓 (`:unlock:`) - Signifies a security violation that would damage us and/or our customers. This
-   is _blocking_ feedback and must be addressed immediately.
-** 💡 (`:bulb:`) - Indicates a helpful tip or trick for improving the code. This can be
-    _blocking_ or _non-blocking_ feedback and is left up to the author to decide. Generally, it is a
-    good idea to address and resolve the feedback.
-** 🙇 (`:bow:`) - Indicates thankfulness of the feedback received. This is _non-blocking_ and
-    always meant as a response to helpful feedback.
-** ✅ (`:white_check_mark:`) - Signifies code review approval. The author can
-    rebase onto `main` and delete the feature branch at this point.
-* Use all feedback as a chance to learn, teach, strenghen the bond of trust between you and your
-  fellow colleagues, and avoid being cut by
-  link:https://fs.blog/2017/04/mental-model-hanlons-razor[Hanlon's Razor].
-* Use automation to ensure code reviews are consistent, of high quality, and swift to resolve. Each
-  code review can be an opportunity to identify and automate the process further.
-* Use face-to-face communication if a code review's written discussion gets lengthy/noisy.
-* Create follow-up actions if additional features are discovered during a code review to avoid
-  delaying code review acceptance. Return to the code review once the new actions have been logged.
-* The author, not the reviewer, should rebase the feature branch onto `main` upon approval.
-* Avoid reviewing your own code review before rebasing onto `main`. Have another pair of eyes
-  review your code first.
-* Ensure the following criteria is met before rebasing your feature branch to `main`:
-** Ensure all `fixup!` and `squash!` commits are interactively rebased. _Avoid rebasing these onto
-   the `main` branch!_
-** Ensure your feature branch is rebased upon `main`.
-** Ensure all tests and code quality checks are passing.
-** Ensure the feature branch is deleted after being successfully rebased.
-
-=== GitHub
-
-When using GitHub, enforce a rebase workflow for all of your GitHub projects (_highly recommended_).
-You can do this via your project options (i.e. `https://github.com/<username/<project>/settings`)
-and editing your merge options for code reviews as follows:
-
-image::https://www.alchemists.io/images/projects/git-lint/screenshots/github-settings-options.png[GitHub Merge Options]
-
-In addition to the above, you'll want to add _branch_ protection rules for your `main` branch. To
-do this, follow these steps:
-
-. Visit your branch settings (i.e. `https://github.com/<username>/<project>/settings/branches`).
-. Click the _Add rule_ button.
-. For _branch name pattern_, enter: `main`.
-. Check _Require pull request reviews before merging_.
-. Set _Required approving reviews_ to `2` as a minimum.
-. Check _Dismiss stale pull request approvals when new commits are pushed_.
-. Check _Require review from Code Owners_.
-. Check _Require status checks to pass before merging_.
-. Check _Require branches to be up to date before merging_.
-. Check _Require signed commits_.
-. Check _Require linear history_ (pairs well with the merge options mentioned above).
-. Check _Include administrators_.
-. Uncheck _Allow force pushes_.
-. Uncheck _Allow deletions_.
-
-With the above applied, you should have the following result:
-
-image::https://www.alchemists.io/images/projects/git-lint/screenshots/github-settings-branch_protections.png[GitHub Branch Protections]
-
-Applying the above changes will help maintain a clean Git history.
+For an in depth look at how to conduct code reviews, please read my
+link:https://www.alchemists.io/articles/code_reviews[article] on this subject to learn more.
 
 == Development
 

data/lib/git/lint/cli.rb

@@ -71,10 +71,7 @@ module Git
 
       desc "--hook", "Add Git Hook support."
       map "--hook" => :hook
-      method_option :commit_message,
-                    desc: "Analyze commit message.",
-                    banner: "PATH",
-                    type: :string
+      method_option :commit_message, desc: "Analyze commit message.", banner: "PATH", type: :string
       def hook
         if options.commit_message?
           check_commit_message options.commit_message

data/lib/git/lint/identity.rb

@@ -6,7 +6,7 @@ module Git
     module Identity
       NAME = "git-lint"
       LABEL = "Git Lint"
-      VERSION = "2.2.0"
+      VERSION = "2.2.1"
       VERSION_LABEL = "#{LABEL} #{VERSION}"
     end
   end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: git-lint
 version: !ruby/object:Gem::Version
-  version: 2.2.0
+  version: 2.2.1
 platform: ruby
 authors:
 - Brooke Kuhlmann
@@ -28,7 +28,7 @@ cert_chain:
   lkHilIrX69jq8wMPpBhlaw2mRmeSL50Wv5u6xVBvOHhXFSP1crXM95vfLhLyRYod
   W2A=
   -----END CERTIFICATE-----
-date: 2021-04-04 00:00:00.000000000 Z
+date: 2021-06-04 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: git_plus
@@ -186,7 +186,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.2.15
+rubygems_version: 3.2.19
 signing_key:
 specification_version: 4
 summary: A command line interface for linting Git commits.