During the epidemic, I felt a lot of laziness, and gradually began to consciously brace myself up and return to the normal rhythm. Recently, the team code base was transferred from Gerrit to Gitlab. In order to keep the front-end team’s daily development work orderly and efficient, I also consulted and learned a lot of information. Referring to the mainstream Git workflow in the industry and combining with the business characteristics of the company, I have also sorted out a Git workflow suitable for my team and shared it here.

Branch management

Branch management is the foundation of git workflow. Good branch design helps standardize the development process and is also the foundation of CI/CD.

Branching strategy

Git workflow is divided into develop, Release, master, hotfix/ XXX, feature/ XXX, etc. Each branch performs its own duties throughout the entire development, testing, and deployment process. I have also made some customizations based on the main branching strategy, which are summarized in a table below:

Branch name Branch location describe Access control
develop Development branch Instead of pushing code in the Develop branch, create a new feature/ XXX for requirements development. After iterative functionality is developed, code is merged into the Develop branch. Develper can not directly push, can initiate merge request
feature/xxx Feature branch For each requirement, create a feature branch, such as feature/user_login, to develop user login functionality. Develper can be pushed directly
release To measure branch Merge the Develop branch into the Release branch. Ps: This branch should be configured to trigger CI/CD and deployed to the test environment. Maintainer Enables a merge request
bug/xxx Defect branch Bugs found after testing should be based ondevelopBranch to createbug/xxxThe branch fixes defects and should be merged into the Develop branch to wait for regression testing.
master Release branch The master should be in a releasable state for official releases. Ps: This branch should be configured to trigger CI/CD and deployed to the production environment. Maintainer Enables a merge request
hotfix/xxx Thermal repair branch Deal with bugs in the latest version online Develper can be pushed directly
fix/xxx Older versions fix branches Deal with old bugs on the line Develper can be pushed directly

In general, develop, Release, and Master branches are required. However, feature/ XXX, bug/ XXX, hotfix/ XXX, fix/ XXX and other branches are purely semantic branch names. If you want to be simple and rough, these branches can be named issue/issue number without classification, such as issue/1. However, state specific issues and to-do items in the issue to make sure the development is traceable.

Protect the branch

With Protected Branches, we can prevent developers from mistakenly pushing code into Branches. For ordinary developers, we only give merge permission to the Develop branch.

Please go to the actual combat case section below for specific operation cases.

Issue-driven work

The agile development collaboration platform adopted by our team is Tencent’s TAPD. Daily iteration requirements and defects will be recorded on TAPD. In order to keep the Gitlab code base relevant to the iterative routine, I decided to use Gitlab Issues as a record to trace back issues.

milestone

Milestones can be thought of as a phased goal, such as an iteration plan. Milestones can set time horizons that constrain and remind developers.

Milestones can be disassembled into N issues. When creating an issue, milestones can be associated. For example, if there are 5 requirements in this iteration, 5 new issues can be created. If all the issues associated with a milestone are Closed within the agreed time frame, the goal is successfully achieved.

The label

Gitlab provides labels to identify and classify issues, which I think is a very good function. I have listed several labels to identify the classification and urgency of an issue.

Issue classification

All development work should be documented through issues, including but not limited to requirements, defects, develop-tested, user experience, etc.

Requirements & Defects

There are two types of requirements and defects documented by TAPD, and simple requirements or defects communicated orally to the product or testers (this can happen in small companies…). .

For TAPD record requirements and defects, create an issue with a link for easy reference (already mentioned above).

As for the needs and defects of oral communication, I have made a rule requiring the proposer to create an issue on Gitlab and simply describe the needs or defects, otherwise I will not accept the development work of oral communication (in order to avoid disputes after the event).

Ps: Actually, it is better to record Tapd than to request product or test issue. I set such a rule, in fact, is to find a word by Gitlab, put an end to oral needs or defects, haha.

Development test

If a bug or problem is discovered by the developer himself, record the problem through issue and create a branch to change the code.

Practical cases

As I said earlier, my principle is that issue drives development work.

