Git II. Dezentrale Versionsverwaltung im Team

Transkript

1 Git II Dezentrale Versionsverwaltung im Team

2 Themenbereiche Arbeit mit Remote Repositories Austausch zwischen Repositories Änderungen rückgängig machen Zusammenarbeit über Workflows

3 Git hat mehr als nur den Workspace.. Arbeit mit Remote-Repositories

4 Repositories klonen Projektserver hat zentrales Repository Jeder Entwickler braucht mindestens einen eigenen Klon Klonen dient auch für unabhängige Entwicklungen mit anderer Richtung (Fork) Als Backup für das Hauptrepository Wichtige Befehle: git clone <pfad> Hinweise

5 Repositories klonen

6 git remote add <name> <pfad> Nützlich, wenn man häufig auf einen Klon zugreift Weist einem geklonten Repository einen Kurznamen zu Bei Befehlen muss dann nicht mehr die Repo-URL benutzt werden Kann gelöscht werden durch: git remote rm <kurzname> Original-Repository trägt den Namen origin Auflistung der Verknüpfung über: git remote --verbose (git remote v)

7 git remote add <name> <pfad>

8 Tracking branches = Lokaler Branch der einen remote branch verfolgt verbinden lokale Arbeit mit der Arbeit in einem entfernten Repository wissen automatisch, von welchem entfernten Branch Änderungen heruntergeladen werden müssen, wenn git pull oder git fetch verwendet werden. git status erkennt, wieviele Commits die aktuelle Arbeit der entfernten Version des Branches voraus ist. git branch --track <NeuerBranchname> <remote>

9 Ideen zusammenführen Austausch zwischen Repositories

10 Austausch zwischen Repositories git pull git fetch git merge git push

11 git fetch Importiert Commits aus einem Remote-Repository in das eigene lokale Repo Die entstehenden Commits werden als Remote-Branches abgespeichert hat absolut keinen Effekt auf lokale Entwicklungsarbeit Sicherer Weg, Commits zu betrachten Ermöglicht, die Änderungen vor der Integration in den eigenen Workspace zu überprüfen Dient dazu, die Arbeit der anderen Entwckler zu begutachten

12 git fetch git fetch <remote> holt alle branches aus dem remote (inkl. aller Commits und Dateien) git fetch <remote> <branch> holt alle Commits und Dateien eines bestimmten branch

13 Austausch zwischen Repositories git pull git fetch git merge git push

14 git merge Fast-Forward- Merge Drei-Wege- Merge

15 git merge Fast-Forward- Merge Drei-Wege- Merge

16 Fast-Forward-Merge Benötigt linearen Pfand von aktuellem Branch zu Zielbranch Bewegt einfach den Zeiger von der masterbranch zur featurebranch Für kleinere Änderungen z.b. Bugfixes

17 git merge Fast-Forward- Merge Drei-Wege- Merge

18 Drei-Wege-Merge Bei auseinander gegangenen Branches Erstellt zur Zusammenführung einen neuen Commit Gut geeignet für längerfristige Features

19 Drei-Wege-Merge 1. Entwickler beginnt ein neues Feature in einem neuen Branch 2. Bearbeitung von Dateien in dem Branch 3. Auch im master-branch wird entwickelt 4. Schließlich wird das Feature in die master-branch übernommen und der Feature-branch gelöscht

20 Achtung, Konfliktpotential

21 Merging-Konflikte

22 Derweil auf dem Master-Branch

23 Merging: Konfliktlösung 1. Zweifach bearbeitete Stelle manuell ändern 2. Dokument erneut hinzufügen (git add) 3. Commit abgeben Konflikt gelöst

24 Austausch zwischen Repositories git pull git fetch git merge git push

25 git pull Abkürzung für git fetch - git merge Abfolge Einfacher Weg sein lokales Repository mit dem Upstream Repository zu synchronisieren git fetch <remote> git merge origin/<current-branch> git pull <remote>

26 Austausch zwischen Repositories git pull git fetch git merge git push

27 git push Gegenstück zu git pull überträgt Commits: lokal remote hat Potenzial, Änderungen zu überschreiben: VORSICHT! möglichst nur in Bare-Repositories pushen gebräuchlichste Verwendung: Veröffentlichung der eigenen lokalen Änderungen in einem zentralen Repository

