How can I understand git workflow? This big factory branch management wulin secret book please quickly accept!

Writing in the front

Many people may marvel at the efficient time management of “Luo Zhixiang”. I was quite shocked by this, so I thought about it and extended it to my favorite job — coding!

I was surprised to find that “Xiaozhu” and Git have similar management modes for team projects.

In this article, I will teach you how to effectively manage a multi-party project with Git.

How to use Git for efficient multiplayer development?

A brief introduction to the branching model

What is a branch? It can be understood as the things that should be done in different time periods during a product iteration:

• The official release in the app store is a package based on the release branch
• Alpha: [grayscale branch] Only incorporates bugfixes that have little impact
• Release: [integration/regression branch] merge into bugFix
• Develop: this branch is an unstable branch, and all features can be closed at any time during development
• Feature: [Requirement branch] Each new requirement will pull a feature branch from the dev branch for development

Are you a little surprised to see this. So many branches in a simple iteration? I’m all messed up. Don’t panic, take you into the actual combat –

Use a project practice to clarify branch management

Scenario 1: Requirements review phase

A release iteration should have clear requirements, just as a YP needs to identify objects. At the end of the requirement review, the team leader will assign new requirements to the team members. We excitedly pull a feature branch from devlop’s main branch (note that the name should be standard, usually feature/[version number]/[requirement abbreviation]) and start the development of the road of no return…

Git checkout -b feature/v1090/my_first_feature origin/ v1090 12Copy the code

** Why does each feature need to pull a separate feature branch for development? ** I think we all understand the point here. Imagine you’re halfway through developing requirement A when A girl asks you out to dinner. You don’t say a word, you push the code up and come back after dinner. If your “unstable” commit causes a feature to crash, you block the team’s work. When you come back full of food and drink, what you’re waiting for is a bloody storm…

Scenario 2: Development phase

Once we have a feature branch of our own, we can start working on our main battlefield! Research, development, self-testing, late nights, hair loss… After so much hard work, my feature branch is finally running as described in the product requirements document!

But it’s still full of holes. Don’t wash your dirty linen in public. It needs to be stable before formal delivery.

The next step is to package and submit the test on its feature branch. In a burst of love photograph kill, hard knock after grinding, finally change test little sister slightly nod: “accurate”. My feature branch also changed from an unstable branch to a stable one.

You are now eligible to join the Develop branch!

Scenario 3: Integration Phase

Unknowingly, we reached the integration stage. The various players gradually merged their completed feature branches into the Dev branch. At this point the build master starts Shouting in the group:

“8 o ‘clock start, want to get on the car to grasp!”

Call yourself on time little princess how could I miss every bus? Finally, I reviewed the code to ensure that it works normally and the code is the same as the person, and there is no problem with the normative elegance. To develop ~

Git push origin develop/v1090 12Copy the code

At this time, the feature branch has come to an end, in order to prevent remote/local accumulation of too many unnecessary branches. You can use

Git push origin -d feature/v1090/my_first_feature/git push origin -d feature/v1090/my_first_feature 1234Copy the code

Delete ~

Scene four: The regression phase

At this point, all requirements for this version have been merged into the DEV branch. BM pulled a Release regression branch from the Dev branch and gave it to the team for regression testing.

What is regression testing? This is a hodgepodge of tests for all features (especially those associated with the features in this version).

If the test on the feature branch can be said to be aimed at a certain function, then the regression test can be regarded as the overall test of the function and quality stability of the whole App.

The regression phase does not incorporate any new requirements, and resolved bugfixes are collectively committed to the Release branch, which is then merged into the Develop branch after regression.



This stage is a game, a war between RD and QA! Be sure to have a good relationship with QA!

Scenario 5: Gray level

In the gray stage, the new version of APP is distributed to a certain level of online users for experience. At this point, the APP has passed layer upon layer tests to ensure stable operation.

But you never know, you can never imagine how Chinese netizens operate.

Therefore, there may still be some bug caused by abnormal case online. BM will pull an alpha branch from the Develop branch for grayscale.

The grayscale phase generally does not accommodate bugfixes that vary greatly, and fixes only obvious crash bugs and minor changes.

Scene 6: Release

Finally to the stage of the version! 🎉 🎉 🎉

After the gray scale is finished, BM will submit the code to the Master branch and pack the official package to the app store. After a while, we will be able to see our fresh APP in each major mobile app market!

Excited hearts, trembling hands. Download it, open the app, and experience the features you’ve written. It’s perfect and it’s so cool

Take you to draw a picture of the pig branch model ~

I have also shown luo Zhixiang how to manage his time with the idea of git branch management. The picture below is just for entertainment

Bosses can also try drawing a piggy’s time management model if they get the hang of it. Please share it without reservation.

After all, everyone wants to know the ropes of multiplayer development.

Write in the last

Last week, I wrote a bunch of unfinished code and submitted it to the public branch because I didn’t have a clear sense of branch when I was developing with the same RD. As a result, the project repeatedly compiled errors and crashed. The whole team spent a whole day to solve the bugs caused by me.

And then I got chewed out by the group leader. I’ve thought about the pain.Make sure you review your branch situation and code stability carefully before each merge, and don’t block progress due to your own fault.

All in all, Git is one of the best ways to manage teamwork and is basically an indispensable tool for Internet companies to develop. Using Git well can bring great convenience to project development.

Study hard and apply it well (#^.^#)！！！！