Here are a few examples to briefly illustrate the basic development process. The whole process in small companies is relatively simple, without complex integration test, multiple rounds of acceptance test, gray scale test, etc. I didn’t even do the unit tests. .

Unit testing is necessary for common libraries and common components, so set a flag here and make sure to add unit testing later.

The requirements development

Feature /1, a feature branch corresponding to Issue 1

Create demand

Of course, normal requirements come from product managers and other requirements providers. Since it is illustrated by examples, HERE I simulate writing a requirement on TAPD myself.

Create issue

Create a Gitlab issue that links to relevant requirements in TAPD.

Branch creation & feature development

Create a feature branch based on the Develop branch for feature development (make sure your local Git repository is currently in the Develop branch and synchronized with the remote Develop branch).

git checkout -b feature/1
Copy the code

Or create branches directly from the Develop branch of the remote repository.

git checkout -b feature/1 origin/develop
Copy the code

Ps: HERE I use feature/1 as the branch name. Actually, here I use the issue number instead of the name such as feature/login_verify, because I think using issue number can make it easier to find the corresponding issue and track the code.

Then we started developing new features……

commit & push

Once the functionality is developed, we need to commit the code and synchronize it to the remote repository.

PS D: projects gitlab project_xxx> git add. PS D: projects gitlab project_xxx> git cz [email protected], [email protected]? Select thetype of change that you're committing: feat: A new feature ? What is the scope of this change (e.g. component or file name): (press enter to skip) ? Write a short, imperative tense Description of the change (Max 94 chars): Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? Yes ? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself: - ? Add issue references (e.g. "fix #123", "re #123".) : fix #1 git push origin HEADCopy the code

Git CZ uses commitizen instead of git commit. For more details, please click the In-depth Practice of Front-end Automation Deployment.

Fix #1 is used to close Issue 1.

Git push origin HEAD represents pushing to a branch of the same name in a remote repository.

Create the Merge Request

A developer initiates a Merge Request to Merge their own features into the Develop branch.

Maintainer then needs to Review the code to confirm the Merge. The code is then stored in a remote Git repository, where other developers can pull the Develop branch and see it.

Version was measured

Issue /2: processes update logs and version numbers, corresponding to Issue 2

The pace of development varies from team to team. Some teams will continue to integrate the release and test every day, while others will do it every other day. We won’t discuss this in depth……

So what do we do when we’re ready to test?

As we learned in the previous section, feature requirements are merged into the Develop branch through the feature/ XXX branch.

In general, version numbers of Changelog. md and package.json should be updated before testing. This can be done by Maintainer or another student who is in control of the project.

Run NPM version Major/Minor /patch -m ‘Something done’. For details, see The in-depth Practice of Automatic front-end deployment.

git checkout -b issue/2 origin/develop
npm version minor -m 'Iteration 1 First lift test'Git push origin HEAD and merge the Merge Request into the Develop branchCopy the code

At this point, you should run the latest Develop branch code through the development environment to make sure the version passes the test.

Maintainer sends a Merge Request to combine the Develop branch code into the Release branch. Gitlab CI/CD is automatically created and released to the test environment.

After release test, each responsible person shall change the status of relevant requirements and defects to ** “under test” ** in TAPD.

Fix test environment bugs

Bug /3, a bug branch corresponding to Issue 3

This refers to system bugs in the test environment discovered by the test engineer during the iteration cycle, which are recorded on the Agile Development collaboration platform TAPD. The steps for fixing bugs in the test environment are similar to those for development requirements. Here are the steps:

  1. Create an issue on Gitlab

    Create an issue with a defect link on TAPD for easy traceability

  2. Create branches & fix defects

    Create branch based on develop branch:

    Git checkout -b bug/3 origin/developCopy the code

    Then change the code……

  3. commit & push

    PS D: projects\gitlab\project_xxx> git cz [email protected], [email protected]? Select thetype of change that you're committing: fix: A bug fix ? What is the scope of this change (e.g. component or file name): (press enter to skip) ? Write a short, imperative tense Description of the change (Max 95 CHars): Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? Yes ? If issues are closed, the commit requires a body. Please enter a longer description of the commit itself: - ? Add issue references (e.g. "fix #123", "re #123".) : fix #3 git push origin HEADCopy the code

  4. Initiate the Merge Request

    A developer issues a Merge Request to Merge the code introduced by the bug they fixed into the Develop branch.

    Maintainer then needs to Review the code to approve the Merge Request.

  5. Waiting for regression tests

    The bug will enter the regression testing process after the next CI/CD.

  6. High level test environment Bug

    If it is a high level bug, such as one that is affecting the system and causing testers to fail to test properly, you should create a bug branch based on the Release branch, merge the release branch, and then launch cherry Pick to merge the Develop branch.

