Talk about Git pull--rebase

There is a scene that happens often.

All are based on the develop pull-out branch for parallel development, where there are probably up to dozens of branches. Then each other in their own logic to write, the time may take a few days or weeks. During this time you may need to pull the submission from a colleague on the remote develop branch occasionally. This is a good habit, so that you can avoid the long-term development of a useless code, and look back at the code is not the new code. There are even a lot of conflicts that need to be addressed, and at this point you may need to test back some of the code for the conflict, which is a hassle.

So let's take a look at the time you need to add-rebase parameters to your pull, so you can avoid many problems. --rebase's intention was to make things look continuous and graceful, rather than a lot of useless merge commits.

There are times when you pull the code and you get a hint like this:

650) this.width=650; "title=" 1 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 1 "src=" http://s3.51cto.com/wyfs02/M02/8A/1B/wKiom1gmtK_ Qyjinaabjbfmr30o334.png "width=" 849 "height=" 176 "/>

This time you are habitual, "esc:wq", the direct default commit comment. Then your commit log will have a very bad log.

650) this.width=650; "title=" 2 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 2 "src=" http://s3.51cto.com/wyfs02/M01/8A/17/wKioL1gmtLDg-ahtAABc0_ Wbgbc497.png "width=" 796 "height=" 340 "/>

If you don't know how to merge these meaningless commits at the end of the release, your release branch will end up being ugly. (For merge Commit please refer to: Chat git merge–squash)

The problem is normal, and let's see why this problem arises. The branch commit route under normal circumstances:

650) this.width=650; "title=" 3 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 3 "src=" http://s3.51cto.com/wyfs02/M02/8A/1B/ Wkiom1gmtlgiq950aaa2hwbugf4351.png "width=" 564 "height=" 146 "/>

There are three commits on the current develop branch. Now that we have two projects starting up, we need to pull out two separate branches independently of each other.

650) this.width=650; "title=" 4 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 4 "src=" http://s3.51cto.com/wyfs02/M00/8A/1B/ Wkiom1gmtllyrmjqaacbq4y85co343.png "width=" 953 "height=" 348 "/>

We separately checkout–b out two branches, independently of the development of non-interference. Under normal circumstances, if the changes in these two branches are not re-posted or conflicting, everything goes well. (A re-paste is a modification that can be automatically merged by the system, and conflicts need to be resolved manually.) You have to reproduce this phenomenon is still a little trouble, you want to modify exactly can be re-pasted location, not directly caused conflict place.

I changed something in the Develop_newfeature_authorcheck and push it to develop. Then checkout to Develop_newfeature_apiwrapper.

Git pull

This will pull the Develop_newfeature_authorcheck branch modification directly down to the local code merge and produce a commit, the merge commit.

650) this.width=650; "title=" 5 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 5 "src=" http://s3.51cto.com/wyfs02/M00/8A/17/ Wkiol1gmtlowcel1aacxjtrne58160.png "width=" 888 "height=" 327 "/>

You can use Git pull–rebase this ending is completely different. -rebase does not produce a commit commit, but instead appends your e commit to the end of D commit. When you look at commit log, there is no more commit that you don't know. Actually the F commmit here is meaningless, it's just a merge commit. And the branch of the message inside will not be saved in the future, and these branches are erased.

Git pull–rebase makes a commit look natural.

650) this.width=650; "title=" 6 "style=" border-left-0px; border-right-width:0px; Background-image:none; border-bottom-width:0px; padding-top:0px; padding-left:0px; padding-right:0px; border-top-width:0px "border=" 0 "alt=" 6 "src=" http://s3.51cto.com/wyfs02/M01/8A/17/ Wkiol1gmtlsw7s8-aabwlo6mk94912.png "width=" 1050 "height="/>

Because the code has a back-and-forth dependency, just this depends on the development of the time who first who after the problem.

Talk about Git pull--rebase