Gitlab practice of front end small and micro teams


During the epidemic, I felt a lot of laziness in the whole person, and I slowly and consciously wanted to cheer up and return to the normal rhythm. Recent team code base fromGerritMoved toGitlabIn order to make the front-end team develop dailyeverything in good order and well arrangedEfficient operation, development historyTraceabilityI have also consulted a lot of learning materials. Reference industry mainstreamGit workflowCombined with the company’s business characteristics, I also sorted out a set ofGit workflow for your teamShare it here.

Branch Management

First of all, branch management is branch managementgitThe basis of workflow, good branch design helps to standardize the development processCI/CDThe basis of.

Branching strategy

Industry mainstreamgitWorkflow, generally divided intodevelop, release, master, hotfix/xxx, feature/xxxAnd so on. Each branch performs its own duties and runs through the wholeDevelopment, testing, deploymenttechnological process. I have also made some customization based on the mainstream branch strategy. Here is a simple summary in a table:

Branch name Branch positioning describe Authority control
develop Development Branch You can’t push code in the development branch. You should create a new feature / xxx for requirements development. After the iterative function development, the code will be merged to the development branch. Develper cannot push directly, but can initiate a merge request
feature/xxx Characteristic branch For each requirement, create a new feature branch, such as feature / user_ Login, which is used to develop the user login function. Develper can push directly
release Proposed branch From the development branch to the release branch. PS: this branch should be configured to trigger CI / CD and deploy to the test environment. Maintainer can initiate merge request
bug/xxx Defect branching The bugs found after testing should be based ondevelopBranch creationbug/xxxAfter the modification, it should be merged into the development branch to wait for regression test.
master Publishing branch The master should be in a state that can be released at any time to release the official version. PS: this branch should be configured to trigger CI / CD and deploy to production environment. Maintainer can initiate merge request
hotfix/xxx Hot repair branch Dealing with bugs in the latest online version Develper can push directly
fix/xxx Old version repair branch Dealing with old versions of bugs Online Develper can push directly

In general,develop, release, masterBranching is necessary. andfeature/xxx, bug/xxx, hotfix/xxx, fix/xxxEquibranching is a kind of semantic branch naming. If we want to be simple and crude, these branches can not be classified and named asIssue / issue numberFor exampleissue/1, but atissueTo ensure the traceability of the development work.

Protection branch

utilizeProtected BranchesWe can prevent developers from mistaking the codepushTo some branches. For ordinary developers, we onlydevelopBranch supplymergejurisdiction.

Gitlab practice of front end small and micro teams

For specific operation cases, please go to the followingPractical casesSection.

Issue driven work

Our team adoptedagile development The collaboration platform is Tencent’s tapd, and the requirements and defects of daily iteration will be in theTAPDOn the record. In order to letGitlabThe code base can be associated with iterative daily transactions, so I decided to use theGitlab issuesTo make a record to facilitate the tracing of problems.


MilestoneIt can be thought of as aPhased goalsFor example, an iteration plan. Milestones can set a time frame to constrain and alert developers.

Gitlab practice of front end small and micro teams

Milestones canDisassemble into n issues, newissueWhen you canAssociated milestones。 For example, there are five requirements in this round of iteration, so we can create five new requirementsissue。 Within the agreed time frame, if a milestone is associated with allissueallClosedIf it is dropped, it means that the goal has been achieved successfully.

Gitlab practice of front end small and micro teams


GitlabProvidedlabelTo identify and classifyissueI think it’s a very good feature. Here are a fewlabel, to identifyissueOfclassificationandDegree of urgency

Gitlab practice of front end small and micro teams

Issue classification

All development work should be approvedissueRecords, including but not limited todemanddefectDevelopment self testUser experienceAnd so on.

Demand & defect

There are probably two kinds of situations here. One isTAPDDocumented requirements and defects, the other is a simple requirement or defect communicated orally with the product or tester (this can happen in a small company…).

aboutTAPDRecord requirements and defects, createissueA link should be attached for easy reference (as mentioned above).

For the needs and defects of oral communication, I have made a rule that the proposer himself should be presentGitlabCreated onissueAnd simply describe the requirements or defects, otherwise I will not take over the development work of oral communication (also to avoid wrangling afterwards).

