reprint from 2015-12-02 Lazybios Day ArchCompared to the merge command, we are relatively unfamiliar with the rebase, rebase this command in the "Pro Git book" translated into "Yan", feel good awkward, personal feeling whether it is from the tone or line (for) called "variable base" to be better and more appropriate. The general flow of rebase
STEP1: Scenario Assumptions
You origin
create a branch based on a remote mywork
branch
git checkout -b mywork origin
STEP2: for development
Once you've created your branch, you start working on the branch, and mywork
over time you've committed 2 commits: C5, C6. Then you pull the origin
branch and find that while you're working, no one else is resting, orgin
The branch also had two commits during this time C3, C4:
STEP3: Merging Branches
After discovering similarities and differences, you want to merge other people's functions in your current work progress, and this time it's about branching, you have two choices, one is merge
, and the other is rebase
(always remember that merge and rebase do a thing), which we use here rebase
.
Switch the Origin branch first, and pull
origjn
pull down the latest changes on the branch by instruction. Then you can use the git checkout mywork
switch to mywork
branch, and here it will be used for the git rebase orgin
transformation of the base.
If there is a conflict, the terminal will give you a hint to ask you to deal with the conflict, when you have finished the conflict, by git add
confirming the changes, commit
do not directly perform git rebase —continue
the transformation of the base even if it is completed.
Here's a simple principle, when you perform a "variable-base" operation, git will mywork
revoke all new commits from your branchand send .git/rebase
them to you temporarily. directory, and then after the empty mywork
Branch updated to origin
Branch status, and finally apply the changes you saved temporarily to the synced mywork
on the branch. This has the effect of "variable base", which starts with the last public part of the commit. So it's called "the base". But there are two points that need to be highlighted:
Merge and rebase The result is identical, the image says, the two are the same .
The commit after using rebase"and the commit before the change, i.e., C6 ' and C6 are different, their SHA-1 values are different, and git sees them as two commits.
Finally, it is recommended to use the Rebase command when it is better to be patient to read the command prompt information, in fact, it already contains everything, and the content is not much.
Rebase usage Scenarios on GitHub
Now the mainstream Git collaboration method recommended in the community is also using the rebase command, that is, fork a code base, keep a remote branch to keep up with the progress of the main library, another feature branch to patch, when the patch is ready, Synchronize the code on the remote branch locally, keep it consistent with the main library, and if the main library changes during the time you patch, then you need to do a pre-rebase operation locally to ensure that your changes are built on top of the latest code in the main library. This is pretty much the case with you helping the author to deal with the conflict locally, so that when the author merges your code, it will be easier. In other words, the process of using rebase is also a self-checking process that forces you to review the changes, reducing the workload between contributors and owners. Because no one is more familiar with your code than you.
The difference between rebase and merge
Git Merge branch There are two commands one is merge, the other is rebase, the two ends are consistent, but in some detail the processing is very different. Is the merging of branches with merge and Rebase, respectively. As you can see, using the rebase command to merge the branch is linear, and with the merge after a number of branches, this small difference, in fact, the final result has no effect, is only the difference in the way.
Explain git pull-rebase
git pull —rebase
, this command is still very high in the actual use of the exit rate. We start from the beginning git pull
, the git pull
complete should be git fetch
+, the default is to pull the git merge FETCH_HEAD
git pull
code First, then merge, it said that using the merge will be more than a merged commit
and a branch, This can happen if commit and merge are frequent, but the rebase is different, it stays linear, so the commit record looks neat and the use —rebase
is replaced by the meaning git rebase
git merge
.
is a long-time commit record using git fetch + git merge, which is not complicated, you can think about it on this basis, or Google a similar diagram.
Reference reference
http://dwz.cn/2goS5e
Http://dwz.cn/2goSKc
Git: Talk about the rebase command, the difference from merge