git-lint 2.0.0 → 2.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0f890a2d629a880fe71b362f043772b891e8bb6610eeafac4ce7d68f20ccc636
-  data.tar.gz: d8e5e33287b6e4be9787a7d1c9ee8d4bc45a7df5de993b52b732b2de56fa1981
+  metadata.gz: 179a706a6991b40dbbb489fdb38fb955505f0ee1c93f866a703e711a6979f8c6
+  data.tar.gz: 5233c41ef4e4862ed4baaa7ceb354deb8e7dbe69efb90720c888ae92628cc7b1
 SHA512:
-  metadata.gz: a019791e28fe05d1bf198d60c5b8516481e68e1658dc1749d3b4a8c355d128c1f64f472d56b76c57305e2f0d58a2cf2ca6af86fe6fbd978f020d6bc60b2233b4
-  data.tar.gz: a10d7d047daff9d31d88fd53a435f12445e59013bc16df30ad877d7738d12ec45acead33e916c7dd122e527b48faea066a332fbe43b454e2ffec76602089e1b0
+  metadata.gz: 6e0d44179f5b348ab65ecf01a5b252726940b3e1eda0a5659d63d9a15755e6ea6f3e940d6d3445339b4a0d1541f89ba279789ecfa127770d5f02927c2533b6eb
+  data.tar.gz: eb86f245720675fff023b44b90e634d91337a53f15af18cacf4f458825c48a57501f054260e2fc4bb75c208e7579ecdb79f81f89008830f02fa16e9059f7ddaa

data.tar.gz.sig

