preface

Here’s the picture:

I believe you often see this git-flow flowchart, but most people will be confused, our project operation is not this way, just have a moment to find out what is suitable for different Git-flow teams, what are the advantages and disadvantages.

Common development scenarios

Developing new features

  1. fromdevelopPull afeatureBranch.
  2. infeatureDo development on the branch.
  3. featureOnce the development is complete, you need to submit tests in two scenarios:
  • A. One is that the function of the task is not complex and there are few test points. After the self-test is sufficient, the task can be directly closed, that is, mergefeatureBranch;
  • B. The other is that the task function is very complex and there are many test points. Don’t finish the task immediately at this point, have QA in the early stagesfeatureTest it on the branch, and then merge it when it’s stablefeatureBranch. Because of the complex function of the task, there are still many problems after the completion of the self-test, too earlydevelop.developIt will be offline for a long time, affecting other releases.
  1. After completing the task willfeatureBranch merge intodevelopDelete the original branch.

Live test environment and live production environment

  1. developThere will be new content waiting to go live. When it goes online, have one readyreleaseBranch, readyreleaseWhen branching, we need to make clear the new content of this launch and list it to QA so that QA can conduct targeted tests.
  2. Pack the corresponding one on the packing machinereleaseBranch, deploy to application server for QA testing, find bugs directly inreleaseBranch based modification.
  3. releaseAfter passing the test, can go online, thenreleaseClose to themasteranddevelopAnd delete thisreleaseBranch.
  4. When deployed online, frommasterMake a package and mark the version, deploy to the pre-delivery, simple regression test on the pre-delivery, release to the online server after no problem, online completion.

Emergency repair

  • For something that needs to be changed immediately and put online as soon as possible, gohotfixBranch.
  • From the latestmasterlahotfixBranches and inhotfixChange on the branch.
  • Pack the corresponding one on the packing machinehotfixBranch, deploy to application server for QA testing, find bugs directly inhotfixChange on the branch.
  • hotfixAfter passing the test, can go online, thenhotfixIncorporated into themasteranddevelopAnd delete thishotfixThe original branch.

It is very important to follow a reasonable and clear Git usage process in team development. Otherwise, everyone commits a jumble of commitments, and the project quickly becomes difficult to coordinate and maintain.

How to manage Git for multi-party projects

Git Flow development process

The main idea is as follows:

Cons: Each development feature branch merges into the Develop branch, resulting in features being developed at the same time that must be live at the same time.

master

[Online branch] – Is an online version branch, which can also be understood as a stable version that can be released at any time. It requires the main programmer to merge the release branch code after each version closure, and developers can not operate at will.

develop

Development Base branch – Contains new content to be released and is the base branch for any new development you do. When you start a new feature branch, it will be the basis for development, thus pulling out the feature branch in preparation for new feature development. In addition, the branch also brings together all the functionality that has been completed and is finally integrated into the Master branch after passing the Release branch test.

release

【 Live branch 】 – This branch is used for testing when the development is finished and is the final release of this version. All bugs during the test phase are fixed in this branch and merged into the Master and Develop branches after the test.

When you’re ready to publish new content on Develop to production, you need to pull the Release branch. The Release branch isolates the subsequent impact of Develop on this launch. When release is pulled out, you don’t have to worry about everything else coming together, just focus on testing and fixing bugs on it.

feature

【 New function development branch 】 – When developing new functions, establish a new feature branch based on the Develop branch for independent development. If you need this feature, just merge the feature branch into the Develop branch and test it next time.

This is designed to avoid unpredictable instability when the feature gets mixed in with a release when it is not yet developed or tested. Of course, multiple feature branches can be opened at the same time to develop different new functions, which can be combined and tested when appropriate.

hotfix

Emergent bug branch – This branch is used to fix emergent bugs on the line. It should be pulled out by the master and merged into the Master and Develop branch to ensure that all bugs are fixed.

For specific operation process, please refer to the following figure:

There are a few things you can see from this flow chart:

  • Scenario 1: Requirement A can be published in the latest release window, requirement B cannot, and then requirement B must be merged into the Develop branch in the next release cycle.
  • Scenario 2: Two functional requirements are tested at the same time. One of them has been tested, and the other one has not passed the test

Our team’s custom Git-flow