psIn fact, the product or test is requiredissueIt’s better to go upTapdrecord. I make such a rule, in fact, is to borrowGitlabFind an excuse,Eliminate oral needs or defectsHa ha.

Development self test

If the developer has found a system defect or problem himself, he should pass theissueRecord the problem and create the appropriate branch modification code.

Gitlab practice of front end small and micro teams

Practical cases

As I said earlier, my principle isissueDrive development.

Here are a few examples to illustrate the basic development process. The whole process of small company is relatively simple, without complex integration test, multi round acceptance test, gray level test, etc. I didn’t even do the unit test.

In fact, it is necessary to do unit testing for public libraries and components. A flag is set here, and the unit test must be supplemented later.

Demand development

Feature / 1, a feature branch, corresponding to issue 1

Create requirements

Of course, the normal requirements come from the demand proponents such as product managers. Since it is illustrated by examples, here I am in theTAPDWrite a requirement on the simulation.

Gitlab practice of front end small and micro teams

Create issue

establishGitlab issue, link toTAPDRelated requirements in.

Gitlab practice of front end small and micro teams

Gitlab practice of front end small and micro teams

Create branch & Function Development

be based ondevelopBranch creationfeatureBranch for functional development (to ensure that the local git repository is currently in the development branch and synchronized with the development branch of the remote warehouse).

git checkout -b feature/1

Or directly from remote warehousedevelopBranch to create a branch based on.

git checkout -b feature/1 origin/develop

PS: I use it herefeature/1As a branch name, it’s actually here1It’s for useissueNo, it doesn’t workfeature/login_verifyThat’s because I think it’sissueIt is easier to find the correspondingissue, easier to trace code.

Then we started to develop new features

Gitlab practice of front end small and micro teams

commit & push

After the function development, we need to submit 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 the type 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):
 (9) Login verification function
? 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 HEAD

git czIt’s using itcommitizenTo replacegit commit。 For details, please click the in-depth practice of front-end automation deployment for in-depth understanding.

fix #1For closingissue 1

git push origin HEADIs pushed to the branch with the same name in the remote warehouse.

Create merge request

Developer initiatedMerge RequestTo request the integration of the features developed by ourselvesdevelopBranch.

Gitlab practice of front end small and micro teams

nextMaintainerneedReview codeAfter confirmationAgree to merge。 Then this part of the code is in the remoteGitThe warehouse has been put into storage, and other developers will pull itdevelopYou can see the branches.

Version testing

Issue / 2, which processes the update log and version number, corresponds to issue 2

Each team has a different pace of development, and some teams do it dailyContinuous integrationSome of them may be released once every two days, so we won’t discuss it in depth

So what should we do when we are ready to propose a test?

From the previous section, we already know that the functional requirements within the iteration will passfeature/xxxBranching intodevelopBranch.

Before testing, generally speaking, it is still necessary to updateCHANGELOG.mdandpackage.jsonThe version number of theMaintainerOr other students in charge of the matter.

It is mainly to execute NPM version major / minor / Patch – M ‘something done’. For specific operations, please refer to the article “deep practice of front-end automatic deployment”.

git checkout -b issue/2 origin/develop
NPM version minor - M 'iteration 1 first test'
git push origin HEAD
Then, merge request is initiated to join the development branch

At this time, the latestdevelopBranch code in the development environment run through the function to ensure that the version self-test passed.

When testing, theMaintainerlaunchMerge Request, willdevelopBranch code mergingreleaseBranch, which is automatically triggeredGitlab CI/CD, automatically build and publish totesting environment

After the version is submitted for testing, each responsible person shallTAPDChange the status of related requirements and defects to“Under test”

Fix test environment bugs

Bug / 3, a bug branch, corresponding to issue 3

