So we went back in history before the first merge and wanna relocate the changes in master to our style branch.
This time we are going to use the rebase command rather than merge.
RUN:
git checkout style
git rebase master
git hist
RESULT:
$ git checkout style
Switched to branch 'style'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Added css stylesheet
Applying: Hello uses style.css
Applying: Updated index.html
$ git hist
* 6e6c76a 2020-01-09 | Updated index.html (HEAD, style) [kwikl3arn]
* 1436f13 2020-01-09 | Hello uses style.css [kwikl3arn]
* 59da9a7 2020-01-09 | Added css stylesheet [kwikl3arn]
* 6c0f848 2020-01-09 | Added README (master) [kwikl3arn]
* 8029c07 2020-01-09 | Added index.html. [kwikl3arn]
* 567948a 2020-01-09 | Moved hello.html to lib [kwikl3arn]
* 6a78635 2020-01-09 | Add an author/email comment [kwikl3arn]
* fa3c141 2020-01-09 | Added HTML header (v1) [kwikl3arn]
* 8c32287 2020-01-09 | Added standard HTML page tags (v1-beta) [kwikl3arn]
* 43628f7 2020-01-09 | Added h1 tag [kwikl3arn]
* 911e8c9 2020-01-09 | First Commit [kwikl3arn]
Step1:Merging VS rebasing
The result of the rebase command looks much like that of the merge command. The style branch currently contains all its changes, plus all the changes of the master branch. The commit tree, however, is a bit different. The style branch commit tree has been rewritten to make the master branch a part of the commit history. This makes the chain of commits linear and more readable.
Step2:When to use the rebase command, and when the merge command?
Don’t use the rebase command …
If the branch is public and shared. Rewriting such branches will hinder the work of other team members.
When the exact commit branch history is important (because the rebase command rewrites the history of commits).
Given the above recommendations, I prefer to use rebase for short-term, local branches and the merge command for branches in the public repository.
