The problem we often encounter in teamwork is that everyone has their own development habits, which include but are not limited to coding style, tool use, etc., so there are all kinds of problems in collaboration. This article will start with a very small entry point, Git Commit Message, as the title suggests.

A good branch management model and a good Git Commit Message are essential for standardized development.

Derivative readings on Git branch management model and GitFlow

Why standardize Git Commit messages

We probably see this a lot in project development

  • Inexplicable sequence of commit logs
  • Commit messages are written so simply that there is no way to tell the intent of the commit from the commit message
  • Commit messages are written haphazardly, and there is no connection between commit messages and code changes
  • Commit The information is written too redundantly

I believe that more or less everyone has encountered. When it comes to code rollback, issue backtracking, Changelog, semantic version release, etc., as a PM, you must be confused even if the PM is involved in the whole CR process.

The ideal Git Commit Message should be able to solve the above problems

  • When a problem occurs, quickly have the PM identify the problem code and roll back
  • Commit makes a connection between code and related issues, so that any code can solve the problem regionally (this also requires a good branching model).

On the other hand, semantic release of Changelog is more like rationalization after commit.

Git Commit Message

Personally, a good COMMIT has the following characteristics

  • Abstemious
  • succinct
  • Strongly associated with code and issue, conducive to CR

How to write a normalized Git Commit Message

Angular Git Commit Guidelines are currently widely used in the industry

The specific format is:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code

Type: the type of this commit, such as bugfix docs style. Scope: the scope of this commit. Subject: The main purpose of this commit. Use imperative sentence, is not a very familiar and unfamiliar word, to portal here imperative sentence 2. First letter capital 3. Don’t end without adding punctuation body: use the same imperative sentence, we need to put this in the body content commit detailed description, such as the motivation of the change, if you need a newline, then use | footer: Describe the issue or break change associated with it. See the case for details

On the one hand, we can pass the COMMIT template, but this is difficult to grasp for the overall control. So as the title suggests, I took an instrumental approach.

The problem will be broken down

How do you leverage tools to help generate commit

Commitizen is a tool for formatting Git commit messages. It provides an inquisitive way to get the information you need, and within a larger framework there are certain paradigms we want to follow (i.e., the types of personalized content such as types). This is hosted by an Adapter in Commitizen. For example, the Angular specification mentioned above is implemented by CZ-Conventional – Changelog.

How do you leverage tools to assist in verifying commit

Commitlint validates git commit messages. Commitlint validates git commit messages with an Adapter like Commitizen. For example, validation of the Angular specification is presented by @commitlint/ config-Conventional.

When does it make sense to check

That’s where Husky comes in. Attach all available hooks.

In older versions it was in package.json

"scripts": {
  "commitmsg": "commitlint -e $GIT_PARAMS"
}

In the new version

  "husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  }
Copy the code

Changelog came naturally

With commitizen’s normalization of Git Commit messages, it’s easy to automate changelog generation based on Commit messages.

Normally, we can use standard-version or Semantic-Release to generate Changelog.

The difference between standard-version and Semantic-release, Standard-version is only for local Git repo and semantic-release is for push or NPM publish.

On the other hand, if your project is managed by Mono Repo via Lerna, and the code is hosted on Github, Lerna has a solution of its own, a way to mark pr and issues based on Github tags. This can see my previous article monorepo new wave | introduce lerna.

The project of actual combat

In actual our business project currently has two scenarios, one kind is ordinary repo, and there’s a mono repo, if you still don’t know mono repo is what of, can under reference before I wrote this article monorepo new wave | introduce lerna, This article is also mentioned above.

Ordinary repo

To get you started, I’ve put together a sample rebo-normal repo, Starter Kit with zero-config for building a library in ES6 featuring Prettier, Semantic Release, and more! This is a work in progress REPO, Babel part is missing at the moment, ts part is needed if you are A TS user, these are the parts that need to be patched up later.

Here’s the key, package.json

 "scripts": {
  "ct": "git-cz",
  "precommit": "lint-staged",
  "commitmsg": "commitlint -e $GIT_PARAMS",
  "release": "standard-version"
},
"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
},
"standard-version": {
  "skip": {
    "commit": true,
    "tag": true
  }
},
"lint-staged": {
  "*.js": [
    "prettier --trailing-comma es5 --single-quote --write",
    "git add"
  ]
},

In normal development, we would change to the following:

Step 1: Use commitizen instead of git commit

use

$ npm run ct

To replace git commit

If you are a sourceTree user, don’t worry, you can visualise the operation and then execute the CT command from the command line. This part really breaks the whole experience and there is no better way to solve it.

Step 2: Format the code

There is no need for manual intervention in this step, as Lint-staged formatting is automated in PreCOMMIT to ensure code styles are as consistent as possible

Step 3: Commit message validation

This step also does not require human intervention, as commitLint in COMMITMsg automatically validates the MSG specification

Step 4: When there is a release requirement

use

$ npm run release

In this step, we rely on the ability of standard-version and output Changelog. If you are careful, you can see that when configuring standard-version, we ignore relevant marking operations. The reason is that we will intervene to modify Changelog because changelog relying on commit MSG may not be intuitive to users. If there is no such special need, you can choose marking.

"standard-version": {
  "skip": {
    "commit": true,
    "tag": true
  }
},
Copy the code

Step 5: Publish

$ npm publish
Copy the code

mono repo

Again, this is a quick start example using Mono repo. Starter Kit with Lerna and zero-config for building a library in ES6 featuring Prettier, Semantic Release, and more!

The biggest difference of Mono repo is that different Commiizen Adapter is needed to adapt to the special project structure of Mono Repo, so we also choose CZ-Lerna-Changelog here. The biggest reason is that we want the commit to implement the corresponding package when generating the Changelog from the COMMIT, and to have a consolidated Changelog that represents all the sub-packages of the Changelog.

For the key part, go to package.json

"scripts": {
  "ct": "git-cz",
  "precommit": "lint-staged",
  "commitmsg": "commitlint -e $GIT_PARAMS",
  "release": "lerna publish --conventional-commits --skip-git --skip-npm",
  "publish": "./tasks/publish.js"
},
"config": {
  "commitizen": {
    "path": "./node_modules/cz-lerna-changelog"
  }
},
"lint-staged": {
  "*.js": [
    "prettier --trailing-comma es5 --single-quote --write",
    "git add"
  ]
},
Copy the code

I’m just going to talk about the differences here

Step 4: When there is a release requirement

use

$ npm run release

In this step, we made use of Lerna’s own ability to generate Changelog according to commit MSG. We also ignored the marking and publishing process, because we still needed to modify the automatically generated Changelog. The problem with this operation is that you need to publish manually afterwards. In a real business project, the option would be to create a new Tasks directory in the root of the project with some automation scripts, such as publish.js

So instead we use release to generate Changelog, which we modify, and then we go to the root directory and run NPM publish to execute tasks/publish.js. This is something I haven’t synchronized into the example yet, but will add later.

Step 5: Publish

$ npm run publish
Copy the code

The reason is an appeal.

conclusion

Listen to a few days ago UCAN share, WenBoHua mentioned is especially impressive, carelessness is growth must be of the ascent, it must be tough, so there is no above tools can be developed, but its existence is to allow people to develop good habits of collaboration, and good habit is can let a person benefit for life, so I hope you, as a reader can set foot on the climb.

Ref: github.com/angular/ang…