Besser leben durch Rebasing - OIO...• Szenario: Rebase „feature-2“ auf „master“und nach „master“ mergen • Aber diesmal existiert auch ein Remote Repository (origin)

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

Besser leben durch Rebasing

Geschönte Entwicklungshistorie leicht gemacht dank Git

1.4

Besser leben durch Rebasing© Orientation in Objects GmbH

Daemonic Disclaimer

• Kein Vortrag über Sinn von Branching und „Daemonic CI“– Siehe hierzu Vortrag „Integrierst du schon oder branchst du noch?“

• Kerngedanke ist grundsätzlich „the mainline stays in a healthy state“– Ratio: „[Don‘t] pick random […] points for development to begin with.”

• „Branches“ bedeutet im Folgenden „Feature Branches“– „temporary branch created to work on a complex change without

interfering with the stability of [the mainline]“

• Es gibt keine Allheilmittel aber viele „Branching Anti-Patterns”– Cascading Branches, Mysterious Branches, Merge Mania, …

2

2


Gliederung

• Merging 101

• Merging in practice

• Merging vs. Rebasing

• May the Force be with you

• Zusammenfassung

3


Gliederung

• Merging 101




• Zusammenfassung

4

3


Kanten und Knoten

• Commit ist fixierter Zustand des Dateibaums mit Metadaten

• Commits stehen zu ihren Vorgängern in Eltern-Kind Beziehung

• Gerichteter azyklischer Graph

5

A

B

C

D


What Is Thy Bidding My Master?

6

A

B master

4


Branch erzeugen

7

A

B master

feature-1


Im Branch entwickeln

8

A

B master

feature-1C

5


Master verändert sich ebenfalls

9

A

B

masterfeature-1 C D


Merge ausführen – Diamonds Are Forever

10

A

B

master

feature-1 C D

E

6


Merge ausführen – Network

11

A

B

master

feature-1

C

D

E


Im Branch entwickeln, again

12

A

B master

C

feature-1D

7


Merge ausführen – Vorspulen

13

A

B

master

C

feature-1

D


Merge ausführen – Vorspulen, oder nicht?

14

A

B

master

C

feature-1

D

A

B

C

feature-1D

masterE

8


Gliederung

• Merging 101




• Zusammenfassung

15


Get the party started

• Ausgangssituation zwei „parallel“ entwickelte Branches

• Was ist wirklich wichtiger: Struktur oder Zeitstempel?

16

9


Let‘s get together (again)

• Zurück mergen von Branch „feature-1“nach „master“

• „Fast-forward“ verrauscht einen Teil der Entstehungsgeschichte

17


Let‘s merge again (and again)

• Branch „feature-2“ soll auch zurück nach „master“– „master“ hat sich seit dem Abzweigen von „feature-2“ verändert

• Aktuellen „master“ nach „feature-2“ mergen und dann wieder zurück– Eventuell automatisiert durch „Branch Updater“ im CI Server

18

10


The beat goes on

• Branch „feature-1“ war aber noch gar nicht ganz fertig– Es wurden nur fertige Teilergebnisse nach „master“ gemergt

• Nacharbeit „feature-1“, Merge „master“ nach „feature-1“ und zurück– Sortierung hilft auch nur noch bedingt

19


• Branch „feature-2“ war übrigens auch noch nicht fertig

• Nacharbeit „feature-2“, Merge „master“ nach „feature-2“ und zurück– Im Ergebnis 8 „echte“ Commits bei 7 reinen Merge Commis

… and on

20

11


We don't need a guitar man, son

21

