An overview of the
The purpose of this article is to share the Git branch design specifications as a reference for developers.
Norms are dead, people are alive, hope their own norms, not to be hit in the face.
Before we talk about the Git branch specification, let’s talk about the environment that is commonly used during system development.
| Referred to as” | The full name |
|---|---|
| DEV | Development environment |
| FAT | Feature Acceptance Test environment |
| UAT | User Acceptance Test environment |
| PRO | Production environment |
- DEV environment: for developer debugging use.
- FAT environment: A functional acceptance test environment used by software testers in a test environment.
- UAT environment: User acceptance test environment used by software testers in production environments.
- PRO environment: The production environment.
For example, if the project domain name is http://www.abc.com, the domain name of the relevant environment can be configured as follows:
- DEV environment: Configure the virtual domain name locally
- FAT environment:
http://fat.abc.com - UAT environment:
http://uat.abc.com - PRO environment:
http://www.abc.com
Next, design the branches for different environments.
branch
| branch | The name of the | The environment | Can be accessed |
|---|---|---|---|
| master | The main branch | PRO | is |
| release | Pre-line branch | UAT | is |
| hotfix | Emergency repair branch | DEV | no |
| develop | Test branch | FAT | is |
| feature | Requirements development branch | DEV | no |
The master branch
The master branch, used for deployment to a formal environment (PRO), is usually merged by the Release or Hotfix branch, and under no circumstances is code directly modified on the Master branch allowed.
The release branch
The release branch is used to deploy to the UAT. It is always consistent with the Master branch and is usually merged with the Develop or Hotfix branch. You are not advised to directly modify code on the Release branch.
If you test a problem in the Release branch, you need to regression verify the Develop branch to see if the problem exists.
Hotfix branch
Hotfix is an emergency repair branch, and the naming rule starts with hotfix-.
When there is an emergency online problem that needs to be fixed immediately, create a hotFix branch based on the Release or Master branch. When the fix is complete, merge it into the Release or Develop branch and delete it once the fix is online.
Develop branch
Develop is a test branch that can be deployed to the test environment (FAT), always keeping the completed and bug-fixed code up to date. Depending on the size of the requirement, you can decide whether to merge the feature branch or develop directly on top of it.
Code must meet the tests before it can be merged or submitted.
Feature branch
Feature is a requirement development branch, and the naming rule begins with feature-. Once the requirement goes online, it will be deleted.
This may be a little hard to understand, but here are a few development scenarios.
Development scenarios
New demand comes in
There is a new order management requirement that needs to be developed. First, we need to create a feature-order branch. The question arises: which branch is this branch based on?
If there are untested requirements, they are created based on master.
If there are no untested requirements, create them based on Develop.
-
When the requirements have been developed in the feature-order branch and are ready to be tested, make sure that develop does not have any untested requirements before the developer can merge the code into the Develop (test environment) for testers to test.
-
After the testers develop the code, the developers release the code to the release environment for testers to test.
-
After the testers pass the test in the release (pre-launch environment), the developer releases the code to the Master (official environment) for testers to test.
-
After the tester passes the master (formal environment) test, the developer needs to delete the feature-order branch.
Ordinary iteration
There is an order management iteration requirement. If the development time is less than 1d, develop directly in Develop. If the development time is more than 1D, create a branch and develop on the branch.
The process of testing and launching after development is consistent with the process of adding new requirements.
Fix test environment bugs
There is a Bug in the Develop test. If the repair time is less than 2h, fix it directly in Develop; if the repair time is more than 2h, fix it on the branch.
The process of testing and launching after repair is consistent with the process of adding new requirements.
Modify bugs in the pre-online environment
If there is a Bug in the release test, first check to see if the develop branch has the same problem.
If so, the repair process is the same as the process for fixing bugs in the test environment.
If it does not exist, this possibility is less, mostly data compatibility problems, environment configuration problems, etc.
Fix formal environment bugs
If there is a Bug in the master test, first check to see if the release and Develop branches have the same problem.
If so, the repair process is the same as the process for fixing bugs in the test environment.
If it does not exist, this possibility is relatively small, mostly data compatibility problems, environment configuration problems, etc.
Emergency fix of official environment bugs
No Bug was tested in the testing process of requirements, but a Bug appeared after the online operation for a period of time, which needs urgent repair.
I personally understand that the emergency fix means that there is no time to verify the test environment, but I recommend verifying the pre-live environment.
-
If there are untested requirements in the release branch, create a hotfix-xxx branch based on the master. When the fix is complete, release the hotfix-xxx branch to the Master for verification. When the verification is complete, merge the master code into the Release and Develop branches. Also delete the hotfix-xxx branch.
-
If there are no untested requirements in the Release branch, but there are untested requirements in the Develop branch, create the hotfix-XXX branch based on the release, and release it to the release for verification after the repair. The following process is consistent with the online process. Merge the master code into the Develop branch and delete the hotfix-xxx branch.
-
If there are no untested requirements in either the Release or Develop branch, fix them on the Develop branch and publish them to the Release for verification.
Parallel to measure
Two requirements were developed in parallel in one project, tested in parallel, but on different launch dates.
Two scenarios I can think of:
- Deploy another set of branches for testers to test
- use
git cherry-pick“Pick and choose” submissions
Do you have a good plan for parallel testing? Leave a message.
Commit Logging specification
Submit information must be filled in carefully!
Recommended reference specification:
(scope) :
For example: fix(home page module) : fix popover JS Bug.
Type indicates the type of action, which can be divided into:
- Fix: fixes the XXX Bug
- Feat: Added the XXX function
- Test: Debugs the XXX function
- Style: change XXX code format or comment
- Docs: Changes the XXX document
- Refactor: Refactor XXX functionality or method
Scope indicates the scope of influence, which can be divided into: module, class library, method, etc.
Subject indicates a short description, preferably no more than 60 words. If you have the Jira number of a Bug, you are advised to add it to the description.
summary
Think of so much temporarily, the specification of this thing is not invariable, for reference.
Recommended reading
- API interface design specifications
- What exactly are the front-line technology managers doing?
- When a person gets promoted, it’s not just about ability, it’s about trust