Git II Dezentrale Versionsverwaltung im Team
Themenbereiche Arbeit mit Remote Repositories Austausch zwischen Repositories Änderungen rückgängig machen Zusammenarbeit über Workflows
Git hat mehr als nur den Workspace.. Arbeit mit Remote-Repositories
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
Repositories klonen
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)
git remote add <name> <pfad>
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>
Ideen zusammenführen Austausch zwischen Repositories
Austausch zwischen Repositories git pull git fetch git merge git push
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
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
Austausch zwischen Repositories git pull git fetch git merge git push
git merge Fast-Forward- Merge Drei-Wege- Merge
git merge Fast-Forward- Merge Drei-Wege- Merge
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
git merge Fast-Forward- Merge Drei-Wege- Merge
Drei-Wege-Merge Bei auseinander gegangenen Branches Erstellt zur Zusammenführung einen neuen Commit Gut geeignet für längerfristige Features
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
Achtung, Konfliktpotential
Merging-Konflikte
Derweil auf dem Master-Branch
Merging: Konfliktlösung 1. Zweifach bearbeitete Stelle manuell ändern 2. Dokument erneut hinzufügen (git add) 3. Commit abgeben Konflikt gelöst
Austausch zwischen Repositories git pull git fetch git merge git push
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>
Austausch zwischen Repositories git pull git fetch git merge git push
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
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
Änderungen rückgängig machen Checkout, revert, reset,
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>)
git revert
git reset
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
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
Bitbucket Zusammenarbeit über ein zentrales Repository
Zusammenarbeit über Bitbucket Benutzerfreundliche Web- Oberfläche zur Diskussion vorgeschlagener Änderungen vor der Integration in das offizielle Projekt Unser Repository für die Übung: https://bitbucket.org/pp_ruby_20 15_ss/git2-uebungsrepository
Teamarbeit: Ablauf 1. Erstellung eines Features durch einen Entwickler in einem Branch in seinem lokalen Repository
Pull-Request
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
Pull-Request
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
Pull-Request
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
Pull-Request
Workflows
Workflows
Workflows
Quellen Preißel, R.,Stachmann, B., Git- Dezentrale Versionsverwaltung im Team (2012) https://www.atlassian.com/git/tutorials http://www.sitepoint.com/getting-started-git-team-environment/ http://ndpsoftware.com/git-cheatsheet.html http://de.gitready.com/beginner/2009/03/09/remote-trackingbranches.html