8. Merge - Pros & Cons
Pros:
● Simple to use and understand.
● Keeps information about the historical existence of branches.
● Existing commits on the source branch are unchanged and remain valid.
Cons:
● History can become intensively polluted by lots of merge commits.
● Visual charts of your repository can have non-informative branch lines.
12. Rebase
What does rebase do: It cuts off these commits
The commits don’t have any information about their parents
anymore.
13. Rebase
The system then applies them on top of the new branch.
We literally cut of these commits and then apply it on top of
the new branch.
14. Rebase
Why does merge even exists if we found such a nice way
to handle our history?
Our commit IDs changed!
Why?
15. Rebase
...because we have a new parent.
Git thinks of our commits as patches and applies them on
top of the new branch.
Therefore Git processes our commits as new commits.
And again, NEW COMMITS!
17. Rebase - Golden Rule
● Never rebase commits that you have pushed
to a public repository. Only rebase local
branches.
Why?
18. Rebase - Golden Rule
● When you rebase pushed branch, you’re
abandoning existing commits and creating
new ones that are similar but different.
So you will rewrite the history...
20. Rebase - Pros & Cons
Pros:
● Clean and flat history.
● Concise commits covering a logical change (can squash series of commits
into one)
● Reduction of merge commits
● Manipulating single commit is easy (e.g. reverting a commit)
Cons:
● More complex
● Rebasing can be dangerous! Can cause history rewrite if done incorrectly
21. The key of having a clean history
… is to have a “fast forward” effect
23. Rebase - Best Practice
$ git checkout -b security_hole_fix
...fix...fix...fix
$ git commit
$ git rebase master
$ git checkout master
$ git merge security_hole_fix
then you get fast-forward effect
24. Who uses what?
Merge
➔ Atlassian (with GitHub pull requests for code reviews)
➔ Git
Rebase
➔ Guava
25. Rebase
If you are not sure you fully understand rebase
-
Don’t do it…
BUT