Share technical knowledge of Java,.NET, Javascript, efficiency, software engineering, programming languages, etc.

GitHub TechShare, Just For Fun

Zero, preface,

  1. This document is intended for web projects (backend and front-end) that need to be continuously published. Minor modifications can be made for projects (frameworks, components, apps, etc.) that need to have different versions at the same time.
  2. The workflow based on git branch flow strategy, this strategy has the advantage of the branch is clear, able to handle the development process in many cases, the disadvantage is that branch is more, the development process will often need to merge, and so on based on the strategy on the basis of appropriate simplification, and considering the situation of parallel iteration, comprehensive set the workflow.

This document contains four parts: branch policy, workflow, branch usage specification and code submission specification. Branch policy mainly introduces Git flow, workflow describes how to implement git flow in specific development process, and branch usage specification describes the usage of each branch in detail. The final code submission specification is a key factor in successfully advancing code review.

1. Terminology description

  • Continuous integration /CI: This term is used to refer to code from the Feature branch that is frequently integrated into the Develop branch and automatically built into the test environment by CI, and feature integration into Develop at least once a day.
  • Continuous integration environment: An environment for automatically building, running tests, and deploying test programs based on a particular branch configuration.
  • Pre-release environment: Close to production, not test environment.

First, branch strategy

1. Branch strategy

The primary branching strategy is based on Git Flow, but it can vary depending on the complex and varied project development process.

Git main process flow below, specific use may refer to: www.ruanyifeng.com/blog/2012/0…

2. Long-term branch

  • Master: Used to store releases that are stable at any time in this branch.
  • Develop: Used for daily development, storing the latest development version.

3. Temporary branches

  • Feature: a feature branch is used to develop specific features. Each feature branch is developed iteratively and merged into the Develop branch after development.
  • Hotfix: used to fix bugs, separate from master, merged into the Master, deveop branch after development.
  • Release: We may need to have a pre-release version to test before we release the official version (i.e. before merging into the Master branch).

Second, the work process

Note: The following text in bold is a special case, most of the time do not need to consider, remove from the process, the workflow is not complex.

1. Initial project

  • Create projects on GitLab
  • Create the Develop branch and set it as a Maintainer branch. Users with Maintainer permissions can directly push and merge. Other users submit the code to their own branch and send a Merge Request. Maintainer and team members conduct code reviews to decide whether to accept the merge.
  • Changed the master branch to not allow push by anyone, the branch can only be changed by MR.

2. The beginning of iteration

  • Case 1: Long iteration time and clear division of labor
  • Developers create their own feature branches, and the code is continuously integrated into Develop.
  • Case 2: Short iteration time, unclear division of labor, or multiple people working on the same feature
  • Developers share a feature branch, and code is continuously integrated into Develop.
  • Case 3: Iteration A and iteration B start at the same time, and A is the main iteration
  • The main iteration selects the development mode based on cases 1 and 2, and the code is continuously integrated into Develop
  • The secondary iteration is separated from the Develop sprint-{version}, the feature is developed based on this version, and the code is continuously integrated into the sprint-{version}.
  • Case 4: Major iteration A is started, and iteration B is suddenly started
  • Iteration B is separated from sprint-{version} from master, feature development is based on this version, and code is continuously integrated into sprint-{version}.

Note: Cases 2, 3 and 4 are special cases and should be avoided as far as possible. Especially cases 3 and 4 require continuous integration of code into another version, so another continuous integration environment needs to be configured, which also increases the trouble of code review and branch merger. The development phase described below is based on case 1, or in case 3 or 4, you need to replace the Develop branch with the Sprint branch.

3. Iterative development phase

  • When developers complete feature development or phase development, initiate Develop’s MR.
  • Maintainer and team members review the MR. Rejectors require submitters to resubmit the MR with code modifications, and acceptors are merged into Develop and automatically built into the test environment.
  • After the overall test of the iteration passes, the release stage is entered.

4. Release preparation

  • For projects without a pre-release environment, skip the preparation phase and enter the release phase.
  • For projects with a pre-release environment, create a new Release from Develop as a protected branch (or merge if you already have one, which can be removed once deployment stabilizes).
  • The release branch is built into a pre-release environment for testing, and bugs are modified on that branch if they exist.
  • Once you’ve finished testing the Release branch, you’re in the release phase.

5. Release phase

  • Submit application for release, and merge code after passing o&M review
  • The release branch is merged to develop and Master if a release is present, and develop to master if not.
  • Build with Master and publish to production.
  • Put the version tag on the master to mark the release.

6. Publish rollback information online

  • When a release rollback occurs, the code merged to the master is also rolled back.

7. Fix online bugs

  • Create hotfix branch from master to fix bugs.
  • When you’re done, merge the hotfix into Develop for testing.
  • After passing the test, merge to master for release, and tag with the minor version number.
  • If you currently have a release branch, you also need to merge hotfix into release.
  • Delete the Hotfix branch.

Three, use specifications