This is about the system in the test environment discovered by the test engineer during the iteration cyclebug, thesebugWill be recorded in the agile development collaboration platformTAPDGo ahead. Repair test environmentbugThe steps are similar to the development requirements

  1. Create issue on gitlab

    Create an issue and attach a defect link on the tapd for traceability

  2. Create branches & fix defects

    be based ondevelopBranch create branch:

    //Three is the issue
    git checkout -b bug/3 origin/develop

    Then change the code

  3. commit & push

    PS D:\projects\gitlab\project_xxx> git cz
    [email protected], [email protected]
    ? Select the type 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):
     (11) Fix a test environment bug
    ? 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 HEAD
  4. Launch merge request

    Developer initiatedMerge Request, request to merge the code introduced by repairing the defect itselfdevelopBranch.

    thenMaintainerneedReview code, agree to thisMerge Request

  5. Waiting for regression test

    ThebugIt will be next timeCI/CDAfter that, the regression test process is entered.

  6. High level test environment bug

    If it’s a high-level onebugFor example, if the operation of the system is affected and the tester cannot test normally, thereleaseBranch BasedbugBranch, merge after modificationreleaseBranch, resendcherry pickIntegrationdevelopBranch.

Release to production environment

After several rounds of continuous integration and regression testing, an iterative version gradually tends to be stable, which also ushers in exciting online time. All we have to do is to pass the testreleaseBranching inmasterBranch.

Gitlab practice of front end small and micro teams

This step is relatively simple, but pay special attention to permission control(Prevention of production environment accidents)For specific permission control, please refer to Chapter 1Branch Management

AndreleaseThe branches are similar,masterBranch Auto triggerGitlab CI/CD, automatically build and publish toproduction environment

Online rollback

Reverse / 4, a rollback branch, corresponding to issue 4

Code upgrade to online, but found an error, the system can not run normally. At this time, if the problem can not be checked out in time, the version rollback operation can only be performed first.

Let’s talk about it firstInertia thinkingNext, my version of the fallback approach.

First of all, createissueRecord:

Gitlab practice of front end small and micro teams

be based onmasterBranch creationrevert/4branch

git checkout -b revert/4 origin/master

Suppose the current version is1.1.0We want to go back to the previous version1.0.3。 So we need to check it out first1.0.3Version information.

PS D:\tusi\projects\gitlab\projectname> git show 1.0.3
commit 90c9170a499c2c5f8f8cf4e97fc49a91d714be50 (tag: 1.0.3, fix/1.0.2_has_bug)
Author: tusi <[email protected]>
Date:   Thu Feb 20 13:29:31 2020 +0800


diff --git a/ b/
index ac831d0..2ee623b 100644
--- a/
+++ b/
@@ -10,6 +10,8 @@

 Only want to modify the old version of the bug, not the latest master

+Version 1.0.2 still has a version, and then fix it
 Feature 2 submission

 Feature 3 submission

It’s mainly about getting1.0.3Version correspondingcommit id, whose value is90c9170a499c2c5f8f8cf4e97fc49a91d714be50

And then, according tocommit idconductresetOperation, and then push to the remote branch with the same name.

git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD

Then launchMerge Requestholdrevert/4Branching inmasterBranch.

Gitlab practice of front end small and micro teams

Generally speaking, there is no problem with this wave of operations, which can solve the normal rollback problem.

Temporary accommodation

becausemasterThe branch is a protected branch, which cannot be setpush。 If you don’t want to passmergeSo it can only be set temporarilyMaintainerhavepushPermission, and then byMaintainerPerform the rollback operation.

git checkout master
git pull
git show 1.0.3
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50
git push origin HEAD

When you’re done, you need to remembermasterSet to not allowedpush

Q: Why notMaintainerAlways havemasterOfpushjurisdiction?

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

What’s wrong with git reset — hard?

As in the title,git reset --hardThere are problems.git reset --hardBelongs to the overbearing play, direct movementHEADPointer. The submitted record will be discarded. If you do not handle it carelessly, don’t panic. You can still query itgit reflogfindcommitIdRescued; rescued;git resetThere is also a hidden problem after the old onebranchconductmergeDuring operation, thegit resetThe rolled back code is reintroduced. So how to solve these problems?

Gitlab practice of front end small and micro teams

Don’t panic. You have to take it out at this timegit revertYes.

Q: git revertWhat are the advantages of?

A: First of all,git revertThe rollback operation is performed through a new commit. The head pointer moves forward so that records will not be lost,git revertAnd it won’t cause itmergeThe code for rollback was introduced by mistake in the old branch. most important of all,git revertIt is more excellent in the detail control of rollback, which can solve the requirement of partial rollback.

For example, this round of iteration team completed the requirements2Item, which is found after online1A requirement has a fatal defect, and the code related to this requirement needs to be rolled back while the code of another requirement is retained.

