First, branch management

“This is the first day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021”

Branch name:

The master branch

  • Master The master branch is also used to deploy the production environment to ensure the stability of the master branch
  • The Master branch is usually combined with the Develop and Hotfix branches, so you can’t change the code directly at any time

The test branch

  • Test is the test branch, and the test branch code will be used as the benchmark in the release and test phase

The release branch

  • Release is the pre-live branch

Feature branch

  • When developing new features, create feature branches based on master
  • Branches are named feature branches that start with feature/ and are named feature/ xxx_Module and feature/ xxx_Module

Hotfix branch

  • Branch naming: Hotfix/indicates the repair branch, and its naming rules are similar to feature branches
  • Create hotfix branches based on the Master branch and merge the hotfix branches into the Test, Master, and Develop branches

Process:

  • When a set of features is developed, they are first merged into the Develop branch and then into the Test branch.
  • If there are bugs that need to be fixed during the test, the developer will fix them in his feature branch and submit them, and repeat the above process.
  • When the test is complete, merge the feature branch to the master and Develop branch, where master is the latest code and is used to launch.

Common tasks:

> (master)$: git checkout -b feature/ XXX # git add xxx > (feature/xxx)$: git commit -m 'commit comment' > (develop)$: Git merge feature/ XXX --no-ff # Git checkout -b hotfix/ XXX # Create hotfix branch from master > (hotfix/ XXX)$: > (hotfix/ XXX)$: git add xxx > (hotfix/xxx)$: git commit -m 'commit comment' > (master)$: Git merge hotfix/ XXX --no-ff # merge hotfix branch with master > (develop)$: Git merge hotfix/ XXX --no-ff # > (test)$: git merge develop --no-ff # > (master)$: git merge testing --no-ff # Git tag -a v1.2.1 -m 'git tag -a v1.2.1 -m' git tag -a v1.2.1 -m 'git tag -a v1.2.1 -m' git tag -a v1.2.1 -m Each element must be incremented numerically. Each release of a relatively large function can be understood as an iteration, which can also be determined according to the project you are developing. The second and revision numbers are zeroed out at each increment. # Secondary version number: the version number released each time a small feature is added. The revision number is zeroed out each increment. # Revision number: # The version released when fixing the bug.Copy the code

Git merge git merge –no-ff

Second, log specification

On a team project, developers often have to submit code to fix bugs or implement new features. The documentation in the project and what features it implements and what problems it solves will fade into oblivion, and you’ll end up wasting time reading code. But a good logging specification for Commit Messages writing helps, and it also reflects whether a developer is a good collaborator. Well-written Commit Messages serve three important purposes:

  • Speed up the review process
  • Help us write good release logs
  • Let subsequent maintainers know why a particular change occurred in the code and why a feature was added

The Angular specification is currently the most widely used, reasonable and systematic.

Basic syntax for Commit Messages:

The most widely used Angular Git Commit Guidelines are:

  • Type: Specifies the type of the commit, such as Bugfix Docs style
  • Scope: indicates the scope of the commit
  • Subject: Briefly explain the main purpose of this commit, and specially emphasize the following points in the original text: 1. Use imperative sentence, is not a very familiar and unfamiliar word, to portal here imperative sentence 2. 3. End without punctuation
  • Body: use same imperative sentence, we need to put in the body content of this commit detailed description, such as the motivation of the change, if you need a newline, use |
  • Footer: Describe the issue or break change associated with it

Description of Type:

  • Feat: Add a new feature
  • Fix: fix the bug
  • Docs: Only modified documents
  • Style: Just change Spaces, indentation, commas, etc., without changing the code logic
  • Refactor: Code refactored without adding new features or fixing bugs
  • Perf: Add code for performance testing
  • Test: Adding test cases is fine
  • Chore: Change the build process, or add dependency libraries, tools, etc
  • Revert: Rolls back an earlier submission
  • Build: The main purpose is to modify the commit of the project build system (e.g. glUP, Webpack, rollup configuration, etc.)
  • Ci: The main purpose is to modify the submission of the project to continue the integration process (e.g. Travis, Jenkins, GitLab CI, Circle, etc.)

A simple example:

Git commit -m 'feat: add git commit -m 'fix: add git commit -m 'Copy the code
#### Commit messages format: # Title line: a maximum of 50 characters. # Body text: a maximum of 72 characters. The information you need to describe includes: * Why is this change necessary? It might be used to fix a bug, add a feature, improve performance, reliability, stability, etc. * How does he solve the problem? Describe specific steps to solve the problem * Are there any side effects or risks? Add a link to the issue address or other document if neededCopy the code