Git Logo

Branching

Verwendete Sprache

Kein korrektes Deutsch bzw. Englisch zur besseren Wiedererkennung der Git Befehle

"gemerged"
"committed"

Warum & wozu?

  • Produktive, funktionierende Version gewährleisten
  • Dinge ausprobieren, ohne den vorhandenen Code zu gefährden
  • Einzelne Features bzw. Programmteile im Entwicklungsprozess isolieren
  • ...

Branches benennen

  • Darf kein ASCII Steuerzeichen enthalten
  • Keines der folgenden Zeichen darf vorkommen: Leerzeichen, Tilde (~), Caret (^), Doppelpunkt, Fragezeichen, Asterisk (*), Öffnende eckige Klammer ([)
  • Darf kein Backslash enthalten

Vollständige Liste: git-check-ref-format Manual Page

  • Nutzerverwaltung
  • ValidierungBeiPasswortAenderung
  • 103279
  • HochgeladeneDateiMaximal5MB
  • GesperrterNutzerWirdNichtNach5MinutenEntsperrt

Besser

  • Kurze und prägnante Namen
  • Hierarchische Bezeichnungen
  • Keine bloße Zahl
  • CamelCase vermeiden, Wörter mit Minus trennen
  • feature/nutzerverwaltung
  • bugfix/validiere-passwort
  • release/v1.0.0
  • junk/ovale-buttons

Warum den Slash als Hierarchie-Trenner?

  • Git behandelt die Hierarchie als Verzeichnisse
  • Auto Complete in der Bash ist schneller
  • Versch. grafische Tools (bspw. SourceTree) stellen die Branches ebenfalls als Ordner dar

Alles nur Best Practices, wenn es einem gar nicht zusagt, kann man es auch komplett anders machen

Mit Branches arbeiten

$ git checkout master
$ git checkout -b develop master

Fast-Forward vs. Recursive Merge

Rebasing

Synchronisation

  • Vermeiden von umfangreichem Merge am Ende
  • Bei veröffentlichtem Branch niemals rebasen!
  • $ git checkout feature/user-mgmt
$ git merge develop

Änderungen vom zentralen Repo integrieren

  • Kein pull verwenden
  • Erst fetchen ( git fetch -p)
  • Anschließend mergen ( git merge --ff-only)
    • Bei Fehlschlag (Fast-Forward nicht möglich): git rebase
    • Bei Merge-Konflikten: git mergetool
      • Anschließend git rebase --continue aufrufen

Git Cheatsheet

Auf Github öffnen

Git Flow

  • master
  • develop
  • feature
  • release
  • hotfix

master

  • Entspricht immer dem produktiven Stand
  • Auf master findet nur ein merge statt, kein commit
  • Jeder commit ist mit einem Tag versehen, der die Versionsnummer enthält
  • Existiert immer in dem Repository, wird nie gelöscht

develop

  • Entspricht dem aktuellen Entwicklungsstand für das nächste Release
  • Bei stabilen Stand wird dieser nach master gemerged
  • Existiert ebenfalls immer in dem Repository

feature

  • Von wo gebranched: develop
  • Wohin gemerged: develop
  • Name: feature/...
  • Existiert nur solange, wie an dem Feature gearbeitet wird
  • Ist das Feature fertig, wird es nach develop gemerged und anschließend gelöscht
  • Wird das Feature verworfen, wird der Branch gelöscht ohne ihn zu mergen

Feature Branch erzeugen

$ git checkout -b feature/f1 develop

Feature Branch zurück mergen und pushen

$ git checkout develop
$ git merge --no-ff feature/f1
$ git push origin develop

Branch lokal & ggf. remote löschen

$ git branch -d feature/f1
$ git push origin :feature/f1

release

  • Von wo gebranched: develop
  • Wohin gemerged: develop & master
  • Name: release/...
  • Dient der Vorbereitung eines Releases
  • Kann kleine Bugfixes und sonstige Release-Vorbereitungen enthalten
  • Wird nach dem mergen in master und develop gelöscht

Release Branch erzeugen

$ git checkout -b release/v1.2.0 develop

Release Branch nach master mergen und taggen

$ git checkout master
$ git merge --no-ff release/v1.2.0
$ git tag -a v1.2.0

Ebenfalls nach develop mergen

$ git checkout develop
$ git merge --no-ff release/v1.2.0

Branch lokal & ggf. remote löschen

$ git branch -d release/v1.2.0
$ git push origin :release/v1.2.0

hotfix

  • Von wo gebranched: master
  • Wohin gemerged: develop & master
  • Name: hotfix/...
  • Für kritische Bugfixes in der Live-Umgebung (master)
  • Fehlerbehebung unabhängig vom aktuellen Entwicklungsstand
  • Existiert nur solange, wie an dem Bugfix gearbeitet wird

Hotfix Branch erzeugen

$ git checkout -b hotfix/v1.2.1 master

Hotfix Branch zurück mergen und taggen

$ git checkout master
$ git merge --no-ff hotfix/v1.2.1
$ git tag -a v1.2.1

Ebenfalls nach develop mergen

$ git checkout develop
$ git merge --no-ff hotfix/v1.2.1

→ Ist gerade ein Release im Gange, sollte der Hotfix Branch stattdessen in diesen Release-Branch gemerged werden

Branch lokal & ggf. remote löschen

$ git branch -d hotfix/v1.2.1
$ git push origin :hotfix/v1.2.1
↗ Git Flow Übersicht (PDF)

Learning by doing...

Aufgabe

Erstellen einer Datei mit sechs Dingen, jedes repräsentiert dabei ein Feature

$ git init
$ touch things.txt

things.txt:

Version: v0.1.0

Six impossible things before breakfast:
1. There's a potion that can make you shrink.
$ git add things.txt
$ git commit -m init
git checkout -b develop

Neues Feature: thing2 

2. And a cake that can make you grow.

Neues Feature: thing3 

3. Animals can tak.

Release erzeugen: v0.2.0

Versionsnummer anpassen (erst auf dem Release-Branch!) und releasen

Neues Feature: thing4 

4. Cats can disappear.

Hotfix: v0.2.1

tak in talk ändern

Versionsnummer anpassen

Neues Feature: thing5 

5. There is a place called Wonderland.

Neues Feature: thing6 

6. I can slay the Jabberwocky.

Release erzeugen: v1.0.0

Versionsnummer anpassen und releasen

Fertige Datei:

Version: v1.0.0
Six impossible things before breakfast:
1. There's a potion that can make you shrink.
2. And a cake that can make you grow.
3. Animals can talk.
4. Cats can disappear.
5. There is a place called Wonderland.
6. I can slay the Jabberwocky.

Fragen? Fragen!