Git rebase does not retrieve the code to get back with git fetch first, git rebase is the merge code.
(1) First use Git fetch to return the code on the server
(2) First merge with Git rebase origin/master
(3) If a conflict occurs, you can then use Git diff to view the conflict, manually break the conflict, add the modified file with git add ' filename ', and then use Git rebase--continue to continue the unfinished merge
(4) Finally, you can update the server with Git push.
Transferred from: http://blog.chinaunix.net/uid-26952464-id-3352144.html
Git Community Book in the Chinese version, excerpt as follows:first, the basicgit rebase is used to merge changes from one branch into the current branch. Suppose you now create a branch called "MyWork" based on the remote branch "origin". $ git Checkout-b mywork originAssumeThe remote branch "origin" already has 2 commits,Now let's make some changes in this branch and then generate two commits (commit).$ VI file.txt$ git commit$ VI otherfile.txt$ git commit...but at the same time, some people have made some changes to the "origin" branch and made the submission. This means that the two branches of origin and mywork each "go forward" and "fork" between them.
here, you can use the "pull" command to drop the changes on the "origin" branch and merge with your changes; The result looks like a new "merged commit" (merge commit):
However, if you want the "mywork" branching history to look like it has not been merged, you might be able to use Git rebase:$ git checkout mywork$ git rebase originThese commands will cancel each commit (commit) in your "mywork" branch and temporarily save them as patches (patches) to the ". Git/rebase" directory, and then update the "mywork" branch to the newest "origin" branch. Finally, the saved patches are applied to the "MyWork" branch.when the ' mywork ' branch is updated, it points to these newly created commits, and those old commits are discarded. If you run the Garbage collection command (pruning garbage collection), these discarded commits are deleted. (see git GC)Ii. Settlement of conflictsIn the process of rebase, there may be conflicts (conflict). In this case, Git will stop rebase and will let you resolve the conflict, and after resolving the conflict, use the "git-add" command to update the index of the content ( index), then, you do not need to perform git-commit as long as the execution: $ git rebase --continue This way git will continue to apply the remaining patches. At any time, you can use the--abort parameter to terminate the action of Rebase, and the "MyWork" branch will return to the state before the start of rebase.$ git rebase --abort iii. The difference between git rebase and git merge Now we can look at the difference between the history created by merging and using rebase: when we use git log to see Commit, the order of the commits is different. Suppose C3 submitted to 9:00AM,C5 submitted at 10:00AM,C4 submitted to 11:00am,c6 submitted in 12:00am, git mergeC7, c6 ,c4,< Span style= "Word-wrap:break-word; Color: #808000; " >c5, C3,c2,c1 The order in which to merge the observed commits using Git rebase (from new to old) is:C7,C6 ', C5 ', c4,c3,c2,c1 because C6 ' commits just C6 commits the clone, C5 ' commits only C5 commits the clone,from the user's point of view, the sequence of commits (from new to old) that was merged with Git rebase is:C7,c6,c5,c4,c3, c2,c1
git rebase principle (GO)