1. Temporary branch naming conventions

Temporary branch The prefix note
feature feature- If gitlab contains task issue, it can be named feature-{issueid}-{simple description}
release release- End with version name or version number
hotfix hotfix- If gitlab contains a bug issue, you can name it feature-{issueid}-{simple description}
sprint sprint- End with iteration name or version number

CI pipes can be automated through prefix matching.

The branch prefix is usually connected with -/, but rarely with _, indicating that two words are related. The feature branch is actually a grouping, so it is usually used with -/, which can be used after the prefix.

2. Specification for the use of feature branches

  • Branch granularity: take a function as the unit, try to correspond to a task issue on Gitlab, and create a feature when developing the next function
  • Duration: Delete the feature as short as possible after merging it into Develop
  • Integration frequency: at least once a day, features should be incorporated into Develop frequently for code review, and developers should always get the latest code from Develop;
  • Merge request: MR can be initiated when the feature is completed. However, when a feature takes a long time to develop, MR should also be initiated as early as possible. At this time, WIP prefix can be added to MR to indicate that the current work is being processed and relevant personnel can review it in advance but not merge it

3. Use specification of hotfix branch

  • Differentiating from feature: In addition to urgent bug fixes, hotfix branches should also be created instead of feature when functional adjustments are needed to quickly get online.

4. Sprint branch usage specification

  • Sprint is used in the same way as Develop and is also a protected branch.
  • It is necessary to separate feature branches from sprint for development, and submit MR from feature to Sprint for code review.

5. Release branch usage specification

  • Release is the protective branch.
  • Use the Hotfix branch for bug fixes.

Iv. Code submission specifications

Let’s start with why we have code submission specifications.

  1. Git is currently the most popular repository management system, which can be said to be a necessary skill for developers. It’s very powerful, and when used correctly it can dramatically increase personal effectiveness. If all members of a team are proficient in using Git, they can greatly improve the modularity, readability, and maintainability of the team’s code, thus improving the team’s research and development efficiency.
  2. Two key actions to successfully advance code reviews are to pay attention to the atomicity of the review Commit and to the Commit Message in the review.

1. Code submission atomicity specification

Atomicity of code commits means that a commit contains an indivisible feature, fix, or optimization, and that the commit should be as small as possible. If a single commit is used to complete a feature and the commit is still large, we need to split the feature into sub-features.

Advantages of atomic commit:

  1. It makes the code structure clearer and easier to understand.
  2. When a problem occurs, it is convenient to locate the problem and can be “rolled back” to the problem submission.
  3. With the help of functional switches, developers can push code to Develop/Master as quickly as possible for merging. This is the foundation of continuous integration.

Specification requirements:

  1. A commit contains an indivisible feature, fix, or optimization, and the commit should be as small as possible.

Code review criteria

  1. Code that does not comply with atomic submission can be typed back.
  2. The atomicity of the submission is required step by step. It is not required to be in place once, but it must be improved step by step.

2. Code submission specification

Good submission instructions can improve code readability and can be a great tool for code review. By formulating strict submission specification format to regulate its quality, it is convenient for reviewers to understand the intent and implementation of the code being reviewed, and through testing, they can speed up their understanding of the code and improve their confidence in the code quality, thus greatly improving the efficiency of reviewers. At the same time, strict submission specification format and good specification quality can also encourage developers to improve code quality.

A good format should include the following aspects:

  • The title briefly describes this submission. This section is best kept under 70 characters to ensure complete display on a single line. For example, git log –oneline, which is commonly used on the command line, should be able to display the output completely.
  • A detailed description, including the purpose of the submission, the reason for choosing the method, and a summary description of the implementation details. These are the three areas that most help reviewers read the code.
  • Test condition, which describes what you did to test the commit, including normal condition output, error condition output, and performance, security, and other specific test results. This section can increase the reviewer’s knowledge and confidence in the submitted code.
  • Information related to other tools and systems, such as related task ids, related sprints (also translated as “iterations”) links. This information is essential to providing basic information for the mesh interconnection of tools.

Specification requirements:

  1. Submission instructions must include two parts: title and test status.
  2. The submission description must comply with the format requirements. According to the amount of code to be submitted, the detailed description and related information should be added if necessary.
  3. Basic format requirements (title and test must be included, title must use type(scope) form) :
Title Description: Testing:Copy the code

Submission Description Template:

Watches: watches $type($scope): summary: test: task ID: BREAKING CHANGE: watches: Closes an issue, as in #123Copy the code

The following options are available for type:

  • Feat: New function
  • Fix: Fixes bugs
  • Docs: Changes to documents only
  • Style: Changes in the code format do not affect changes in code execution.
  • Refactor: Refactoring, which is not a new feature or a code change that fixes a bug
  • Perf: Performance optimization
  • Test: Adds a test
  • Build: the building process
  • Chore: Miscellaneous changes that do not modify source code

Scope is used to specify the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project.

Note other important information at the end, such as incompatible changes, bug ids fixed, and so on.