rebase
Suppose you now create a branch called "mywork" based on the remote branch "origin".
$ git checkout -b mywork origin
Now we make some changes in this branch and make two commits, C5, C6.
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...
But at the same time, someone else also made some changes on the "origin" branch and made commits (C3, C4). This means that the two branches "origin" and "mywork" are "forward" respectively, they "forked" between.
Here, you can use the "pull" command to pull the changes on the "origin" branch and merge them with yours; the result will look like a new "merge commit":
However, if you want to make the "mywork" branch history look like it hasn't gone through any merges, you might be able to git rebase :
$ git checkout mywork
$ git rebase origin
These commands will undo every commit in your "mywork" branch and temporarily save them as patches ( the patches are placed in the ".git/rebase" directory), then put "mywork" "The branch is updated to the latest "origin" branch, and finally the saved patches (C5' , C6') are applied to the "mywork" branch.
When the 'mywork' branch is updated, it will point to these newly created commits, and those old commits will be discarded. These discarded commits are deleted if you run pruning garbage collection. (See git gc )
Now we can look at the difference between the history produced with merge and with rebase :
During the rebase process, conflicts may arise. In this case, Git will stop the rebase and let you resolve the conflicts; after resolving the conflicts, use the "git-add" command to update the index of these contents (index), then, you don't need to do git-commit, just do:
$ git rebase --continue
This way git will continue to apply the remaining patches.
At any time, you can --abortterminate the rebase action with an argument, and the "mywork" branch will revert to the state it was in before the rebase started.
$ git rebase --abort