28 git push git push <remote> <branch> schiebt den entsprechenden Branch und alle notwendigen Commits und Objekte auf das remote, wo eine lokale branch erstellt wird git push <remote> --force funktioniert selbst dann, wenn daraus ein non-forward-merging folgt (nur benutzen, wenn man absolut sicher ist, was man tut) git push <remote> --all schiebt alle branches auf das remote

29 Änderungen rückgängig machen Checkout, revert, reset,

30 Revert vs. Reset Macht gespeicherte (commited) Änderungen rückgängig Löscht Commit nicht, sondern erstellt einen neuen, bei dem die Änderungen rückgängig gemacht wurden Revidiert einen einzigen Commit (setzt nicht auf Stand zurück) bewahrt git davor, einen Teil der Historie zu verlieren git revert <commit> Macht nicht gespeicherte (uncommited) Änderungen rückgängig permantente Revision (keine Möglichkeit, danach auf das Original noch zuzugreifen) sollte immer nur bei lokalen Änderungen angewandt werden git reset git reset <file> git reset --hard (<commit>)

31 git revert

32 git reset

33 Vergleich git revert gut geeignet, wenn ein Fehler nur durch einen einzigen Commit entstanden ist sichere Variante, da es die Historie nicht ändert kann gezielt einen individuellen Commit auswählen für public history gedacht git reset arbeitet vom aktuellen Commit an rückwärts Rückgängigmachen eines früheren Commits beinhaltet das Verlorengehen aller darauffolgenden Commits ohne --hard ein guter Weg das Repository zu säubern --hard ist hilfreich wenn ein Experiment total schief gelaufen ist

34 Reset Revert Checkout Kommando Ebene Gewöhnliche Nutzungsweise git reset Commit Datei Commits in privaten branches verwerfen oder uncommitted changes wegwerfen Eine Datei aus dem Staging-Bereich wiederherausholen git revert Commit Datei / Commits in einem öffentlichen Zweig rückgängig machen git checkout Commit Datei Zwischen branches wechseln oder alte Zustände betrachten Änderungen im Arbeitsverzeichnis verwerfen

35 Bitbucket Zusammenarbeit über ein zentrales Repository

36 Zusammenarbeit über Bitbucket Benutzerfreundliche Web- Oberfläche zur Diskussion vorgeschlagener Änderungen vor der Integration in das offizielle Projekt Unser Repository für die Übung: 15_ss/git2-uebungsrepository

37 Teamarbeit: Ablauf 1. Erstellung eines Features durch einen Entwickler in einem Branch in seinem lokalen Repository

38 Pull-Request

39 Teamarbeit: Ablauf 1. Erstellung eines Features durch einen Entwickler in einem Branch in seinem lokalen Repository 2. Veröffentlichung der Branch auf einem öffentlichen Repository mittels PUSH-Befehl

40 Pull-Request

41 Teamarbeit: Ablauf 1. Erstellung eines Features durch einen Entwickler in einem Branch in seinem lokalen Repository 2. Veröffentlichung der Branch auf in einem öffentlichen Repository mittels PUSH-Befehl 3. Pull-Request durch den Entwickler via Bitbucket 4. Die anderen Teammitglieder reviewen den Code, diskutieren und verändern ihn

42 Pull-Request

43 Teamarbeit: Ablauf 1. Erstellung eines Features durch einen Entwickler in einem Branch in seinem lokalen Repository 2. Veröffentlichung der Branch auf in einem öffentlichen Repository mittels PUSH-Befehl 3. Pull-Request durch den Entwickler via Bitbucket 4. Die anderen Teammitglieder überprüfen den Code, diskutieren und verändern ihn 5. Ein Projektverwalter führt das Feature mit dem Inhalt des offiziellen Repository zusammen mittels MERGE-Befehl und schließt den Pull-Request

44 Pull-Request

45 Workflows

46 Workflows

47 Workflows

48 Quellen Preißel, R.,Stachmann, B., Git- Dezentrale Versionsverwaltung im Team (2012)