Disadvantages: The merge action is repeated, and conflicts need to be resolved twice. (Because the feature code is not pushed to Release from Develop, if there is a conflict in the release branch, there will be a conflict in the release branch. Release is automatically merged into Develop (if any conflicts are resolved) to reduce conflict resolution. The scenarios that need special attention are

Start developing release/1.2.0 features

git checkout -B feature/A master
# After writing a bunch of code
git add .
git commit -m "Feat: Add Shopping Cart feature (#123)"

# programmer A receives Task2, but the release cycle is not release/1.2.0
git checkout -B feature/B master
# After writing a bunch of code
git add .
git commit -m "Feat: Added image Lazy Load feature (#126)"
Copy the code

UAT QA testing phase

  • After passing the functional test, prepare to enter the QA test process
# supervisor added release/v1.2.0 for releaseGit Checkout -b release/v1.2.0 master# handle programmer A's code merge release/1.2.0Git Checkout release/1.2.0 Git merge feature/A --no-ff release/1.2.0Configuration 'release/*' is automatically merged into Develop
Git branch -d feature/A


The code for programmer B is merged into Develop and is outside the scope of this release
git checkout develop
git merge feature/B --no-ff
Copy the code

Note whether the merge branch is used--no-ffThe difference between:

Prepare production environment process

git checkout -B  master
Merge the branch of code that needs to be released this timeGit merge release/v1.2.0 - no - ff# If the CI module writes the script NPM run release, do the following on the master
npm run test Run unit tests in your project
npm run build # Package components
npm version --new-version # Update version number
git add & git commit & git push # Update package.json version number
git tag & git push Type the release number for the master
Next complete the deploy task
Copy the code

Hotfix process

To fix the problem

$git checkout -b hotfix-1.2.1 Master Switched to a new branch"Hotfix - 1.2.1"
$ git commit -a -m "fix: xxxx"
Copy the code

Merge back to release and master for regression testing

$ git checkout master
Switched to branch 'master'$git tag - $git tag - $git tag - $git tag - $git tag - $git tag - $git tag - $git tag - $git tag - $git tag - $git tagCopy the code
$ git checkout release/1.2.0
Switched to branch 'release / 1.2.0'$git merge --no-ff hotfix 1.2.1 merge made by recursive.Copy the code

Inadequate:

  • Scenario 1: The Develop branch incorporates a feature (but later requirements were dropped and the feature branch was not merged into a release branch), so the Develop base needs to be maintained from time to time

Git Basic Operations

Finally, Git basic operations to review.

Initialize the warehouse

Create a new Git repository in the current directory
$ git init

Create a new directory and initialize it as a Git code base
$ git init [project-name]

Download a project and its entire code history
$ git clone[url] Copy codeCopy the code
# quick command
echo "# git-Demo" >> README.md
git init
git add README.md
git commit -m "first commit"

git remote add origin xxx
git push -u origin master
Copy the code

Configure Git

Git’s Settings file is.gitconfig, which can be in the user home directory (global configuration) or in the project directory (project configuration).

$Git config [--global] $Git config [--global] $Git config [--global "[name]" $git config [--global] user.email "[email address]Copy the code

Add delete file

$git add [file1] [file2]... $git add [dir] $git add. $git add. $git add -p $git rm [file1] [file2] $git mv [file-original] [file-copy] copy the code by pressing $git mv [file-original] [file-copy]Copy the code

Submit code

$git commit [file1] [file2] $git commit [file1] [file2] $git commit -v $git commit -v $git commit -v $git commit -- amend-m [message] # amend the last commit, $git commit --amend [file1] [file2]... Copy the codeCopy the code
# Daily commands
git add .
git commit -m "Description of this submission"
git pull
git push
Copy the code

Branch command

$git branch -r $git branch -r $git branch [branch-name] $git checkout -b [branch] Commit $git branch [branch] [commit] $git branch --track [branch] [remote-branch] $git checkout [branch-name] $git checkout - $git branch --set-upstream [branch] [remote-branch] $git merge [branch] $git cherry-pick [commit] $git branch -d [branch-name] # $git push origin --delete [branch-name] $git branch-dr [remote/branch] Replicates codeCopy the code

Tag command

$git tag [tag] $git tag [commit] # Delete local tag $git tag $git show [tag] # $git push [remote] [tag] $git checkout -b [branch] [tagCopy the code

Check the information

$git log -- $git log -- $git log -- $git log -- $git log $git log -s [keyword] # $git log [tag] HEAD --pretty=format:%s # $git log [tag] HEAD --grep feature # --follow [file] $git whatchanged [file] # diff $git log -p [file --pretty --oneline # display all submitted users $git diff $git diff $git diff $git diff $git diff $git diff [first-branch] $git diff [first-branch] $git diff [first-branch] $git diff --shortstat "@{0 day ago}" $git show [commit] # $git show --name-only [commit] $git show [commit]:[filename] # $git reflog copy codeCopy the code

Remote synchronization

$git remote show [remote] $git remote show [remote] $git remote add [shortname] [url] $git pull [remote] [branch] $git push [remote] [branch] $git push [remote] --all copies the codeCopy the code

undo

$git checkout [commit] [file] $git checkout [file $git reset [file] $git reset [commit] # reset the HEAD of the current branch to commit. $git reset --hard [commit] # $git reset --keep [commit] # create a new commit to undo the specified commit $git Revert [commit] # Remove the uncommitted changes temporarily and move on to $git Stash $git Stash pop laterCopy the code

conclusion

There is no best, only the best, and this applies to how the team chooses git-flow.

expand

[# A successful Git shoot model] (nvie.com/posts/a-suc…)