Git Pond Flow

I believe you will have a more or less understanding of git workflow

  • Git flow
  • Github flow
  • Gitlab flow

I don’t know. Look at this

Here are a few pain points in using GitFlow:

  1. Waiting — when there are multiple people developing, we need to pay attention to whether the branches such as test and pre-launch are temporarily used by others. If they are temporarily used, we need to wait for others to finish testing after using them.
  2. Conflict post – no time on line like the enemy, to the last Mr That moment just know how much conflict, a wave of operation fierce as tiger, maybe there are bugs. The consolidation of large areas of code is also a big challenge for managers. Reviewing all code takes a lot of time and effort;
  3. No rollback – If it turns out that one of the features doesn’t live for a specific reason, rolling back the version will require drastic changes and many conflicts may have to be reworked. All at once it was another night;
  4. Deployment – Because the branch is not fixed, every time it needs to be deployed to dev or any other environment it needs to be done manually, so every little bit of time is wasted.

In order to solve the above pain points, a Git workflow has been specially set up.

Take a look at the flow chart of this workflow

The main implementation

  1. advantages
  • Each function is independent, both on both use
  • Separate features live, review code is more friendly
  • 0 wait to realize the theoretical infinite environment
  • Conflicts are preloaded and exposed on the first fixed branch
  1. disadvantages
  • Conflict resolution is not neat enough. You need to pay attention to the sequence of functions to be online after conflict resolution

instructions

  1. Environment Description:
  • The warehouse uses GITLab;Modify the Mr Configuration as follows

  • Deploy using Jenkins
  1. Branch instructions
  • Master: online branch (protected branch)
  • Staging: pre-launch branch (protected branch)
  • Test: Test branch (protected branch)
  • Dev: Develop the test branch, and the developer can merge the functional branch into this branch and push it to the remote side, but cannot make any changes on dev
  • Function 1, 2, 3… : Development branch (pulled out based on master, deleted after online)

The development process

  1. Based on master, pull branch staging, test, dev… (One to one correspondence with Jenkins environment). The branch setup is as follows

Note: The dev branch does not need to be set as a protected branch. This branch is open to developers for the following reasons:

  • Verify that the functionality branch conflicts with other functionality in the dev branch
  • Merge the local function branch into the dev branch and push it to the remote side; Automatic deployment can be realized in cooperation with Jenkins.In this configuration.If your company does smooth deployment, other fixed branches can be set to trigger automatic deployment when merging Mr (Pain point 4 can be solved here without any problem)
  1. Feat2, Feat3, Fea1, Feat2…
  2. Feat branch => Merge the local dev branch into the local dev branch. Feat Branch => Merge the local dev branch into the local dev branch.
  • If yes, record the conflict. Roll back dev to the status before merge. Switch back to the FEAT branch
  • No conflicts => push local dev (each fixed branch has its own independent function at the corresponding stage, and completing a fixed branch is countless virtual test environments, which fixes pain point 1)
  1. If the Dev environment self-test is successful => Remote feat Feat Feat Feat To Staging => Pre-release environment Remote feat Lift Mr To Master (select Delete branch)
  2. If there is a function on the master, and temporarily unable to go online, then you can return the master to the state before the feat merge, and then need the function back into it again (solve the pain point can not go back).

Matters needing attention

  1. Git Account Configuration

Since two user records appear in the commit record of git submitted by the same person, it is recommended to configure the working Gitlab account globally.

git config --golbal user.name "XXX"
git config --golbal user.email "[email protected]"
Copy the code

If you have a special project or third-party library, you can set the local account in the corresponding project directory

git config --local user.name "XXX"
git config --local user.email "[email protected]"
Copy the code
  1. Disable local changes to the dev branch code

This is what happens when you modify dev’s code locally

  • The code is not on the FEAT branch. The code is lost when the FEAT branch is merged with another branch, such as Test
  • If the code was on dev and feat was modified, a code conflict would occur

Suggest way link configuration terminal: www.cnblogs.com/weixuqin/p/… Can clearly know the current branch.

  1. Prohibit merging other branches such as dev, test, staging into the development branch (master)

By merging a fixed branch into a local development branch, it is possible to merge functionality that others are developing into your own branch. Now, if you merge it then you’re going to have a conflict on each of the fixed branches after the conflict is resolved. (Master is used to create new development branches)

  1. Don’t use base

Since rebase is merged to another branch such as dev, a new commit ID is generated, such as B; If the feat has changed the same location as the commit ID (B), merging the feat into dev will cause a conflict.

Conflict resolution posture

  1. Modify in different lines

Fixed branch rollback Merge => Switch back to the local branch

Merge again to fixed branch, Conflict Resolution (DOG)

  1. Communication to modify

Fixed branch back merge test1 concentration change = > = > negotiation based on test2 conflicting files back to the master = > test2 new branch named after need to know to be behind the test1 online

Merge into a fixed branch