Differences between jiu_rebase and merge in the egit User Manual of git plug-in eclipse

The final result of rebase and merge operations is the same, but the implementation principle is different.

From the above mairobro example, we can know how pull merges historical records. In fact, the default pull operation is the merge operation of a branch, as shown below:

The submission records of mairo's younger brother are as follows:

The submission record of mairo's brother is as follows:

First, mairo's younger brother pushes updates to the server, so that the server-side records are the same as those of mairo's younger brother's local records. Then mairo's brother executes the pull operation, now let's analyze how pull operates.

L by default, pull updates the latest records on the server to the corresponding mirror branch in the local remote tracking.

L then perform the merge operation on the mirror branch of local and the mirror branch of remote tracking.

After the merge operation, a new merge record node is added, as shown below:

It can be seen that mushrooma was before mushroomb. The time relationship does not depend on who executes the push first, but on who executes the commit first in the local repository. Therefore, merge records each commit strictly in chronological order.

Next let's take a look at rebase. In fact, rebase also combines the two branches. After mairo's younger brother pushes the update, the history of the mirror branch on the server side is as follows:

Mairo's local history is as follows:

Now mairo's brother does not perform merge operations, but rebase operations. The final result is as follows:

The obvious difference is that there is no branch record, and you have noticed that mushrooma * is not the same record as mushrooma. Let's analyze the rebase operation first, what changes have mairo's history taken:

L first save the update part of the current branch to the temporary area, and the current branch is reset to the record of the last pull.

L then add the server updates to the current branch. The current branch is the same as the server branch.

L submit the original Branch's update part of mushrooma to the end of the current branch, that is, add the mushrooma update to the end of mushroomb. Of course, the update record is no longer the previous mushrooma, if a conflict exists, use the comparison tool to resolve the conflict and change the record to mushrooma *.

If mairo's brother has submitted mushrooma1, mushrooma2, and mushrooma3, after rebase is executed, the merge operations shown in the sequence of mushrooma1, mushrooma2, and mushrooma3, the last record is mushrooma1 *, mushrooma2 *, and mushrooma3 *. Obviously, rebase operations are more complex, conflict is more likely, and not recorded in chronological order.