README.adoc in git-lint-2.2.0 vs README.adoc in git-lint-2.2.1

- old
+ new

@@ -745,13 +745,16 @@ implementation and spec. Otherwise, it might be a change to an existing file which adds new behavior. * *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 added benefit of categorizing the commits for building release notes, change logs, etc. This becomes handy when coupled with another tool, link:https://www.alchemists.io/projects/milestoner[Milestoner], @@ -945,11 +948,11 @@ * Use feature branches for new work. * 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). === Rebases @@ -970,127 +973,11 @@ 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. -** 🔓 (`: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 To contribute, run: