git rebase and merge handle conflicts
"TLDR: When there are new modifications to the remote repository and the local repository is not synchronized, continuing to make modifications locally will cause conflicts. Git provides two processing methods: Merge and Rebase. Merge will generate a new submission to summarize the submissions of C and D, but conflicts may occur and need to be resolved manually. Rebase follows linear submission processing, and the history record is cleaner. In terms of usage recommendations, it is safer to use Rebase on personal branches, but be cautious on public branches."
When our remote warehouse has new modifications, but the local warehouse is not synchronized, at this time, if we continue to modify the local warehouse, we cannot submit it to the remote warehouse because a conflict occurs.
Specifically, the submission history of the remote warehouse is A -> B -> C, the submission history of the local warehouse is A->B->D, the C modifications of the remote warehouse are not synchronized to the local, and the local D modifications cannot be submitted to the remote.
(Actually, I modified the README file on the Github website, forgot to synchronize it back to the local warehouse, started writing code, and finally submitted an error)
There are two processing methods at this time, and they will be displayed in two different forms on the git commit.
Merge
Merge will generate a new commit M, which summarizes commit C and commit D. However, commit C and commit D are likely to conflict. In this case, you need to manually handle the conflict.
Implementation steps
git config pull.rebase false
git pull
git status
<<<<<<< HEAD
your modifications
=======
Remote modification
>>>>>>> branch-name
git add .
git commit -m "Resolve merge conflicts"
Then it will be displayed in the form of a fork diagram in the git history diagram:
A -> B -> C -> M (M is a merge commit)
\-> D -> E/
This method retains a complete history record, but the branch history will appear more messy.
Rebase
Rebase is processed according to linear submission, and the history record is very beautiful.
Implementation steps:
git config pull.rebase true
git pull
The final git history is in the form:
A -> B -> C -> D' (linear history)
Usage suggestions
It is safe to use rebase on personal branches
Use rebase with caution on public branches
If you are not sure, you can use the default merge strategy first
It should be noted that if the code has been pushed to the remote, you need to force push (git push -f) after using rebase. This may affect other developers, so be extra careful.