Git is by far the most popular source code management tool. In order to standardize development, keep code submission records and git branch structure clear, and facilitate subsequent maintenance, git related operations are standardized.

Branch management

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

Develop branch

  • Develop is a branch of development that keeps code up to date and bug-fixed
  • When developing new features, the Feature branch is created under the Develop branch

Feature branch

  • When developing new features, create a feature branch based on Develop
  • Branches are named feature branches that start with feature/ and are named feature/user_module and feature/cart_module

The release branch

  • Release is the pre-online branch, and the release branch code will be used as the benchmark test in the release test stage
When a set of features are developed, they are first merged into the Develop branch, and release branch is created when testing. If there are bugs that need to be fixed during testing, they are fixed and submitted directly by the developer in the Release branch. When the test is complete, merge the Release branch to the Master and Develop branch, where master is the latest code and is used to go live.Copy the code

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 with the Master branch and Develop branch

Common tasks

Add new features

(dev)$: git checkout -b feature/xxx            Build a feature branch from dev
(feature/xxx)$: blabla                         # development
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff          # merge the feature branch into dev
Copy the code

Fix emergency bug

(master)$: git checkout -b hotfix/xxx         Create hotfix branch from master
(hotfix/xxx)$: blabla                         # development
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       Merge hotfix branch into master and live in production
(dev)$: git merge hotfix/xxx --no-ff          # merge the hotfix branch into dev to synchronize the code
Copy the code

Test environment code

(release)$: git merge dev --no-ff             # merge the dev branch into Release, then pull and test in the test environment
Copy the code

Online production environment

(master)$: git merge release --no-ff          # Merge the code tested in release into master for operation and maintenance
(master)$: git tag -aV0.1 -m'Deployment package version name'  Name the version with a Tag
Copy the code

The 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

There are currently several community specifications for how to write Commit messages. The Angular specification is currently the most widely used, reasonable and systematic. The diagram below:

Basic syntax for Commit Messages

Angular Git Commit Guidelines are currently widely used in the industry

The specific format is:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code
  • 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. See the case for details

Description of Type:

  • Feat: Add a new feature
  • Fix: fix the bug
  • Docs: Only modified documents
  • Style: Just changed Spaces, formatting indentation, all good, etc., without changing the code logic
  • Refactor: Code refactored without adding new features or fixing bugs
  • Perf: Add code for performance testing
  • Test: Adds test cases
  • Chore: Change the build process, or add dependency libraries, tools, etc

Commit Messages format requirements

# Header line: 50 characters or less, describing major changes
#
# Body content: More detailed descriptive text. 72 characters or less is recommended. The following information needs to be described:
#
Why is this change necessary? It may 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 needed
Copy the code

Refer to the link

  • Git branch management policy
  • Git Commit Messages
  • Git Commit Specification Guide