Release to production

After several rounds of continuous integration and regression testing, an iteration was slowly stabilizing and an exciting time to go live was approaching. All we need to do is merge the release branch that passed the test into the Master branch.

This step is relatively simple, but pay special attention to permission control (preventing production environment accidents). For details on permission control, see section 1 branch Management.

Similar to the Release branch, the Master branch automatically triggers the Gitlab CI/CD, which is automatically built and published to production.

Line rollback

Revert /4, a rollback branch corresponding to Issue 4

The code was upgraded online, but an error was reported and the system did not work properly. If the fault cannot be rectified in time, roll back the version first.

First talk about the inertial thinking, my version of the way back.

First, create an issue to record:

Create the revert/4 branch based on the Master branch

git checkout -b revert/4 origin/master
Copy the code

Let’s say the current version is 1.1.0 and we want to go back to the previous version 1.0.3. We need to check out the 1.0.3 version first.

PS D: \ tusi \ projects \ gitlab \ projectname > git show 1.0.3 commit 90 c9170a499c2c5f8f8cf4e97fc49a91d714be50 (tag: 1.0.3, fix/1.0.2_has_bug) Author: tusi <[email protected]> Date: Thu Feb 20 13:29:31 2020 +0800 fix:1.0.2 diff --git a/ readme. md b/README. 2ee623b 100644 -- a/ readme.md +++ b/ readme.md @@-10,6 +10,8 + Feature 2 commit Feature 3 commitCopy the code

Mainly take to version 1.0.3 corresponding commit id, its value is 90 c9170a499c2c5f8f8cf4e97fc49a91d714be50.

Next, we reset based on the COMMIT ID and push to the remote branch with the same name.

git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD
Copy the code

Merge Request to Merge the revert/4 branch into the Master branch.

In general, this wave operation is fine and solves the normal rollback problem.

Temporary accommodation

Since the master branch is a protected branch, it is not pushed. If you do not want to use merge rollback, you must temporarily set the push permission for Maintainer, and Maintainer provides rollback operations.

Git checkout master git pull git show 1.0.3 git reset - 90 c9170a499c2c5f8f8cf4e97 hardfc49a91d714be50
git push origin HEAD
Copy the code

When you’re done, you also need to remember to make the master non-push.

Q: Why Maintainer is not allowed to have master push rights all the time?

A: Mainly in order to prevent production environment accidents, it is safer to give temporary authority!

Git reset –hard

Git reset –hard Git reflog — reset — reset — reset — reset — reset — reset — reset There is also an implicit problem with Git reset. If you merge with an old branch, the git reset rollback code will be reintroduced. So how to solve these problems?

Don’t panic, you have to pull out Git revert.

What are the advantages of Git Revert?

Git Revert is A rollback with A new COMMIT. The HEAD pointer moves forward so that records are not lost. In addition, Git Revert does not cause merge older branches to mistakenly introduce rollback code. Most importantly, Git Revert does a better job of controlling the details of rollback, and it addresses some of the rollback needs.

For example, in this iteration, the team completed two requirements and found that one of them had a fatal defect. The code related to this requirement needs to be rolled back while the code of the other requirement needs to be preserved.

First let’s look in the log to find the commitiDs for these two requirements