Gitlab practice of front end small and micro teams

First of all, let’s look at the log to find the two requirementscommitId

PS D:\tusi\projects\test\git_test> git log --oneline
86252da (head > master, origin / master, origin / head) resolves conflicts
e3cef4e (origin/release, release) Merge branch 'develop' into 'release'
F247f38 (origin / development, development) requirement 2
89502c2 demand 1

We use itgit revertRoll back the code related to requirement 1

git revert -n 89502c2

At this time, you may have to resolve the conflict. After solving the conflict, you canpushTo remotemasterBranch.

git add .
Git commit - M 'roll back the relevant code of requirement 1 and resolve the conflict'
git push origin master

Feel or vegetable, if the big guys have more elegant solutions, ask for guidance!

Fix online bugs

One hot fix on 5

For example, the system fails to log in onlinebugAnd the test engineers are thereTAPDDefect records were submitted. So repair onlinebugWhat are the steps?

  1. establishissueThe title can be downloaded fromTAPDMediumBugDanzhongcopyCome here, and the description is postedBugSingle link is enough.
  2. be based onmasterBranch create branchhotfix/5

    git checkout -b hotfix/5 origin/master
  3. Code, fix this bug
  4. Repair thisbugAfter that, submit the branch code to the branch with the same name in the remote warehouse

    git push origin HEAD
  5. And then launchcherry pickMerge intomasteranddevelopBranch, and inmasterBranch with new versiontag(assuming the current largesttagyes1.0.0, so the new versiontagShould be1.0.1)。

Fix old online bugs

Fix / 6, an online old version repair branch, corresponding to issue 6

Some project products may have multiple online versions running at the same time, so it is inevitable to solve the problem of the old versionbug。 For old online versionsbugThe repair steps are similar to the previous section.

  1. establishissueDescribe the problem clearly
  2. Suppose the current version is1.0.0, and0.9.0There is a versionbug, should be based ontag 0.9.0establishfixBranch.

    git checkout -b fix/6 0.9.0
  3. After the defect has been repaired, a new one shall be markedtag 0.9.1And push it to the remote.

    git tag 0.9.1
    git push origin tag 0.9.1
  4. If thisbugIt also exists in the latestmasterBranchgit push origin HEADSubmit thefixBranch code to the remote warehouse branch with the same name, and then launchcherry pickMerge intomasterAt this time, it is very likely that there will be a conflict and the conflict needs to be resolved.

    Gitlab practice of front end small and micro teams

cherry pick

In understandingcherry pickBefore, I always thought that onlygit mergeYou can merge the code, or encounter the problem of merging unwanted code several times. Yescherry pick, we can merge the single submission records and solve the problemgit mergeWhen merging too much unwanted content, trouble in solvingbugIt’s especially useful.

git rebase

After this period of use, I found thatgit mergeWhen merging branches, thegit logOfGraphThe picture looks a little hard.

PS D:\tusi\projects\gitlab\projectname> git log --pretty --oneline --graph
*   7f513b0 (HEAD -> develop) Merge branch 'issue/55' into 'release'
| * 1c94437 (origin/issue/55, issue/55) 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'
| |\ \
| | * | 27c59e8 (origin/issue/30, 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'
| |\ \ \
| | |/ /

Then I learnedgit rebaseChanging base, hahaha. Because of the rightrebaseI don’t know much about it, and I dare not use it easily at presentrebaseAfter allrebaseThere are still many hidden pits. Be careful when using them! Dig a hole here, and fill in the hole after you understand it

matters needing attention

  1. Generally speaking, self initiatedMerge RequestIt has to be done by other colleaguesReviewAnd agree to merge, which is more conducive to discovering code problems.
  2. by the way,TAPDWe also supportGitlabCollaborative. See the source code Association guidelines for details.


Practice has proved that this set ofGitAt present, workflow can cover most of the scenarios in the development process of my project. However, it should be noted that the best thing is to suit yourself, and sometimes it will be acclimatized to blindly adopt other people’s plans.

The above is purely within the front-end small and micro teamGitlabPractice, there must be many shortcomings, if there are mistakes, please correct, welcome to exchange.

Gitlab practice of front end small and micro teams