@@ -1,2 +1,2 @@
-���;��
-$�#6l��H�A�ܳ?��
+F���ㅺ��_J���YO�TN�0U
+���V���s�� 4������8�c���Z��&�Ĝx����7|��s������x��cqP7ǯ��b[X�>�HT�,�`��#!9�j~R�*UNݯ�RY�wBE��%_7��_=q

data/README.adoc

@@ -14,27 +14,23 @@ image::https://img.shields.io/badge/code_style-alchemists-brightgreen.svg[Alchem
 image::https://circleci.com/gh/bkuhlmann/git-lint.svg?style=svg[Circle CI Status]
 
 [link=https://travis-ci.org/bkuhlmann/git-lint]
-image::https://travis-ci.org/bkuhlmann/git-lint.svg?branch=master[Travis CI Status]
+image::https://travis-ci.org/bkuhlmann/git-lint.svg?branch=main[Travis CI Status]
 [link=https://app.netlify.com/sites/git-lint/deploys]
 image::https://api.netlify.com/api/v1/badges/7e23b422-3412-4e7f-b654-65c0417a0b1f/deploy-status[Netlify CI Status]
 
 A command line interface for linting Git commits. Ensures you maintain a clean, easy to read,
 debuggable, and maintainable project history.
 
-*Git Lint is the official port of the original Git Cop project that avoids references to violence or
-violent terminology that might make anyone feel unwelcome. The name change was necessary in order to
-better support the link:https://blacklivesmatter.com[Black Lives Matter] and
-link:https://8cantwait.org[Defund Police] movements.*
-
 toc::[]
 
 == Features
 
 * Enforces a {git_rebase_workflow_link}.
 * Enforces a clean and consistent Git commit history.
+* Supports Git default branch configuration.
 * Provides a customizable suite of analyzers.
 * Provides Git Hook support for local use.
-* Provides Continuous Integration (CI) build server support.
+* Provides Continuous Integration (CI) support.
 
 == Screencasts
 
@@ -71,9 +67,9 @@ git-lint -v, [--version]       # Show gem version.
 To check if your Git commit history is clean, run: `git-lint --analyze`. It will exit with a failure
 if at least one issue with error severity is detected.
 
-This gem does not check commits on `master`. This is intentional as you would, generally, not want
-to rewrite or fix commits on `master`. This gem is best used on feature branches as it automatically
-detects all commits made since `master` on the feature branch.
+This gem does not check commits on your default branch (i.e. `main`). This is intentional as you
+would, generally, not want to rewrite or fix commits on the `main` branch. This gem is best used on
+feature branches as it automatically detects all commits made since creation of the feature branch.
 
 Here is an example workflow, using gem defaults with issues detected:
 
@@ -115,6 +111,21 @@ Now, when running `bundle exec rake -T`, you'll see `git_lint` included in the l
 
 If you need a concrete example, check out the link:Rakefile[Rakefile] of this project for details.
 
+=== Default Branch
+
+Your default branch configuration is respected no matter if it is set globally or locally. If the
+default branch is _not set_ then Git Lint will fall back to `master` for backwards compatibility.
+When the next major version is released, the default branch fallback will change from `master` to
+`main`. You can set your default branch at any time by running the following from the command line:
+
+[source,bash]
+----
+git config --add init.defaultBranch main
+----
+
+💡 When setting your default branch, ensure you use a consistent Git configuration across all of
+your environments.
+
 === Configuration
 
 This gem can be configured via a global configuration:
@@ -293,7 +304,7 @@ maintenance costs for you. To configure global Git Hooks, add the following to y
 ....
 
 Then you can customize Git Hooks for all of your projects.
-link:https://github.com/bkuhlmann/dotfiles/tree/master/home_files/.config/git/hooks[Check out these
+link:https://github.com/bkuhlmann/dotfiles/tree/main/home_files/.config/git/hooks[Check out these
 examples].
 
 If a global configuration is not desired, you can add Git Hooks at a per project level by editing
@@ -378,7 +389,7 @@ have a build server that is not listed, please log an issue or provide an implem
 support.
 
 Calculation of commits is done by reviewing all commits made on the feature branch since branching
-from `master`.
+from `main`.
 
 ==== link:https://circleci.com[Circle CI]
 
@@ -736,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
@@ -746,8 +760,8 @@ added benefit of categorizing the commits for building release notes, change log
 handy when coupled with another tool, link:https://www.alchemists.io/projects/milestoner[Milestoner],
 for producing consistent project milestones and Git tag histories.
 
-Automatically ignores _fixup!_ or _squash!_ commit prefixes when used as a Git Hook in order to not
-disturb interactive rebase workflows.
+💡 Automatically ignores _amend!_, _fixup!_, or _squash!_ commit prefixes when used as a Git Hook in
+order to not disturb interactive rebase workflows.
 
 === Commit Subject Suffix
 
@@ -870,7 +884,7 @@ worth considering:
   blindly combine multiple commit messages without editing them into a single, coherent message._
 * Use `git rebase --interactive` when cleaning up commit history, order, messages, etc. This should
   be done prior to submitting a code review or when code review feedback has been addressed and
-  you are ready to rebase onto `master`.
+  you are ready to rebase onto `main`.
 * Use `git push --force-with-lease` instead of `git push --force` when pushing changes after an
   interactive rebasing session.
 * Avoid checking in development-specific configuration files (add to `.gitignore` instead).
@@ -932,11 +946,11 @@ configuration disabled.
 === Branches
 
 * Use feature branches for new work.
-* Maintain branches by rebasing upon `master` on a regular basis.
+* Maintain branches by rebasing upon `main` on a regular basis.
 
 === 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).
@@ -954,131 +968,15 @@ configuration disabled.
 * Use hooks globally rather than locally per project. Doing this applies the same functionality
   across all projects automatically, reduces maintenance per project, and provides consistency
   across all projects. This can best be managed via your
-  link:https://github.com/bkuhlmann/dotfiles/tree/master/home_files/.config/git/hooks[Dotfiles].
+  link:https://github.com/bkuhlmann/dotfiles/tree/main/home_files/.config/git/hooks[Dotfiles].
 * Avoid forcing global or local project hooks as a team-wide mandate. Hooks are a personal tool much
   like editors or other tools one choose to do their work. For team consistency, use a continuous
   integration build server instead.
 
 === 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.
-** 🔒 (`:lock:`) - 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 `master` 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 `master` upon approval.
-* Avoid reviewing your own code review before rebasing onto `master`. Have another pair of eyes
-  review your code first.
-* Ensure the following criteria is met before rebasing your feature branch to `master`:
-** Ensure all `fixup!` and `squash!` commits are interactively rebased. _Avoid rebasing these onto
-   the `master` branch!_
-** Ensure your feature branch is rebased upon `master`.
-** 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 `master` 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: `master`.
-. 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/analyzers/abstract.rb

@@ -18,25 +18,17 @@ module Git
           @descendants << klass unless klass.to_s.start_with? "#<Class" # Ignore anonymous classes.
         end
 
-        def self.id
-          to_s.delete_prefix("Git::Lint::Analyzers").snakecase.to_sym
-        end
+        def self.id = to_s.delete_prefix("Git::Lint::Analyzers").snakecase.to_sym
 
-        def self.label
-          to_s.delete_prefix("Git::Lint::Analyzers").titleize
-        end
+        def self.label = to_s.delete_prefix("Git::Lint::Analyzers").titleize
 
         def self.defaults
           fail NotImplementedError, "The `.#{__method__}` method must be implemented."
         end
 
-        def self.descendants
-          @descendants || []
-        end
+        def self.descendants = @descendants || []
 
-        def self.build_issue_line index, line
-          {number: index + ISSUE_LINE_OFFSET, content: line}
-        end
+        def self.build_issue_line(index, line) = {number: index + ISSUE_LINE_OFFSET, content: line}
 
         attr_reader :commit
 
@@ -46,9 +38,7 @@ module Git
           @filter_list = load_filter_list
         end
 
-        def enabled?
-          settings.fetch :enabled
-        end
+        def enabled? = settings.fetch(:enabled)
 
         def severity
           settings.fetch(:severity).tap do |level|
@@ -60,17 +50,11 @@ module Git
           fail NotImplementedError, "The `##{__method__}` method must be implemented."
         end
 
-        def invalid?
-          !valid?
-        end
+        def invalid? = !valid?
 
-        def warning?
-          invalid? && severity == :warn
-        end
+        def warning? = invalid? && severity == :warn
 
-        def error?
-          invalid? && severity == :error
-        end
+        def error? = invalid? && severity == :error
 
         def issue
           fail NotImplementedError, "The `##{__method__}` method must be implemented."
@@ -80,9 +64,7 @@ module Git
 
         attr_reader :settings, :filter_list
 
-        def load_filter_list
-          Kit::FilterList.new settings[:list]
-        end
+        def load_filter_list = Kit::FilterList.new(settings[:list])
 
         def affected_commit_body_lines
           commit.body_lines.each.with_object([]).with_index do |(line, lines), index|

data/lib/git/lint/analyzers/commit_author_capitalization.rb

@@ -16,9 +16,7 @@ module Git
           @validator = validator
         end
 
-        def valid?
-          validator.new(commit.author_name).valid?
-        end
+        def valid? = validator.new(commit.author_name).valid?
 
         def issue
           return {} if valid?

data/lib/git/lint/analyzers/commit_author_email.rb

@@ -16,9 +16,7 @@ module Git
           @validator = validator
         end
 
-        def valid?
-          validator.new(commit.author_email).valid?
-        end
+        def valid? = validator.new(commit.author_email).valid?
 
         def issue
           return {} if valid?

data/lib/git/lint/analyzers/commit_author_name.rb

@@ -17,9 +17,7 @@ module Git
           @validator = validator
         end
 
-        def valid?
-          validator.new(commit.author_name, minimum: minimum).valid?
-        end
+        def valid? = validator.new(commit.author_name, minimum: minimum).valid?
 
         def issue
           return {} if valid?

data/lib/git/lint/analyzers/commit_body_bullet.rb

@@ -12,9 +12,7 @@ module Git
           }
         end
 
