Git is a great tool for collaborative development, and its most powerful feature is that it allows you to create and switch code branches very quickly. I cut a Feature branch from the trunk, and was about to go to the toilet for a water stroke in the middle of the development, when I came to test, I found a flash back Bug in the trunk code. I didn’t panic at all, but held back for the first time, cut another BugFix branch from the trunk, and then cut back to the Feature branch after modification, so the keyboard pushed forward, the seat moved back, stood up and turned around. Jilt a coat corner, broken pace cat walk to the toilet, deep and famous. (See GitFlow for details on how to manage Git branches.)

Git makes it easy to split code on different branches, but ultimately on the trunk. There are two ways, merge and rebase, which is also called rebase. Combination is easy to understand, but also more commonly used, what is the ghost, light look at the name a little unclear feel li look. Since both can merge code from one branch into the other, what’s the difference? Which should be used in what situations?

How do you design code integration if you are the parent of Git

Before we talk about the difference between a merge and a derivative, let’s think about this: let’s say we have a master branch and an experiment branch

In one case, we take C4, C3, and C2, the closest branching point of the branch, and we can compare the three ways that the experiment code is different from the master’s code, and then we can extract those differences and submit them to the master. Thus, a new commit is generated on the master.

It is a three-way merge of the latest snapshots of the two branches (C3 and C4) and their nearest common ancestor (C2). The result of the merge is a new snapshot (and commit).

So can I not do this difference comparison? Another way to think about it, the same master and Experiment branch diagram:

Although C3 and C4 are committed on different branches, if they are committed on one branch, then we have the final code we want. This is the idea of derivatives.

Git Git Git Git Git Git Git Git Git

1. Check out the experiment branch and perform derivatives on the master

$ git checkout experiment
$ git rebase master
Copy the code

$ git checkout master
$ git merge experiment	
Copy the code

Its principle is to first find C2, the most recent common ancestor of the two branches (i.e., the target branch master of experiment and derivative operation of the current branch), and then compare the previous submissions of the current branch with that of the ancestor to extract the corresponding modifications and save them as temporary files. The current branch is then directed to the target base C3, where changes previously saved as temporary files are applied sequentially. Note that experiment will discard the previous C4 submission and resubmit the code with the C4 change as the new C4′.

It can be seen that the core of derivatives lies in “process repetition” **.

A minefield of derivatives

As you can see from the above, although the result of both consolidation methods is the same, derivatives make the commit history much cleaner. When you look at the history of a branch that has been refocused, you see that although the actual development work is in parallel, it appears to be serial, and the commit history is a straight line with no forks. Do we just use derivatives? Don’t worry, it’s a minefield!

In Git’s recommended derivatives, the commit (C3) on the target branch master is unchanged, while the Experiment branch dismisses some existing commits (C4) and creates some new commits (C4′) that are identical but actually different. So in this case, let’s call the master a passive branch, and the experiment is an active branch. If before to yan, you have to submit a delivery to a warehouse, while others have been pulled from the warehouse to submit and follow-up work, at this point, if you use git rebase command to reorganize the commit and push again, your partner so they will have to once again to the job at hand and you submit to consolidate, If you then have to pull and integrate their modified commits, things get messy.

Do not use derivatives as “active branches” for common branches, such as the Develop branch in GitFlow, because this can break other people’s commit records and affect team collaboration. For example, if you develop a new feature independently, check out a feature branch from Develop, and open the branch to Develop the feature as an “active branch”. Develop, develop, develop, develop

Usage scenarios

If you’re a normal teenager, like me, you just play merge and you can’t go wrong. If you are a literary youth, like me, also play yan-hua, just lightning.

The official explanation of the derivatives

Git-scm.com/book/zh/v2/…