diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..0c3a5be --- /dev/null +++ b/.gitattributes @@ -0,0 +1,104 @@ +* text=auto + +#common settings that generally should always be used with your language specific settings + +# Auto detect text files and perform LF normalization +# http://davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/ +# Commented because this line appears before in the file. +# Commented because this line appears before in the file. +# # * text=auto + +# +# The above will handle all files NOT found below +# + +# Documents +*.doc diff=astextplain +*.DOC diff=astextplain +*.docx diff=astextplain +*.DOCX diff=astextplain +*.dot diff=astextplain +*.DOT diff=astextplain +*.pdf diff=astextplain +*.PDF diff=astextplain +*.rtf diff=astextplain +*.RTF diff=astextplain +*.md text +*.adoc text +*.textile text +*.mustache text +*.csv text +*.tab text +*.tsv text +*.sql text + +# Graphics +*.png binary +*.jpg binary +*.jpeg binary +*.gif binary +*.tif binary +*.tiff binary +*.ico binary +# SVG treated as an asset (binary) by default. If you want to treat it as text, +# comment-out the following line and uncomment the line after. +*.svg binary +#*.svg text +*.eps binary + + +############################################################################### +# Set default behavior to automatically normalize line endings. +############################################################################### +# Commented because this line appears before in the file. +# * text=auto + +############################################################################### +# Set the merge driver for project and solution files +# +# Merging from the command prompt will add diff markers to the files if there +# are conflicts (Merging from VS is not affected by the settings below, in VS +# the diff markers are never inserted). Diff markers may cause the following +# file extensions to fail to load in VS. An alternative would be to treat +# these files as binary and thus will always conflict and require user +# intervention with every merge. To do so, just comment the entries below and +# uncomment the group further below +############################################################################### + +*.sln text eol=crlf +*.csproj text eol=crlf +*.vbproj text eol=crlf +*.vcxproj text eol=crlf +*.vcproj text eol=crlf +*.dbproj text eol=crlf +*.fsproj text eol=crlf +*.lsproj text eol=crlf +*.wixproj text eol=crlf +*.modelproj text eol=crlf +*.sqlproj text eol=crlf +*.wmaproj text eol=crlf + +*.xproj text eol=crlf +*.props text eol=crlf +*.filters text eol=crlf +*.vcxitems text eol=crlf + + +#*.sln merge=binary +#*.csproj merge=binary +#*.vbproj merge=binary +#*.vcxproj merge=binary +#*.vcproj merge=binary +#*.dbproj merge=binary +#*.fsproj merge=binary +#*.lsproj merge=binary +#*.wixproj merge=binary +#*.modelproj merge=binary +#*.sqlproj merge=binary +#*.wwaproj merge=binary + +#*.xproj merge=binary +#*.props merge=binary +#*.filters merge=binary +#*.vcxitems merge=binary + diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..8e7b7f9 --- /dev/null +++ b/.github/CODE_OF_CONDUCT.md @@ -0,0 +1,74 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, gender identity and expression, level of experience, +nationality, personal appearance, race, religion, or sexual identity and +orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by [contacting the project team][email]. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +[email]: greg@swindle.net +[homepage]: https://www.contributor-covenant.org diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 0000000..5e65d87 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,1116 @@ +[![Generator Community Repo][product-repo-logo-image]][product-repo-url] + +# Contributing
to `architecture-decision-records` +> [![PRs Welcome][makeapullrequest-image]][makeapullrequest-url] +> +> Welcome to `architecture-decision-records`. You're among people eager to promote recommended community standards that encourage open source consumption and contributions with comprehensive `README`, `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `LICENSE` documents. If you are curious, you're already a member! + +**Contributions** start with **community conversations** that lead to **positive change.** Open source provides a flexible collaboration model that facilitates change, even among perfect strangers. Contributions therefore: + + 1. Begin with **Issues**, + 2. Occur in **Pull Requests**, and + 3. End with **Merges**. + +## Table of contents + + +- [1. Issues](#1-issues) + * [1.1. Create Issues for feature requests and defects.](#11-create-issues-for-feature-requests-and-defects) + * [1.2. Format titles with **`type(scope): subject`**.](#12-format-titles-with-typescope-subject) + * [1.3. Fill out the issue template.](#13-fill-out-the-issue-template) + * [1.4. Label the issue (optional).](#14-label-the-issue-optional) + * [1.5. Monitor your issue for questions.](#15-monitor-your-issue-for-questions) + * [1.6. Your issue will be either accepted for work, or declined.](#16-your-issue-will-be-either-accepted-for-work-or-declined) +- [2. **Git**](#2-git) + * [2.1. **Rules**](#21-rules) + + [2.1.1. Makes changes in a topic branch.](#211-makes-changes-in-a-topic-branch) + + [2.1.2. Favor the topic branch naming recommendation `type/issue-change-name`.](#212-favor-the-topic-branch-naming-recommendation-typeissue-change-name) + + [2.1.3. Branch out from `master`.](#213-branch-out-from-master) + + [2.1.4. ***Never*** push into the `master` branch. ***Always*** submit a Pull Request.](#214-never-push-into-the-master-branch-always-submit-a-pull-request) + + [2.1.5. Submit a Pull Request as soon as possible.](#215-submit-a-pull-request-as-soon-as-possible) + + [2.1.6. Rebase your local `master` branch before you ask for PR approvals.](#216-rebase-your-local-master-branch-before-you-ask-for-pr-approvals) + + [2.1.7. Resolve rebase conflicts before Pull Request reviews.](#217-resolve-rebase-conflicts-before-pull-request-reviews) + + [2.1.8. Add reviewers and the label `Status: Needs Review` when the topic branch is ready.](#218-add-reviewers-and-the-label-status-needs-review-when-the-topic-branch-is-ready) + + [2.1.9. Delete local and remote topic branches after merging.](#219-delete-local-and-remote-topic-branches-after-merging) + + [2.1.10. Protect your `master` branch.](#2110-protect-your-master-branch) + * [2.2. **Feature-branch-workflow**](#22-feature-branch-workflow) + + [2.2.1. Initialize a Git repository in the product directory (_for new repositories only_).](#221-initialize-a-git-repository-in-the-product-directory-_for-new-repositories-only_) + + [2.2.2. Checkout a new `feat`ure or `fix` branch.](#222-checkout-a-new-feature-or-fix-branch) + + [2.2.3. Make Changes.](#223-make-changes) + + [2.2.4. Follow the Conventional Commits Specification for commit messages.](#224-follow-the-conventional-commits-specification-for-commit-messages) + + [2.2.5. Sync with remote to get changes you’ve missed.](#225-sync-with-remote-to-get-changes-youve-missed) + + [2.2.6. Update your topic branch with the latest changes from `master` by interactive rebase.](#226-update-your-topic-branch-with-the-latest-changes-from-master-by-interactive-rebase) + + [2.2.7. Resolve conflicts (if any occur), and continue rebase.](#227-resolve-conflicts-if-any-occur-and-continue-rebase) + + [2.2.8. Push your branch with the `-f` flag (if necessary).](#228-push-your-branch-with-the--f-flag-if-necessary) + + [2.2.9. Submit a Pull Request.](#229-submit-a-pull-request) + + [2.2.10. Once accepted, the Pull request will be merged, closed, and deleted by an administrator.](#2210-once-accepted-the-pull-request-will-be-merged-closed-and-deleted-by-an-administrator) + + [2.2.11. Remove your local topic branch if you're done.](#2211-remove-your-local-topic-branch-if-youre-done) + * [2.3. **Tell your boss how Git enables collaborative process models.**](#23-tell-your-boss-how-git-enables-collaborative-process-models) + + [2.3.1. Explain that inner and open source are _process models_.](#231-explain-that-inner-and-open-source-are-_process-models_) + + [2.3.2. Describe a typical Git workflow in collaborative terms.](#232-describe-a-typical-git-workflow-in-collaborative-terms) +- [3. **Code standards**](#3-code-standards) + * [3.1. Use the Standard JS Style.](#31-use-the-standard-js-style) + * [3.2. Use ESLint to analyze source code.](#32-use-eslint-to-analyze-source-code) +- [4. **Unit testing**](#4-unit-testing) + * [4.1. Write Jest tests.](#41-write-jest-tests) + * [4.2. Reach 100% code coverage.](#42-reach-100%25-code-coverage) +- [5. **Directory structure**](#5-directory-structure) +- [6. **Logging**](#6-logging) +- [7. **Dependencies**](#7-dependencies) +- [8. **APIs**](#8-apis) + * [8.1 **API design**](#81-api-design) + * [8.2 **API security**](#82-api-security) + * [8.3 **API documentation**](#83-api-documentation) +- [9. **Licensing**](#9-licensing) + + +## 1. Issues + +![Issues][icon-issue-image] + +* **Collaboration starts with *Issues*. Changes happen through *Pull Requests*.** + + View `architecture-decision-records's` collaboration and contribution flowcharts: + + --- + +
+ Help Toggle view of the Issue workflow flowchart. + + ![Issue flowchart][contribution-lifecycle-issues-image] + +
+ + --- + +
+ Help Toggle view of the Pull Request workflow flowchart. + + ![Pull Request flowchart][contribution-lifecycle-pr-image] + +
+ + --- + +* ### 1.1. Create Issues for feature requests and defects. + + _Why:_ + > ⌦ `architecture-decision-records` follows an issue-driven product delivery model. + > Before any work is done, create an Issue, first. This starts a + > conversation about features, defects ("bugs"), refactoring, product + > delivery improvements, etc. + + Go ahead! Get started now: + + * [Report a defect ("bug")][issues-new-defect-url] + * [Request a feature][issues-new-feat-url] + * [Review all open issues][issues-url] + +* ### 1.2. Format titles with **`type(scope): subject`**. + + _Why:_ + > ⌦`type` categorizes product changes. Valid types are: + > + > * `build`: Changes that affect the build system or external dependencies. + > * `ci`: Changes related to continuous integration, delivery, and deployment tasks. + > * `docs`: Documentation changes. + > * `feat`: A new feature. + > * `fix`: Defect (bug) repair. + > * `perf`: Performance enhancements. + > * `refactor`: Source code design improvements that don't affect product behavior. + > * `style`: Changes involving graphics, typography, etc., as well as source code beautification. + > * `test`: Tests added to increase code coverage, or corrected due to errors. + +* ### 1.3. Fill out the issue template. + + _Why:_ + > ⌦It keeps communication consistent and unambiguous. + +* ### 1.4. Label the issue (optional). + + _Why:_ + > ⌦ We use [`git-labelmaker`][gh-git-labelmaker-url] to categorize Issues (and Pull Requests) consistently. There are four label categories: + > + > * `Type`: the "kind" of product change. + > * `Status`: the state of a change. + > * `Priority`: the importance and value of a change. + > * `Points`: the size/complexity of a change. + + --- + +
+ Help Toggle view of the Label definitions table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Label 🏷Definition
Type: FeatureA distinguished or expected characteristic of a product that either differentiates the product from competitors, or whose absence would be diminish the product’s value.

