The difference between git pull--rebase and git pull

Reprint: Http://hungyuhei.github.io/2012/08/07/better-git-commit-graph-using-pull---rebase-and-merge---no-ff.htmlpull--rebase

First of all, spit.

If you're in code review and see (What's going to be called the "Submit line graph" below), especially if someone like me has some sort of neat freak, does it feel particularly uncomfortable? If so, take a look at the following:)

Why

Git as a distributed version control system, all modifications are based on the local, in the team collaboration process, assume that you and your partner in the local each have their own new submissions, and your partner before you push the code to the remote branch, so you must first execute git pull to obtain the partner's submission, and then to Push your own commits to the remote branch. As with Git's default policy, if the commit line graph between the remote branch and the local branch is forked (that is, not fast-forwarded), Git performs a merge operation, resulting in a meaningless commit record, resulting in confusion like that.

Solve

In fact, in the pull operation, the use of git pull --rebase options can be a good solution to the above problem. Plus --rebase The argument is that if the submission line graph has a fork, Git will rebase the policy instead of the default merge policy. What are the benefits of using the REBASE strategy? It's a man git-merge good idea to take a look at the diagram.

Let's say that the commit line graph is this way before the pull is executed:

                 A---B---C  remotes/origin/master                /           D---E---F---G  master

If this is done git pull , the commit line graph will look like this:

                 A---B---C remotes/origin/master                /                    D---E---F---G---H master

The result is an H unnecessary commit record. If it is executed git pull --rebase , the submission line chart will look like this:

                       remotes/origin/master                           |           D---E---A---B---C---F‘---G‘  master

FGtwo commits rebase are re-stitched through the way C after, the extra fork is removed, the purpose is achieved.

Summary

Most of the time, it git pull --rebase is used to make the submission line graph look better, thus facilitating code review.

However, if you are not very skilled at using git, my advice is to git pull --rebase practice a few more times, because rebase is a "dangerous behavior" in Git.

In addition, it is important to note that the use of direct pull is more git pull --rebase prone to conflict, if the expected conflict is more, the proposal or direct pull.

Merge--no-ff

The above git pull --rebase strategy is to fix the submission line diagram, so that it forms a straight line, and the strategy to be used git merge --no-ff <branch-name> is to reverse its way, deliberately make the submission line diagram fork out.

Assuming you're preparing to merge two branches locally, and just these two branches are fast-forwarded, then you get a straight-line map of the lines when you merge directly, but if you want to tell your partner more clearly: This series of submissions is for the same purpose , then you can deliberately make a submission to the submission line graph fork.

The result of the execution git merge --no-ff <branch-name> would probably be this:

The Middle Fork route diagram shows clearly that these submissions are for complete adjusting user domains and tags

Further

Often my habit is to check if the feature branch is "partially behind" the remote Dev branch before merging the branch (assuming that you want to merge the feature branch into the Dev branch locally):

git checkout devgit pull # 更新 dev 分支git log feature..dev

If no submission information is output, the feature is up-to-date for the dev branch. If the output is executed immediately, the git merge --no-ff Submission line chart will look like this:

So before merging, I usually do it first:

git checkout featuregit rebase dev

This allows the feature to be re-stitched to the updated dev and then merged, resulting in a clean and comfortable submission line graph.

Again: As mentioned earlier, rebase is "dangerous behavior", it is recommended that you are familiar with git to do so, otherwise it is not worth the candle.

Summarize

git pull --rebase git merge --no-ff The code that is used and actually and directly used git pull git merge should be the same.

The git pull --rebase main use is to flatten the submission of the approximate line graph, while the git merge --no-ff Fork is deliberately created.

Word: If you're a bit of a neat freak, consider using them.

The difference between git pull--rebase and git pull