PS D:\tusi\projects\test\git_test> git log --oneline 86252da (HEAD -> master, origin/master, E3cef4e (Origin /release, release) Merge branch 'develop' into 'release' f247f38 (Origin /develop, Develop) demand 2 89502C2 demand 1Copy the code

We use Git Revert to roll back the code associated with requirement 1

git revert -n 89502c2
Copy the code

You might want to resolve a conflict, and then you can push it to the remote master branch.

Git add. Git commit -m 'Rollback requirement 1 related code and resolve conflicts' git push origin masterCopy the code

Feel or dish dish, if the big guys have a more elegant solution, please guide!

Fix online bug

Hotfix /5, an online hotfix branch corresponding to Issue 5

For example, there was a bug that the system could not log in online, and the test engineer also submitted the defect record in TAPD. So what are the steps to fix a bug on the line?

  1. Create an issue. The title can be copied from the Bug list in TAPD, and the description can be linked to the Bug list.

  2. Create hotfix/5 based on master.

    git checkout -b hotfix/5 origin/master
Copy the code

  3. Masturbation code, fix this bug……

  4. After fixing this bug, commit the branch code to the remote repository branch with the same name

    git push origin HEAD
Copy the code

  5. Then cherry pick the master and Develop branches and add the new version tag to the Master branch (assuming the current largest tag is 1.0.0, the new version tag should be 1.0.1).

Fix old bugs online

Fix /6, an online fix branch corresponding to Issue 6

Some project products may have multiple online versions running at the same time, and it is inevitable to fix bugs in older versions. For the bugs that appear in the old version online, the repair steps are similar to the previous section.

  1. Create an issue that describes the problem clearly

  2. If the current version is 1.0.0 and there is a bug in 0.9.0, create a fix branch based on Tag 0.9.0.

    Git checkout -b fix/6Copy the code

  3. Once the defect is fixed, a new tag 0.9.1 should be tagged and pushed remotely.

    Git tag 0.9.1 Git push originCopy the code

  4. If this bug also exists in the latest master branch, git push origin HEAD is required to commit the fix branch code to the remote repository branch with the same name, and then initiate cherry pick to merge into the master branch.

cherry pick

Before I learned about Cherry Pick, I thought git merge was the only way to merge code, and I had several problems merging unwanted code. With Cherry Pick, you can merge single commit records, which is especially useful for bug resolution when git merges too much unwanted content.

git rebase

After using git merge for a while, I found that the Git log Graph looks a bit cumbersome when merging branches.

PS D:\tusi\projects\gitlab\projectname> git log --pretty --oneline --graph
*   7f513b0 (HEAD -> develop) Merge branch 'issue/55' into 'release'| \ | * 1 c94437 (origin/issue / 55, 55) issue/fix: "bug" XXX1 | * c84edd6 Merge branch'release' of host:project_repository into release
| |\
| |/
|/|
* |   115a26c Merge branch 'develop' into 'release'
|\ \
| * \   60d7de6 Merge branch 'issue/30' into 'develop'| | \ \ | | | * 27 c59e8 (30, origin/issue/issue / 30) fix: "bug" XXX2 | | | * ea17250 Merge branch'release' of host:project_repository into release
| | | |\
| |_|_|/
|/| | |
* | | |   9fd704b Merge branch 'develop' into 'release'
|\ \ \ \
| |/ / /
| * | |   a774d26 Merge branch 'issue/30' into 'develop'| | \ \ \ | | | / /Copy the code

Git rebase = git rebase = git rebase Due to the lack of understanding of Rebase, I dare not easily switch to Rebase at present. After all, there are many hidden pits in Rebase, so use it carefully! Dig a pit here first, behind figured out to fill pit again……

Matters needing attention

  1. Generally, it’s self-initiatedMerge RequestIt has to be someone elseReviewAnd agree to join in, which makes it easier to find code problems.
  2. By the way,TAPDAlso supports andGitlabSynergy. seeSource code association Guide.

conclusion

As it turns out, this Git workflow can cover most of my project development scenarios so far. However, it should be noted that what suits you is the best, and blindly adopting others’ schemes is sometimes not acclimated to the soil.

The above is purely Gitlab practice within the front-end small and micro team. There are bound to be many deficiencies. If there are any mistakes, please correct them.