Git rebase is in trouble. What to do? Waiting line

We are using git Have you ever made a mistake in the process of ？

I've been through , My first disaster was the use of git rebase Caused by the , Although it was finally solved , But it still scares me a lot . It was like this .

Let's take a look at this picture ：

Briefly explain what's in this picture ,C1 Nodes are the smallest common ancestor of all branches . It can be understood as the earliest master edition , And then we checkout Two branches came out , The difference is bugFix and feature. among feature It's a new branch of our development , and bugFix It's repairing bug The branch of .

When we put bugFix After that, hurry up merge master Released , When we released it, we found bugFix There's a little bit of a problem . For example, the file that should not be submitted has been submitted , Plus, we don't use rebase Combined in the form of , So it looks like commit The records are a little messy . So I decided to use rebase Fix the submission record , Use when you're done git push -f Forced update of remote branch .

Because we've been push After , Want to use a new commit If the record covers the old, it must be used -f Push... By force . These operations are routine operations , But I accidentally made a big problem , Almost led to the tragedy later .

I'll sell you something first , Let's think about it for a few seconds , What's the hidden question here ？

rebase The taboo of

The problem here is feature Branch , We can see from the picture that feature Branch is merge 了 C5 Node's . But when we rebase push -f After that ,C5 Nodes don't exist . Let's show you the pictures and you will understand , This is rebase The previous dependency tree ：

We rebase And then the dependency tree became like this ：

Because of feature I used to merge Over master And rely on C5 Node , and master stay rebase Force push After that, there is no more in the whole link C5 Node . That is to say feature The branch depends on a node that no longer exists , It's not too bad at this time , Because feature The branch hasn't been updated yet , If feature Branch pull once , Then the whole branch will be like this ：

That is to say, the same code is in feature Two versions are stored in the branch , And if feature Merge into master After that , You'll find out before push -f Those submissions that were forced to abandon were merged again , And the whole thing commit Of log It's going to be very, very chaotic , It's hard to understand .

If these branches are their own , Then if you pinch your nose , If these branches belong to someone else in the team , It's basically unavoidable to make a mess . If there is one in the group Git The boss knows how to solve this situation. It's OK , Otherwise , It's very difficult to recover completely , It's very likely that one operation has no idea where the deviation is , I don't know how to find it back .

I was fine , I have learned how to deal with this situation when I make trouble , Although still can't avoid stepping on the pit , But fortunately, I came out of the pit in time . Before we look at the method of debonding , Let's start with a question , For rebase What is the root cause of the chaos , How can we avoid ？

To solve rebase Only rebase

Why did we just C8 Once the node pull It will lead to local chaos ？ Because we've introduced , When we execute pull When , In fact, it was carried out git fetch and git merge Two steps . So it is equivalent to that we put master The change of the branch merge Once , We depend on rebase Previous changes , Such a merge Naturally, the two versions will be changed merge Together .

To solve this problem , We can't be in C8 Node time pull operation , Because pull Operation contains merge,merge It can lead to mistakes . It is not difficult to solve this problem , We can rebase To master On . When we execute rebase When ,git Will find out that our current branch is unique and master There's no change on the branch , Extract these changes and apply them to master We got a new result on .

So we don't put... In our records C2 and C5 Brought in .

Divergent thinking

Let's think through the above process , What's the conclusion ？

In fact, the conclusion is very simple , Namely rebase Although it's very easy to use, it's also very convenient , But it also has conditions that apply , The biggest condition is that if there are other branches that depend on the current branch , We can't use it at this time rebase, Otherwise, it will cause confusion .

What is the cause of the confusion ？ It's essentially us rebase It's time to change commit The record of , Different people have different opinions on this point . There is a group of people who think git You can't tamper with your submission records , The purpose of its existence is to record repo All the changes that have taken place . If you use rebase And so on , Then we can't trace the changes and versions well . There's another person who doesn't think so , They feel that if the change of the record is very confusing, it is very inconvenient for users to read , At this time, it is very necessary to use some methods to repair it . Tools are invented for use .

The two parties are arguing endlessly , Different people have different views , It can be said that it is a problem of values, and it is not too much . I personally prefer the latter on this issue , Since there is such a good tool , Nature should use . Use is not abuse , We need to follow certain rules , It's the only way to make sure you don't make a mess of it . For example, it must not be used when there are other downstream dependencies rebase, Otherwise, it is almost certain that it will cause trouble .

Today's article is here , I wish you every day something to gain . If you still like today's content , A third company, please ~（ Like it 、 Concern 、 Forward ）

Link to the original text , Seeking attention

This article USES the mdnice Typesetting

![](https://img2020.cnblogs.com/blog/1906483/202011/1906483-20201106162502684-19946313