1. git&GitFlow
1.1. Use git
no
1.2. GitFlow version branch management strategy
The GitFlow development model constrains software development activities from the perspective of source code management. It provides a reference management model for our software development. The GitFlow development model keeps the development code repository clean and isolates the development between team members, effectively avoiding the inefficiency and confusion caused by the interaction of the code under development.
The so-called development model may need to be tailored or expanded according to different development teams, different cultures, and different project backgrounds, scales, and complexities.
1.2.1. Common branches of GitFlow
GitFlow branches include master, Develop, feature, Release, and hotfix. Master and Develop are remote branches, and feature, release, and hotfix are local branches. Remote branch refers to the remote repository that needs to be pushed to GitLab and Github. A local branch is the Git version control environment that developers use for their local development.
1.2.2. The flow chart of GitFlow is as follows
You need to know what each branch is for, when it is created, from which branch it is generated, and into which branch it is merged.
1.1.1. The master branch
ø The Master branch is the most stable branch with relatively complete functions. It can release the code of production environment at any time. Never develop and commit code directly on the Master branch to ensure that the code on the Master is always available.
The master branch is the only read-only branch that can only be merged from other branches (release/hotfix) and cannot be modified from this branch. In addition, all push in the Master branch should be labeled for easy traceability, such as release merged into master, or hotfix merged into master, need to be tagged.
1.1.1. Develop branches
This branch is used as the main branch of normal development, and always exists. It is always the latest and most complete branch, based on the master branch clone (only once).
Add the feature branch to develop and delete the feature branch
Note: it is forbidden to submit uncompiled or failed compiled code to the remote warehouse. If the coding work is not completed, it can be submitted to the local warehouse. After the function point is fully realized and the self-test passes, the code will be pushed to the remote warehouse.
ø When the Develop branch has collected all the functionality that needs to be implemented, i.e. all the code that needs to be released to the next release, pull the Release branch from the Develop branch and test it
The release/hotfix branch is online, merged into Develop and pushed
1.1.1. Feature branch
The function development branch is mainly used to develop new functions. It is based on the clone of develop branch. After the function is developed and passes the self-test, the branch is closed to Develop branch
ø Feature branches can have multiple branches at the same time, which are used for the simultaneous development of multiple functions in the team. They are temporary branches and can be deleted after the function is completed
1.1.1. The release branch
The test branch is mainly used to submit to testers for functional testing. The branch is merged into Develop based on feature and cloned from develop
Bugfix -* is created during the process of fixing bugs. After all bugs are fixed, merge them into the Develop/Master branch and push them to the master branch. Tag them in the Master branch
ø It is a temporary branch and can be deleted after the function is online
Note: If you start testing on the Release branch, you are not allowed to incorporate new features from the Develop branch into the Release branch, because the Release branch has already started testing. If you incorporate new features, you will need to retest them all. Try to release the new features in the next release.
1.1.1. The hotfix branch
The patch branch, based on the master branch clone, is mainly used to fix bugs in the online version
After the fix is complete, merge it into the Develop/Master branch and push it. Tag the master branch
ø It is a temporary branch and can be deleted after patch repair goes online
ø All hotfix branch changes go to the next release
1.1. Gitflow development practice
The development practice of Gitflow needs to be combined with JIRA. When the continuous integration platform is built in the later stage, gitLab, Maven, Jenkins, Sonarqube and other tools will be combined to continue to improve.
1.1.1. Submission criteria
In addition to the source code, other build generated items (e.g. maven target folder,.idea folder, etc.) cannot be submitted to the repository and added to the.gitignore file.
ø Developers should switch to designated branches and develop corresponding functions strictly in accordance with our agreed gitFlow version branch management process.
After completing a task, you need to test the develop code strictly according to the test case before pushing it to a remote branch.
1.1.2. Naming conventions
ø Primary branch name: master
ø Name of main development branch: Develop
ø Tag name: V *. Release, where “*” indicates the version number and “release” is lowercase, for example, v1.0.0.release
ø New function development branch name: feature-*, where “*” is the task number on the corresponding JIRA
ø Release branch name: release-*, where “*” is the version number and “release” is lowercase, for example: release-1.0.0, bugfix-* is the name of the bugfix branch
ø The name of the bug fix branch of the master: hotfix-*, where “*” indicates the task number on the corresponding JIRA
1.1.3. Developer development steps
1) Any work of developers, including new feature development task, bug modification on release and hotfix modification on master, needs to create corresponding types of problems on JIRA. The development task is created by the developers themselves, and the bugs on release and master are created by the testers. Suzhengxia-347, for example, and then create a branch for people to complete tasks or fix bugs.
1) Create a feature branch: Create a feature branch named feature-347 in the Develop branch of the project. Before creating the branch, it is best to pull down the latest code, because someone else may have submitted the code that passed the test.
To ensure that the current branch is the latest Develop branch, right-click on the project and select git — Repository — Branches…
Select New Branch
Enter the branch name feature-347
1) Merge feature-347 into the Develop branch when the new feature is complete and self-tested according to the test case provided by the tester.
Switch the current branch to the Develop branch, and perform a pull operation to pull the latest code and prevent conflicts.
Select feature-347 branch and Merge into Current to complete develop.
1.1.1. Problems encountered in practice
1) feature management
The number of features managed by the team is small, and the station will communicate with each other every day. The merged features will also be deleted in time, and the number of features at the same time is basically fixed at the same scale. Use Tencent cloud online editing tool to maintain a document for management.
2) Database script management
Method 1: Developers organize their own scripts
One script directory for each feature, and an empty directory for those without scripts. Finally, the number of script directories will be as many as the number of features released. Before the release, someone will sort them into batches and execute them with one click. Script submission time: the script must be submitted after the feature is merged. It is not completed until the testers have tested all the functions and scripts. We should put the scripts in a unified directory.
Method 2: One person is responsible for organizing the scripts of the whole project team
The person in charge of the script is generally the person in charge of the merge and the publisher. In the design stage, the database scripts required by the function should be sorted out. If there is any change in the later stage, the person in charge of the script should be notified.