Note that Type: Feature and Type: Defect are mutually exclusive: an Issue cannot be both a feature and a defect.
Type: DefectA flaw, fault, or abnormality that deviates from or prevents the product’s expected behavior.

Note that Type: Feature and Type: Defect are mutually exclusive: an Issue cannot be both a feature and a defect.
CLA: SignedThe person who submitted a product change has signed your Contributor License Agreement.

Remove this label if your product owner does not require a CLA.
CLA: UnsignedThe person who submitted a product change has **not**signed your Contributor License Agreement.

Remove this label if your product owner does not require a CLA.
Priority: CriticalType: Feature: The proposed enhancement is essential to the success of your product.

Type: Defect: Your product no longer functions due to internal, FATAL errors, and must be addressed immediately in order to maintain consumer loyalty.
Priority: HighType: Feature: The proposed enhancement is central to product’s value proposition, and should be implemented as soon as possible.

Type: Defect: The product functions overall, but with an issue that risks consumer abandonment.
Priority: MediumType: Feature or Type: Defect: The proposed change should be implemented as long as no Priority: Critical or Priority: High issues exists.
Priority: LowType: Feature: A proposal that minimally affects the product’s value.

Type: Defect: Represents “cosmetic” problems like misspelled words or misaligned text that do not affect branding and marketing strategy.
Status: AbandonedType: Feature or Type: Defect: The team and community have neglected, forgotten, discarded, or ignored resolving a Issue.
Status: AcceptedType: Feature or Type: Defect: The product owner or maintainers agreed to a product change proposal.
Status: AvailableType: Feature and Type: Defect: The change proposal is ready for team and community members to work on.
Status: BlockedType: Feature and Type: Defect: The proposed change cannot be addressed until another issue has been resolved.