-        def valid?
-          commit.body_lines.all? { |line| !invalid_line? line }
-        end
+        def valid? = commit.body_lines.all? { |line| !invalid_line? line }
 
         def issue
           return {} if valid?
@@ -27,9 +25,7 @@ module Git
 
         protected
 
-        def load_filter_list
-          Kit::FilterList.new settings.fetch :excludes
-        end
+        def load_filter_list = Kit::FilterList.new(settings.fetch(:excludes))
 
         # :reek:FeatureEnvy
         def invalid_line? line

data/lib/git/lint/analyzers/commit_body_bullet_capitalization.rb

@@ -12,9 +12,7 @@ module Git
           }
         end
 
-        def valid?
-          lowercased_bullets.size.zero?
-        end
+        def valid? = lowercased_bullets.size.zero?
 
         def issue
           return {} if valid?
@@ -27,9 +25,7 @@ module Git
 
         protected
 
-        def load_filter_list
-          Kit::FilterList.new settings.fetch :includes
-        end
+        def load_filter_list = Kit::FilterList.new(settings.fetch(:includes))
 
         def invalid_line? line
           line.match?(/\A\s*#{Regexp.union filter_list.to_regexp}\s[[:lower:]]+/)
@@ -37,9 +33,7 @@ module Git
 
         private
 
-        def lowercased_bullets
-          commit.body_lines.select { |line| invalid_line? line }
-        end
+        def lowercased_bullets = commit.body_lines.select { |line| invalid_line? line }
       end
     end
   end