Our GIT workflow

An overview of

Dev merged into Master trigger CI, pre-release

The next iteration function, that is, the function that is not online this time and developed in advance, should use feature and pay attention to merge with the following command

git merge --no-ffCopy the code

Fix online bugs with hotfix, merge back to prod and dev branch

details

Based on the current situation and our team’s habits, the possible Git branches are agreed as follows:

1. Prod is used for production deployment and requires tag
2. Master for CI, designed to provide a stable test environment, incorporating PROD
3. Dev merges functionality development into master for this iteration, giving developers access
4. Feature -${feature-$} feature-${feature-$}
5. Hotfix -${tag}-${index} hotfix-${tag}-${index} hotfix-${tag}-${index

The workflow is detailed below:

1. Let’s say this Week’s launch features are confirmed on Monday, and developers have their work cut out for them
2. All developers develop on Dev, using the mock interface on the front end and testing the interface locally on the back end
3. After the back-end staff develops all interfaces of a complete function, the code is merged into the master, the CI is pushed to trigger, and the front-end staff is informed that the real interface can be connected
4. Relevant front-end personnel debug the real interface, and after completion, merge it into master, push to trigger CI, and notify relevant back-end personnel for mutual verification
5. If all goes well and everything goes according to plan, on Friday the relevant staff will merge the master branch into PROD and tag it for easy rollback, after which it can be deployed to production
6. Special case 1: On Wednesday, a developer received a new requirement for the next iteration. Due to the high efficiency of relevant developers, they have finished the development of this week’s functions, so they decide to advance the development. Therefore, relevant developers will checkout a branch of feature-xxx based on dev branch, which will not affect this release. The dev branch is merged in the next iteration and then deleted
7. Special Case II: Hotfix -${tag}-1 hotfix-${tag}-2 hotfix-${tag}-2 hotfix-${tag}-1 hotfix-${tag}-2 Then, the relevant personnel modified and verified the two branches of Prod checkout, merged them into the dev and PROd branches, and then asked the relevant personnel to tag and release the production. After the production verification was correct, the branch was deleted.

explain

The above process and pictures were referenced to the classic article A -successful- Git-Shoot -model, bearing some modifications. Most of the Git Workflow articles, ideas, and content on the web are derived from Git Workflow, especially the images.

There are two things that are inconsistent with our best practices:

1. Dev performs the nightly build. This is also the case before, but in the interface debugging phase, the backend pushes the code and triggers the CI rebuild, causing the interface to become unavailable and all the front ends to block. During the validation of the development environment by the backend or tester, the front end pushes the code, making the Web application unavailable and blocking all validation. This greatly affected the development/testing experience to the point where it affected the mood, so the CI was removed for dev and only for master
2. The naming of release is misleading. In this article, release is actually a pre-release branch, which is used for verification before going online, but our members misunderstood it as a release branch, which is exclusively used for going online and releasing. In order to resolve the differences, according to the current size of the team, we decided to use master as the stable version, as the verification branch before going live, and PROD as the real go live branch, with a tag before going live

The label

The tag follows the following conventions

V Version number (Major.minor.patch)

Title: Project name – Date