(Quelle: https://twitter.com/henryhoffman/status/694184106440200192)


Gliederung

• Merging 101




• Zusammenfassung

22

12


Been there, done that

• Merge Commits vereinen auseinanderlaufende Zweige

• Aus Sicht von „master“ erfolgen Änderungen aber nacheinander

23

A

B

masterfeature-1 C D

A

B

master

feature-1 C D

E


Alte Zöpfe abschneiden

• Zweige können auch mittels Rebase „verpflanzt“ werden

• Es entstehen neue Commits und alte „verschwinden“

24

A

B

masterfeature-1 C D

C‘

A

B

master

feature-1

C D

C‘

13


Based rebasing (1)

• Szenario wie zuvor: „feature-2“ soll auch zurück nach „master“

• „master“ nach „feature-2“ mergen, aber dann…

• „feature-2“ nicht zurück nach „master“ mergen sondern rebasen

25


Based rebasing (2)

• Abschließend „feature-2“ nach „master“ mergen– „Fast-forward“ Merge möglich aber nicht wünschenswert

• Commit Historie leicht lesbar und „echt“ aus Sicht von „master“

26

14


All your base are belong to us

• Szenario wie zuvor: Nacharbeiten in „feature-1“ werden ausgeführt

• „feature-1“ auf „master“ rebasen und nach „master“ mergen– „master“ kann zuvor seinerseits nach „feature-1“ gemergt worden sein

27


All good things come in t(h)rees

• Nacharbeiten in „feature-2“ werden ausgeführt

• „feature-2“ auf „master“ rebasen und nach „master“ mergen– „master“ ist zuvor wieder nach „feature-2“ gemergt worden

28

15


Final showdown

• Rebase basierter Ansatz ist lesbarer und hat besseres SNR– 7 versus 4 Merge Commis bei 8 „echten“ Commits

29


While we're at it

• Wenn neue Commits erzeugt werden, dann gleich ordentlich– Commit „Geschichte“, die man auch später noch versteht

• Interactive Rebasing erlaubt diverse Aufräumarbeiten– Changing Multiple Commit Messages– Reordering Commits– Squashing Commits– Splitting a Commit

30

16


All’s well that ends well

• Branch Commits als Teil der Dokumentation

• Roter Faden für Leser der Änderungen dieses Branches

31


Gliederung

• Merging 101




• Zusammenfassung

32

17


Golden rule of rebasing

• „The golden rule of git rebase is to never use it on public branches.“– Wahlweise auch: „pushed“, „shared“ oder „pulled from elsewhere“

• Public Branches sind de facto Standard– Toolchains, Remote Repos für Backup, Transparenz im Team

• Was bedeutet das nun?

33


Rebasing mit Remote Repos

• Szenario: Rebase „feature-2“ auf „master“und nach „master“ mergen

• Aber diesmal existiert auch ein Remote Repository (origin)– Kein Fast-forward von Remote Referenz auf lokale mehr möglich– Remote Referenz ist kein Vorfahre der neuen lokalen Referenz

34

18


Use the Force

• Push wird verweigert, wenn Remote Referenz kein Vorfahre ist– Default Verhalten da Remote Repo Commits „verlieren“ könnte

• Push kann durch „--force“ Option erzwungen werden

35


Und bist Du nicht willig, so brauch‘ ich Gewalt

• Nach Force Push noch Merge von „feature-2“ auf „master“– Abschließend erneuter Push (ohne Force) in das Remote Repository

36

19


Und was sieht der Rest der Welt?

• Andere Entwickler müssen Rebasing in ihre Repos übernehmen– Entweder Pull mit „--rebase“ Option oder über Reset Kommando

37


Die Welt dreht sich vielleicht auch ohne uns weiter

• Und wenn „heimlich“ an zu rebasendem Branch gearbeitet wurde?– Force Push würde zum Verlust dieser Commits führen

38

20


Gewalt ist nicht die einzige Lösung

• Push besitzt auch eine „--force-with-lease” Option– „[--force] sibling that partially protects against damaging forced updates”

• Vorsicht wenn im Hintergrund Fetch ausgeführt wird (siehe Doku)

39


The use of unnecessary force has been approved

• Und falls jemand doch Commits mit „--force“ entfernt?– Szenario: Force Push hat Commits im Remote Repo entfernt

40

21


Not all those who wander are lost

• Verlorene Commits in lokalen Branch überführen und dort arbeiten

• Bei Bedarf verlorene Commits mittels Reflog wiederfinden– Sollte nie Bestandteil des normalen Workflows sein

41


Gliederung

• Merging 101




• Zusammenfassung

42

22


There ain't no such thing as a free lunch

• Vorteile sowohl bei Merging als auch Rebasing Workflows– Merge: verständlich(er), Erhalt zeitlicher Ablauf, keine „Push“ Probleme– Rebase: keine „Regenbogen“ Historie, Möglichkeit Commits zu „putzen“

• Für Rebasing sind vorab diverse Fragen zu klären– Ist schöne Historie oder zeitlicher Ablauf „first-order“ Arbeitsergebnis?– Ist schöne Historie Mühen und möglichen Risiken wert?– Wie groß ist git Kompetenz im Team?– Gibt es Branching Policies, die alle kennen, verstehen und befolgen?– Werden die Branching Policies durch Tools unterstützt?– Gibt es ein gemeinsames Verständnis von Public Branches?

• My two cent: Funktioniert gut mit Feature Branches in Scrum Teams– Scrum Feature Branches sind kurzlebig mit beschränkter Bearbeiterzahl

43


A fool with a tool is still a fool

• Git Hosting Tools unterstützen zum Teil auch Rebasing Workflows– Etwa Bitbucket Server bei Pull Requests und Merge Strategies

44

23


“Anybody can make history; only a great man can write it.” (Oscar Wilde)

• Geschönte Entwicklungshistorie ist nicht gratis

• Aber vielleicht für Sie persönlich ihren Preis wert

45


If you remember one thing

46

„Practicality beats purity”

(The Zen of Python, Tim Peters)

24


Links (1)

• Continuous Integration Certification– https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

• Continuous Lifecycle 2016 Vortrag „Integrierst du schon oder branchst du noch? – Müssen sich Features Branches und CI widersprechen“– https://www.oio.de/public/presentations

• Continuous Integration– https://martinfowler.com/articles/continuousIntegration.html

• Linus Torvalds auf Linux Kernel Mailing Liste am 28.09.2010 – https://lkml.org/lkml/2010/9/28/362

47


Links (2)

• Version Control with Subversion– http://svnbook.red-bean.com/en/1.7/svn-book.html

• Software Branching and Parallel Universes– https://blog.codinghorror.com/software-branching-and-parallel-

universes/

• Merging vs. Rebasing | Atlassian Git Tutorial– https://www.atlassian.com/git/tutorials/merging-vs-rebasing

• ‘--force’ considered harmful; understanding git's ‘--force-with-lease’– https://developer.atlassian.com/blog/2015/04/force-with-lease/

• Bitbucket Server 5.5 release notes– https://confluence.atlassian.com/bitbucketserver/bitbucket-server-5-5-

release-notes-938037662.html

48

25



[email protected]

??

? ?

????

Fragen ?

49



[email protected]

Vielen Dank für Ihre Aufmerksamkeit !

Documents

Besser leben durch Rebasing - OIO...• Szenario: Rebase „feature-2“ auf „master“und nach „master“ mergen • Aber diesmal existiert auch ein Remote Repository (origin)