README.adoc in git-lint-2.1.0 vs README.adoc in git-lint-2.2.0
- old
+ new
@@ -12,11 +12,11 @@
image::https://img.shields.io/badge/code_style-alchemists-brightgreen.svg[Alchemists Style Guide]
[link=https://circleci.com/gh/bkuhlmann/git-lint]
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.
@@ -25,13 +25,14 @@
== 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
[link=https://www.alchemists.io/screencasts/git_lint]
image::https://www.alchemists.io/images/screencasts/git_lint/cover.svg[Screencast,600,240,role=focal_point]
@@ -64,13 +65,13 @@
....
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:
[source,bash]
----
@@ -108,10 +109,25 @@
Now, when running `bundle exec rake -T`, you'll see `git_lint` included in the list.
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:
....
@@ -286,11 +302,11 @@
[core]
hooksPath = ~/.git_template/hooks
....
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
any of the scripts within the `.git/hooks` directory of the repository.
@@ -371,11 +387,11 @@
This gem automatically configures itself for known CI build servers (see below for details). If you
have a build server that is not listed, please log an issue or provide an implementation with
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]
Detection and configuration happens automatically by checking the `CIRCLECI` environment variable.
No additional setup required!
@@ -863,11 +879,11 @@
* Use `git commit --squash` when fixing an earlier commit, addressing code review feedback, etc.,
and want to combine multiple commit messages into a single commit message. _Avoid using squash to
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).
* Avoid checking in sensitive information (i.e. security keys, passphrases, etc).
* Avoid "WIP" (a.k.a. "Work in Progress") commits and/or code review labels. Be confident with your
@@ -925,11 +941,11 @@
or changed.
=== 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:
** Makes it easier to record milestones and capture associated release notes.
@@ -947,11 +963,11 @@
* Use hooks to augment and automate your personal workflow such as checking code quality, detecting
forgotten debug statements, etc.
* 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
@@ -1014,34 +1030,34 @@
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.
+** 🔓 (`: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 `master` and delete the feature branch at this point.
+ 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 `master` upon approval.
-* Avoid reviewing your own code review before rebasing onto `master`. Have another pair of eyes
+* 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 `master`:
+* 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 `master` branch!_
-** Ensure your feature branch is rebased upon `master`.
+ 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
@@ -1049,15 +1065,15 @@
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
+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: `master`.
+. 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_.