Note that the Issue blocking the proposed change SHOULD be referenced in the Blocked Issue’s description field.
Status: CompletedType: Feature and Type: Defect: The issue has been resolved and all acceptance criteria validated.
Status: In ProgressType: Feature and Type: Defect: The team or community is actively working on the Issue’s resolution.
Status: On HoldType: Feature and Type: Defect: The Product Owner has (temporarily) postponed Issue resolution.

Note that the reason for postponement should be stated in the Issue’s description field.
Status: PendingType: Feature and Type: Defect: product change or resolution is either awaiting the Product Owner’s decision. Ideally, the Product Owner should declare why they’re undecided somewhere in the Issue thread.
Status: RejectedType: Feature and Type: Defect: The Product Owner has declined a change proposal.

Note that the Product Owner should politely explain why they dismissed the change request.
Status: Review NeededType: Feature and Type: Defect: The person working on an Issue has requested help or discussion. When applied to a Pull Request, Status: Review Needed signifies that the PR is ready for evaluation (and potentially, approval).
Status: Revision NeededType: Feature and Type: Defect: The Issue is not ready for evaluation because of incomplete or insufficient information.
Type: Breaking ChangeThe change introduces backward incompatibility with previous product versions.

Type: Breaking Change MUST be recorded with a

  1. Git commit message,
  2. An increment (+1) in the product’s Semantic Version’s MAJOR version,
  3. CHANGELOG entry, and
  4. Updated API documentation.
