Rebasing is a contentious issue in the Git community. Advocates consider it essential to remove pesky, intermediate commits, while opponents cry foul at its tendency toward overuse, and destruction of history. This DevTalk presents both sides of the issue and suggests a re-thinking of history itself as a first-order work product. Hear John Williston, technical product manager and git expert, discuss: -What rebasing is and how it typically comes into play -The unpleasant side effects of its overuse -A better way to look at it (as a tool for making history a first-order work product)

1. To Rebase or
Not to Rebase?
Taming Your Git History

2. John Williston
Perforce Software
To Rebase or Not to Rebase

3. Agenda
• What is rebasing?
• The Git community divided
• Should we rebase?
To Rebase or Not to Rebase

4. What is
Rebasing?
To Rebase or Not to Rebase

5. What Rebasing Is
• Let’s start with what it isn’t: merging
• Rebasing is more like a “macro”
• And flattens history in the process
To Rebase or Not to Rebase

6. Merging Versus Rebasing
To Rebase or Not to Rebase
Rebasing
• “Macro”
record/playback
• Destroys history
• Moves both “pointers”
Merging
• Three-way process
• Preserves history
• Changes only target

7. Visually: Before
C1 C2
To Rebase or Not to Rebase
master
C4
C3
bugfix

8. Visually: After
Merging Rebasing
C1 C2 C4
C3
master
C5
bugfix
To Rebase or Not to Rebase
master
C1 C2 C4 C5
bugfix

9. The Git
Community Divided
To Rebase or Not to Rebase

10. Always Merge versus Always Rebase
• Two camps
• Both have reasons
• Both agree on some problems
• Sap team productivity
To Rebase or Not to Rebase

11. Always Rebase
• Eliminates complicated history
• Avoids merge commit “noise”
• Avoids “rainbow” branch diagrams
• Cleans intermediary commits
To Rebase or Not to Rebase

12. Always Merge
• Simpler and more familiar
• Preserves complete history
• Preserves chronological ordering
• No hidden problems from pushing
To Rebase or Not to Rebase

13. Key Observations
• History is a first-order work product
• Merge-commit “noise” drowns out “signal”
• Rebasing privately affects only the individual
• Rebasing publicly affects others
To Rebase or Not to Rebase

14. Should We
Rebase?
To Rebase or Not to Rebase

15. Initial Conclusions
• Neither extreme is necessary
• Rebase simplicity ends where teams begin
• Individuals aren’t teams
• Team policy remains essential
To Rebase or Not to Rebase

16. Individual Recommendations
• Branch for every unit of work
• Branch again as you like
• Commit as often as you like
• Clean up your history prior to review
• Stick to merge when dealing with others
To Rebase or Not to Rebase

17. Team Questions
• What is your team’s rebase competence?
• What is your organization’s Git competence?
• Which do you value more, simplicity or
traceability?
• Does your branching strategy fit?
To Rebase or Not to Rebase

18. Final Conclusions
• Rebase is a little like fire
• It streamlines and clarifies history, at a cost
• Competent individuals should freely use it
• Teams should be sure it fits
• Organizations need branching strategies
To Rebase or Not to Rebase

19. THANK YOU!!!
John Williston, Ph.D
jwilliston@perforce.com
@p4jbw
To Rebase or Not to Rebase
P4Ideax Forums