Gitlab Flow

The branch status of the project is:

  • Master: The master branch is used to store the released versions. Any time you get a stable distribution from this branch, it will be the stable distribution.
  • Develop: a development branch used for daily development and to hold the latest development releases;
  • FEAT -XXX < Feature Branch > : Feature branches that, once developed, are merged into Develop or Master and then deleted;
  • Hotfix-xxx

    : Formal environment patch branch, once developed, they are merged into Develop or Master and then deleted;
  • Fix-xxx < Fix Branch > : Development environment patch branches, which are merged into Develop or Master and then deleted once development is complete;

Branch,

Master the main branch

The codebase has one and only one main branch. The official versions available to users are distributed on this main branch. Tag each release with a Tag such as 0.1, 0.2 or 0.3.

Develop Development Branch

Developers routinely develop and test branches of functionality. If you want to publish formally, you need to “merge” the Develop branch on the Master branch. Since GitLab sets branch protection on Master by default (this setting allows cancellation, but does not recommend cancellation if there are multiple development projects), it is necessary to submit a merge application in GitLab for the project manager to merge into Master.

feat-xxx
  • Function branch is a temporary branch, and will be deleted after merging. It’s for the purpose of developing a specific function, which is separated from the master branch. When the development is complete, merge into the Develop branch.
  • Functionality branch names can be named in the form FEAT-XXX.
Bug branch
  • After the project is tested and officially released, bugs will inevitably occur. This is where you need to create a branch and fix the bug.

  • Bug occurrence environment is different, can define different bug branch.

    • Test environment: create a new branch from Develop for Fix-XXX;
    • Formal environment: create a new branch from master with hotfix-xxx;

GitLab branch authority management

Permission types

Gitlib has five identity permissions, which are:

  • The Owner of the project, which has all the permissions to operate
  • The Master project manager can do anything except change or delete the project meta-information
  • Developer, a person who does some development work on a project and has no permission to the protected content
  • Reporter project reporters, who only have read access to projects, can create code snippets
  • Visitors to the Guest project can only submit questions and comments

Branch management standard

Naming conventions

The name of the branch Branch name Function is introduced
The main branch master Formal environment release
Development branch develop Test and development environment release
Function branch feat-xxx Use the Zen number (or use pinyin abbreviations if there are too many).
Repair branch hotfix-xxx Bug number for using Zen Tao, or increase based on current Tag version number
Repair branch fix-xxx Bug work order number for using Zen Tao

Submission specification

Each time Git commits code, it must write a Commit message, otherwise it is not allowed to Commit. In general, however, the Commit message should be clear and clear about the purpose of the commit. The submission specification is set to: “type:subject”

type

The category used to indicate the Commit, only the following seven identifiers are allowed.

  • FEAT: New Feature
  • Fix a bug
  • Style: Format (changes that do not affect code execution)
  • Refactor: Refactoring (that is, not new features, not code changes to fix bugs)
  • Test: Add a test
subject

Subject is a short description of the Commit type, no more than 50 characters long.

Other notes: no period at the end (.)

advantages
  • It’s readable and clear, and you don’t have to look too far into the code to see what the current Commit does.
  • Prepare for Code Reviewing
  • Easy to track project history
  • Make other developers want to be grateful when running Git Blame
  • Improve the overall quality of the project, improve personal engineering quality

Submit branch specification

  • Direct submission of code to the main branch is prohibited, and online editing and modification of the code warehouse is allowed. Except for special circumstances (such as version number change, CI change);
  • Do not submit testable code to any main branch source directory (SRC). Test code can only exist in the test directory.
  • Do not allow any work branch to commit code across the master branch. The work branch can only merge into the master branch with the same origin as the work branch.
  • It is forbidden to modify the main branch version number during the development process.
  • Unused import statements and formatting code must be removed before the code is committed to the main branch.
  • Comments must be made for each submission, and code comments must be brief and readable. Accurate description is easily detectable;
  • Each merge request must be noted with a brief description of the function points contained in the merge request. Accurate descriptions are easily detectable.

Development process management

Iterative development process specification

  1. The general group makes the next iteration version launch plan every Thursday and determines the version number of the main branch of iteration development and notifies each center (group);
  2. Responsible persons of each center (group) will claim and confirm the task (as of Friday), divide the task and distribute it to developers, and the development will be developed on the new version branch;
  3. Each center (group) shall complete the basic tasks before Thursday and submit them to the main branch of the iteration version for integration and verification by the test group;
  4. The test group packages the test in the integration test branch, and the bug is submitted to Zen Tao management. The relevant responsible person will claim and fix the bug in time, and notify the test group of regression test at the same time.
  5. The person on duty online shall determine the final project version and file it for output before the end of work every Thursday;
  6. The responsible person of each center (group) submits the final Database Change Script and Environment Change Script notification to the person on duty online;
  7. The responsible person of each center (group) submits “Program Change Instructions” and “On-line Verification Function List” to the test group;
  8. The online duty person is responsible for the production environment WAR package release and database changes;
  9. The test team verifies the release correctness of the production system according to “On-line Verification Function List”;
  10. The test team verifies that there is no error and issues the on-line change notice according to the Program Change Instructions. The test does not roll back the release procedure and changes to the database and environment by notifying the on-duty person online;
  11. The general group determines the delayed release plan;
  12. The process of delaying on-line operation shall be implemented according to Article 5 to Article 10 of this Chapter;
  13. It is prohibited to distribute the program or change database operations at any other time without approval

Online Bug fixing process

  1. Create a hotfix-xxx branch using the master branch as the source;
  2. Fix the integration environment bug in hotfix-xxx’s fix branch and submit the merge request to the online main branch;
  3. The responsible person of the center (group) is responsible for code review and approving or rejecting the merger request;
  4. The test team carries out patch repair verification in the integrated test environment according to the latest code;
  5. After verification, send the merge request to the main branch of integrated iterative development at the same time as cherry-pick;
  6. The release process shall refer to [Article 5 to Article 10 of Iterative Development Process Specification];

Test the Bug fix process

  1. Create a fix branch for Fix-XXX from the main integration test branch.
  2. Fix the integration environment Bug in the fix branch of Fix-XXX and submit the merge request to the integration test main branch;
  3. The responsible person of the center (group) is responsible for code review and approving or rejecting the merger request;
  4. The test team carries out patch repair verification in the integrated test environment according to the latest code;
  5. After verification, send the merge request cherry-pick to the main branch of iterative development;
  6. The release process shall refer to [Article 5 to Article 10 of Iterative Development Process Specification];