We will follow the same steps below and see how rebase makes the git history different:
1. add file_01 on master
2. make feature-branch-01, add file_02
3. add file_03 on master
4. make feature-branch-02, add file_04
Experiment One:
merge feature-branch-01 into master
merge feature-branch-02 into master
We will see the git history graph as below:
Experiment Two:
merge feature-branch-01 into master
rebase feature-branch-02 into master
merge feature-branch-02 into master
Git history graph looks like this:
When we say 'rebase', 'base' is the place in master/develop where the feature branch is created from. Look at Experiment One, the base of feature-branch-02 is the second last commit, while in Experiment Two, we've moved the base to the latest master via rebasing. In other words, rebasing is Like TEMPORARILY removing all the changes from feature-branch, recreating the feature-branch from latest master/develop and then re-adding the changes back to feature-branch.
The major benefit of rebase before merge is we will have a cleaner git history without two lines intersect with each other. As the developer working on feature-branch, daily rebasing allows us sync with develop branch and be aware of the conflicts might happen earlier before the day we merge.
How to rebase?
In source tree, stay at feature branch, right click develop branch and choose 'rebase current changes onto master'. Solve any conflicts and commit.
Force push will be required if you push to remote repository. SourceTree -> Preference -> General -> Allow force push
Further reading:
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
No comments:
Post a Comment