Type: BuildChanges to the process that convert source code into a stand-alone form that can be run on a computer or to the form itself.
Type: ChoreMiscellaneous non-functional changes such as typographical fixes or source code repository initialization, e.g., chore(scm): scaffold product directory structure
Type: CIContinuous Integration (CI) changes, i.e., automated build, test, an quality assurance tasks.
Type:../docsThe introduction of or revisions to natural language documents or source code comments.
Type: DuplicateAn Issue that shares the same characteristics as a previously reported issue.

Note that product maintainers should reference the original Issue and close the Type: Duplicate Issue.
Type: FeedbackA response to a Type: Question or voluntary information used as a basis for improvement.
Type: FixA change intended to repair a Type: Defect Issue.
Type: PerformanceA change intended to reduce product latency.
Type: QuestionA request for information.
Type: RefactorSource code design improvements that do not affect product behavior.
Type: RevertChanges that return the product’s source code to previous Git commit hash.
Type: SpikeA technical or design experiment that investigates a possible solution.

Note that spike solutions are, by definition, throwaway solutions that should NEVER be added to a product release.
Type: StyleIssues that address code standard or brand compliance.
Type: TestIssues that prove intended behavior or substantiate “definitions of done.”

Type: Test can also refer to changes that result in broader code coverage.
+
+ + --- + +* ### 1.5. Monitor your issue for questions. + + _Why:_ + > ⌦ The team might need more clarification. + +* ### 1.6. Your issue will be either accepted for work, or declined. + + _Why:_ + > ⌦ It's up to the Product Owner to agree to proposed changes. If they believe your issue add value, the issue will be approved, and we'll ask someone to volunteer to do the work. + > + > Otherwise, your issue will be politely declined. + + +## 2. **Git** + +![Git Logo][icon-git-logo-image] + +* ### 2.1. **Rules** + + `architecture-decision-records` manages contributions with the [feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow). + +* #### 2.1.1. Makes changes in a topic branch. + + _Why:_ + > ⌦ Use an isolated topic branch for parallel product development. Topic branches allow you to submit multiple pull requests without confusion. You can iterate without polluting the master branch with potentially unstable, unfinished code. The `architecture-decision-records` team uses: + > + > * [Feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) for small-ish codebases, or + > * [Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) for large applications and monoliths + +* #### 2.1.2. Favor the topic branch naming recommendation `type/issue-change-name`. + + _Why:_ + > ⌦ Although not required, our team prefixes branches with the type of change being introduced, followed by a forward slash and the issue id. + > + > Pattern: `type/issueId-subject`
+ > Icon legend: ![Bitbucket branch prefix][icon-bitbucket-20-image] Bitbucket + > ![GitHub branch prefix][icon-github-20-image] GitHub + > + >
+ >
bugfix/
+ >
Applies to Bitbucket branches Defect (bug) repair issues.
+ >
build/
+ >
Applies to GitHub branches Issues related to product builds.
+ >
ci/
+ >
Applies to GitHub branches Issues related to continuous integration, delivery, and deployment tasks.
+ >
docs/
+ >
Applies to GitHub branches Issues related to documentation.
+ >
feat/
+ >
Applies to GitHub branches New feature or enhancement requests.
+ >
feature/
+ >
Applies to Bitbucket branches New feature or enhancement requests.
+ >
fix/
+ >
Applies to GitHub branches Defect (bug) repair issues.
+ >
+ >
Applies to Bitbucket branches `hotfix/`
+ >
perf/
+ >
Applies to GitHub branches Performance improvement issues.
+ >
refactor/
+ >
Applies to GitHub branches Source code design **improvements that do not affect product behavior**.
+ >
revert/
+ >
Applies to GitHub branches Tasks that revert to a previous commit hash.
+ >
spike/
+ >
Applies to GitHub branches Issues related in solution investigation.
+ >
style/
+ >
Applies to GitHub branches Issues related to style guideline compliance, especially `ESLint` errors and warnings.
+ >
test/
+ >
Applies to GitHub branches Test coverage tasks.
+ > + +* #### 2.1.3. Branch out from `master`. + + _Why:_ + > ⌦ `architecture-decision-records` follows the feature-branch-workflow. + +* #### 2.1.4. ***Never*** push into the `master` branch. ***Always*** submit a Pull Request. + + _Why:_ + > ⌦ It notifies team members whenever changes occur and allows the community to review your changes at any time.. + > + > It also enables easy peer-review of the code and dedicates forum for discussing the proposed feature. + +* #### 2.1.5. Submit a Pull Request as soon as possible. + + _Why:_ + > ⌦ Pull Requests declare work in progress. Frequent pushes to a Pull Request notify your team members about change, and gives them the opportunity to provide feedback more often. + > + > Pull Request pushes also trigger automated CI-services, which help you fail fast and assess quality. + +* #### 2.1.6. Rebase your local `master` branch before you ask for PR approvals. + + _Why:_ + > ⌦ Rebasing will merge in the requested branch (`master` or `develop`) and apply the commits that you have made locally to the top of the history without creating a merge commit (assuming there were no conflicts). This results in a nice and clean history. + +* #### 2.1.7. Resolve rebase conflicts before Pull Request reviews. + + _Why:_ + > ⌦ Rebasing will merge in the `master` branch and apply the commits that you have made locally to the top of it. + +* #### 2.1.8. Add reviewers and the label `Status: Needs Review` when the topic branch is ready. + + _Why:_ + > ⌦ When you add a Reviewer, GitHub (or Bitbucket) notifies teammates that your topic branch meets all Acceptance Criteria and is ready to be merged into `master`. + > + > Add the label "Status: Review Needed" formally declares the status of your topic branch, and helps teams filter through issues. + +* #### 2.1.9. Delete local and remote topic branches after merging. + + _Why:_ + > ⌦ Topic branches should only exist while work is in-progress. Merged topic branches clutter up your list of branches with dead branches. Topic branch deletion also insures that you only ever merge back into `master`. + +* #### 2.1.10. Protect your `master` branch. + + _Why:_ + > ⌦ Branch protection prevents production-ready branches from incorporating unexpected and irreversible changes. Learn more about + > + > * [GitHub protected branches](https://help.github.com/articles/about-protected-branches/) and + > * [Bitbucket protected branches](https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html). + +* ### 2.2. **Feature-branch-workflow** + + We use the [feature-branch-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow). We _recommend_ [interactive rebasing](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing), too, but that's not required. + + + +* #### 2.2.1. Initialize a Git repository in the product directory (_for new repositories only_). + + For subsequent features and changes, this step should be ignored. + + ```sh + cd + git init + ``` + +* #### 2.2.2. Checkout a new `feat`ure or `fix` branch. + + ```sh + # For a new feature branch: + git checkout -b feat/-scope-of-change + + # For branches that address defects: + git checkout -b fix/-scope-of-change + ``` + +* #### 2.2.3. Make Changes. + + ```sh + git add + git commit -a + ``` + + _Why:_ + > ⌦ `git commit -a` will start an editor which lets you separate the subject from the body. Read more about it in *section 1.3*. + +* #### 2.2.4. Follow the Conventional Commits Specification for commit messages. + + This project enforces [AngularJS Git Commit Guidelines][git-commit-guidelines-url] (which is now an extension of the [Conventional Commits Specfication][conventional-commits-url]) with [`commitplease`][commitplease-url] pre-commit hooks. + + _Why:_ + > Consistent, legible Git logs not only facilitate communication, but also enable automated `CHANGELOG` generation and semantic versioning with [`standard-version`][standard-version-url]. + + * **`build` commit messages** + + Issues related to product builds. + + ``` + build(): + + <[body]> + +