to rebase or not to rebase: taming your git history

Post on 19-May-2015

476 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

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

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

To Rebase or Not to Rebase

THANK YOU!!!John Williston, Ph.D

jwilliston@perforce.com@p4jbw

P4Ideax Forums

top related