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 from
GitlabIn order to make the front-end team develop dailyeverything in good order and well arranged，Efficient 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.
First of all, branch management is branch management
gitThe basis of workflow, good branch design helps to standardize the development process
CI/CDThe basis of.
gitWorkflow, generally divided into
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 on
|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|
masterBranching is necessary. and
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 as
Issue / issue numberFor example
issue/1, but at
issueTo ensure the traceability of the development work.
Protected BranchesWe can prevent developers from mistaking the code
pushTo some branches. For ordinary developers, we only
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 the
TAPDOn the record. In order to let
GitlabThe code base can be associated with iterative daily transactions, so I decided to use the
Gitlab 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.
Milestones canDisassemble into n issues, new
issueWhen you canAssociated milestones。 For example, there are five requirements in this round of iteration, so we can create five new requirements
issue。 Within the agreed time frame, if a milestone is associated with all
ClosedIf it is dropped, it means that the goal has been achieved successfully.
labelTo identify and classify
issueI think it’s a very good feature. Here are a few
label, to identify
issueOfclassificationandDegree of urgency。
All development work should be approved
issueRecords, including but not limited todemand，defect，Development self test，User experienceAnd so on.
Demand & defect
There are probably two kinds of situations here. One is
TAPDDocumented 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…).
TAPDRecord requirements and defects, create
issueA 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 present
issueAnd 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 required
issueIt’s better to go up
Tapdrecord. I make such a rule, in fact, is to borrow
GitlabFind 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 the
issueRecord the problem and create the appropriate branch modification code.
As I said earlier, my principle is
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.
Feature / 1, a feature branch, corresponding to issue 1
Of course, the normal requirements come from the demand proponents such as product managers. Since it is illustrated by examples, here I am in the
TAPDWrite a requirement on the simulation.
Gitlab issue, link to
TAPDRelated requirements in.
Create branch & Function Development
be based on
featureBranch 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 warehouse
developBranch to create a branch based on.
git checkout -b feature/1 origin/develop
PS: I use it here
feature/1As a branch name, it’s actually here
1It’s for use
issueNo, it doesn’t work
feature/login_verifyThat’s because I think it’s
issueIt is easier to find the corresponding
issue, easier to trace code.
Then we started to develop new features
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 it
git commit。 For details, please click the in-depth practice of front-end automation deployment for in-depth understanding.
fix #1For closing
git push origin HEADIs pushed to the branch with the same name in the remote warehouse.
Create merge request
Merge RequestTo request the integration of the features developed by ourselves
MaintainerneedReview codeAfter confirmationAgree to merge。 Then this part of the code is in the remote
GitThe warehouse has been put into storage, and other developers will pull it
developYou can see the branches.
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 pass
Before testing, generally speaking, it is still necessary to update
package.jsonThe version number of the
MaintainerOr 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 latest
developBranch code in the development environment run through the function to ensure that the version self-test passed.
When testing, the
Merge Request, will
developBranch code merging
releaseBranch, which is automatically triggered
Gitlab CI/CD, automatically build and publish totesting environment。
After the version is submitted for testing, each responsible person shall
TAPDChange 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 cycle
bugWill be recorded in the agile development collaboration platform
TAPDGo ahead. Repair test environment
bugThe steps are similar to the development requirements
Create issue on gitlab
Create an issue and attach a defect link on the tapd for traceability
Create branches & fix defects
be based on
developBranch create branch:
//Three is the issue git checkout -b bug/3 origin/develop
Then change the code
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
Launch merge request
Merge Request, request to merge the code introduced by repairing the defect itself
MaintainerneedReview code, agree to this
Waiting for regression test
bugIt will be next time
CI/CDAfter that, the regression test process is entered.
High level test environment bug
If it’s a high-level one
bugFor example, if the operation of the system is affected and the tester cannot test normally, the
bugBranch, merge after modification
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 test
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。
releaseThe branches are similar,
masterBranch Auto trigger
Gitlab CI/CD, automatically build and publish toproduction environment 。
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, create
be based on
git checkout -b revert/4 origin/master
Suppose the current version is
1.1.0We want to go back to the previous version
1.0.3。 So we need to check it out first
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 fix:1.0.2 diff --git a/README.md b/README.md index ac831d0..2ee623b 100644 --- a/README.md +++ b/README.md @@ -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 getting
commit id, whose value is
And then, according to
resetOperation, and then push to the remote branch with the same name.
git reset --hard 90c9170a499c2c5f8f8cf4e97fc49a91d714be50 git push origin HEAD
Generally speaking, there is no problem with this wave of operations, which can solve the normal rollback problem.
masterThe branch is a protected branch, which cannot be set
push。 If you don’t want to pass
mergeSo it can only be set temporarily
pushPermission, and then by
MaintainerPerform 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 remember
masterSet to not allowed
Q: Why not
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 movement
HEADPointer. The submitted record will be discarded. If you do not handle it carelessly, don’t panic. You can still query it
git resetThere is also a hidden problem after the old one
mergeDuring operation, the
git resetThe rolled back code is reintroduced. So how to solve these problems?
Don’t panic. You have to take it out at this time
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 it
mergeThe 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 requirements
2Item, which is found after online
1A 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.
First of all, let’s look at the log to find the two requirements
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 it
git 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 can
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 online
bugAnd the test engineers are there
TAPDDefect records were submitted. So repair online
bugWhat are the steps?
issueThe title can be downloaded from
copyCome here, and the description is posted
BugSingle link is enough.
be based on
masterBranch create branch
git checkout -b hotfix/5 origin/master
- Code, fix this bug
bugAfter that, submit the branch code to the branch with the same name in the remote warehouse
git push origin HEAD
- And then launch
cherry pickMerge into
developBranch, and in
masterBranch with new version
tag(assuming the current largest
1.0.0, so the new version
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 version
bug。 For old online versions
bugThe repair steps are similar to the previous section.
issueDescribe the problem clearly
Suppose the current version is
0.9.0There is a version
bug, should be based on
git checkout -b fix/6 0.9.0
After the defect has been repaired, a new one shall be marked
tag 0.9.1And push it to the remote.
git tag 0.9.1 git push origin tag 0.9.1
- If this
bugIt also exists in the latest
git push origin HEADSubmit the
fixBranch code to the remote warehouse branch with the same name, and then launch
cherry pickMerge into
masterAt this time, it is very likely that there will be a conflict and the conflict needs to be resolved.
cherry pickBefore, I always thought that only
git mergeYou can merge the code, or encounter the problem of merging unwanted code several times. Yes
cherry pick, we can merge the single submission records and solve the problem
git mergeWhen merging too much unwanted content, trouble in solving
bugIt’s especially useful.
After this period of use, I found that
git mergeWhen merging branches, the
GraphThe 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 learned
git rebaseChanging base, hahaha. Because of the right
rebaseI don’t know much about it, and I dare not use it easily at present
rebaseThere 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
- Generally speaking, self initiated
Merge RequestIt has to be done by other colleagues
ReviewAnd agree to merge, which is more conducive to discovering code problems.
- by the way,
TAPDWe also support
GitlabCollaborative. See the source code Association guidelines for details.
Practice has proved that this set of
GitAt 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 team
GitlabPractice, there must be many shortcomings, if there are mistakes, please correct, welcome to exchange.