Usually we have 2 method to collobrate.
Both git rebase and git merge are used to obtain from a branch and merge to the current branch, but they adopt different working methods. The following work scenario illustrates the difference.
Scenes:
As shown in the figure: you are developing new features in a feature branch, and at the same time, there are new commits in the master branch.
In order to merge new commits on master to your feature branch, you have two options: mrege or rebase
git merge
Execute the following commands:
git checkout feature
git merge master
Or perform simpler:
git merge master feature
Then git will automatically generate a new commit (merge commit)
look like this on the feature at this time:
- Marge Features: Automatically create a new commit.
If you encounter a conflict during the merge, you only need to modify and re-commit.
- Advantages: Record the real commit status, including the details of each branch.
- Disadvantages: Because each merge will automatically generate a merge commit , So when using some git GUI tools, especially when commits are frequent, I see that the branches are very messy.
git rebase
The essence is rebasing.
rebasing is the find common ancestor.
Execute the following commands:
git checkout feature
git rebase master
look like this:
- Rebase features: will merge the previous commit history.
- Advantages: get a more concise project history, remove merge commit
- Disadvantages: if there is a code problem in the merge , it is not easy to locate, because the history is re-write
If there is a conflict during merging, follow the steps below to resolve
Modify the conflict part
git add
git rebase --continue
(If the third step is invalid, it can be executed git rebase --skip)
Do not habitually execute the git commit command after git add
The Golden Rule of Rebasing rebase
never use it on public branches
For example, the following scenario: as shown in the figure
Now we see what's problem with using rebase on public branches?
If you rebase master to your feature branch:
Rebase moves all master's commits to the top of your feature. The problem is: other people are still developing on the original master. Because you moved the master using rebase, git will think that the history of your master branch is different from that of others and will conflict.
So ask yourself before performing git rebase,
Will anyone else look at this branch?
if YES Do not use this destructive rebase command that modifies the commit history
if NO ok, you can use rebase as you like
Summary
If you want a clean, linear history tree without merge commit, then you should choose git rebase.
If you want to keep a complete history and want to avoid the risk of rewriting commit history, you should choose to use git merge
In your described suitation.
- you are advised to use git rebase on yourself own branch. The other guys obey the same rule.
- When someone do squash commit. donot push -f to master branch.
- When handling master branch, use git merge to obtain commit from someone own branch.
