To Rebase or Not to Rebase: Taming Your Git History
19
To Rebase or Not to Rebase? Taming Your Git History
-
Upload
perforce -
Category
Technology
-
view
476 -
download
0
description
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)
Transcript of To Rebase or Not to Rebase: Taming Your Git History
To Rebase or Not to Rebase?Taming Your Git History
To Rebase or Not to Rebase
John WillistonPerforce Software
To Rebase or Not to Rebase
Agenda
• What is rebasing?• The Git community divided• Should we rebase?
To Rebase or Not to Rebase
What is Rebasing?
To Rebase or Not to Rebase
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
Merging Versus Rebasing
Rebasing• “Macro”
record/playback• Destroys history• Moves both “pointers”
Merging• Three-way process• Preserves history• Changes only target
To Rebase or Not to Rebase
Visually: Before
C1 C2C4
C3
bugfix
master
To Rebase or Not to Rebase
Visually: After
RebasingMerging
C1 C2 C4
C3
C5
bugfix
master
C1 C2 C4 C5
bugfix
master
To Rebase or Not to Rebase
The Git Community Divided
To Rebase or Not to Rebase
Always Merge versus Always Rebase
• Two camps• Both have reasons• Both agree on some problems• Sap team productivity
To Rebase or Not to Rebase
Always Rebase
• Eliminates complicated history• Avoids merge commit “noise”• Avoids “rainbow” branch diagrams• Cleans intermediary commits
To Rebase or Not to Rebase
Always Merge
• Simpler and more familiar• Preserves complete history• Preserves chronological ordering• No hidden problems from pushing
To Rebase or Not to Rebase
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
Should WeRebase?
To Rebase or Not to Rebase
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
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
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
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
