Git Branching Workflow

3.4 Git Branching-workflows developed using branching to develop with branches

Now that we've learned to create new branches and merge branches, what can (or should) be done with it? In this section, we will describe some of the workflows that are developed using branching. And it is because of the convenience of branch management, it is derived from this kind of typical work mode, you can choose a use to see according to the actual situation of the project.

Long-term Branch

Since Git uses a simple three-party merge, it is not difficult to merge a branch to another branch over a long period of time. That is, you can have multiple open branches at the same time, each of which is used to accomplish a specific task, and as the development progresses, you can move the results of a feature branch to other branches at any time.

Many developers who use Git like to work in this way, such as justmasterThe branch retains completely stable code, the code that has been published or is about to be published. At the same time, they also have a namedevelopOrnextParallel branch, dedicated to subsequent development, or only for stability testing-certainly not necessarily absolute stability, but once in a stable state, you can merge it intomasterIn Thus, in order to ensure that these completed feature branches (short-term branches, such as the previousiss53Branch) to pass all the tests and not introduce more errors, you can go to the trunk branch and wait for the next release.

Essentially what we're talking about is a pointer that keeps moving right along with the commit object. The pointer to the stable branch always lags behind in the commit history, while the frontier branch is always relatively front (see figure 3-18).

Figure 3-18. Stable branches are always older.

Or think of them as work lines, perhaps a better understanding of the set of tested submissions to be selected to a more stable pipeline (see figure 3-19).

Figure 3-19. It might be easier to imagine a pipeline.

You can use this to maintain different levels of stability. Some major projects will also have aproposed(recommended) orpu(Proposed updates, recommended updates) branch, which contains those that may not yet mature into thenextOrmasterThe content. The goal is to have different levels of stability: when these branches enter a more stable level, merge them into higher-level branches. Again, it is not necessary to use multiple long-term branches, but in general, this is easier to manage for very large projects or for very complex projects.

Feature Branch

Attribute (Topic) branching can be used in projects of any size. An attribute branch refers to a short-term branch that is used to implement a single feature or its associated work. Maybe you've never done anything like this in a previous version control system, because it's often too expensive to create and merge branches. In Git, however, it's common to build, use, merge, and delete multiple branches within a day.

We have seen this usage in the example in the last section. We have creatediss53AndhotfixThese two feature branches, after several updates have been submitted, are merged into the trunk branch and then deleted. This technology allows you to quickly and completely switch context-because your work is scattered across the pipeline, and the changes in each branch are related to its target characteristics, and things like browsing the code become easier. You can keep the changes you make in the feature branch for a few minutes, a few days or even months, and then merge them when they mature, without caring about the order or the progress they set up.

Now let's look at a practical example. Take a look at Figure 3-20, from bottom to top, at first wemasterWork to C1, then start a new branchiss91Try to fix bug number 91st, when submitted to the C6, there is a new solution to the problem, so from the previous C4 place another branchiss91v2, and went back to the trunk when the C8 was done.masterC9 and C10 were submitted toiss91v2Continue to work, submit C11, and then come up with a less definite idea, frommasterThe latest submission C10 a new branch.dumbideaDo some experiments.

Figure 3-20. Has a commit history for multiple attribute branches.

Now, let's assume two things: we finally decided to use a second solution,iss91v2In addition, we havedumbideaThe branch showed the colleagues that it was a genius. So next, we're going to abandon the originaliss91Branches (which in effect discard C5 and C6) and merge directly into the trunk with two additional branches. The final commit history will turn into figure 3-21:

Figure 3-21. Merge the branching histories of Dumbidea and Iss91v2.

It is important to keep in mind that these branches are all local branches. When you use branching and merging, everything is done in your own Git repository-it doesn't involve interacting with the server at all.

Git Branching Workflow