Skip to content
Created: November 18, 2017

Git branch development workflow ​

Documentation: Git branch development workflow

long term branch ​

Because Git uses a simple three-way merge, it is not difficult to repeatedly merge one branch into another over a long period of time.In other words, you can have multiple open branches at different stages of the entire project development cycle; you can regularly merge certain topic branches into other branches.

Many developers who use Git like to work in this way. For example, only keep completely stable code on the master branch. The development process is in the dev branch. After development is completed, it is merged into the test branch for testing. Only the stable code that passes the test is merged into the master branch.

The dev and test branches do not need to remain absolutely stable, but after test reaches a stable state through testing, it can be merged into the master branch.

In fact, what we just discussed is a pointer that keeps moving to the right as you commit.The pointer to the stable branch (master) is always far behind in the commit history, while the pointer to the cutting-edge branch (dev or test) is often further ahead.

You can maintain different levels of stability this way.Some large projects also have a proposed (recommended) or pu: proposed updates (recommended updates) branch, which may not be able to enter the master branch because it contains some immature content.The purpose of this is to give your branches different levels of stability; when they have reached a certain level of stability, merge them into branches with a higher level of stability.Again, using multiple long-lived branches is not necessary, but it is often helpful, especially if you are working on a very large or complex project.

Topic branches (short-term branches) ​

Topic branches work for any size project .Topic branching is a short-term branch , it is Used to implement a single feature or its related work 。

You already created the iss53 and hotfix This usage has been seen in topic branches.The topic branch you used in the previous section ( iss53 and hotfix branch), and after they were merged into the trunk branch, you deleted them.This technology allows you to quickly and completely context-switch - because your work is distributed among different pipelines, in different pipelines Each branch is relevant only to its target feature , therefore, It will be easier to see what changes you made when doing things like code reviews .You can keep your changes in a topic branch for minutes, days, or even months, waiting for them to mature before merging them, regardless of the order in which they were created or the progress of your work.

Consider an example where you work on the master branch to C1, then create a new iss91 branch to solve a problem, and work on the iss91 branch to C4. However, you have new ideas about that problem, so you create a new iss91v2 branch to try to solve the problem in another way, and then you return to masterAfter working on the branch for a while, you come up with an uncertain idea, so you create a new dumbidea branch in C10 and do some experiments on it.Your commit history will look like this:

Have commit history for multiple topic branches.

Figure 1. Submission history with multiple topic branches ▲

Now, let's assume two things: you decide to use the second solution to solve that problem, which is the solution in the iss91v2 branch.Also, you show your dumbidea branch to your colleagues and it turns out to be amazing.At this time you can abandon the iss91 branch (that is, discard the C5 and C6 commits), and then merge the other two branches into the trunk branch.Eventually your commit history will look like this:

Commit history after merging  and  branches.

Figure 2. Commitment history after merging dumbidea and iss91v2 branches ▲

We will reveal more details about the branching workflow in Distributed Git, so please make sure you read that chapter before deciding what branching scheme to use for your next project.

Keep in mind that when you do so many operations, these branches are all local.When you create and merge branches, all of this happens within your local Git repository - there is no interaction with the server.