Programmieren 2 06 Git-Teamwork und Egit

Transkript

1 Programmieren 2 06 Git-Teamwork und Egit Bachelor Medieninformatik Sommersemester 2015 Dipl.-Inform. Ilse Schmiedecke schmiedecke@beuth-hochschule.de 1

2 Die Bildquelle Die schönen Schemazeichnungen in dieser Lehrheinheit entstammen (Lizensiert unter Creative Common Attribution 2.5 Australia) 2

3 Teamwork: Einrichten des zentralen Repo Mary richtet das RemoteRepository ein: (auf dem Server, z.b. per ssh) git init --bare ourrepo.git Mary clont ourrepo, um ihr eigenes lokales Repo zu haben: git clone es heißt dann lokal "origin" Mary richtet lokal die Verzeichnisstruktur für das Projekt ein (mit leeren Dateien oder.gitignore), committet sie und pusht sie nach ourrepo: git push [origin] Paul clont ourrepo (incl. Verzeichnisstruktur) git clone Bill möchte einen anderen Namen als "origin" git clone git remote rename origin marysrepo 3

4 Teamwork: Zentralisierter Workflow John erzeugt neue Dateien, committet und pusht sie. commit/push Mary arbeitet ebenfalls am Projekt und will nach 2 Commits ihre Änderung pushen Konfliktmeldung commit/push Mary aktualisiert ihr lokales Repo git fetch git rebase Der Pfadkonflikt kann von git aufgelöst werden, Marys Änderungen werden "angehängt" Jetzt kann Mary pushen git push git pull Paul und Bill sollten pullen git pull fetch rebase 4 4

5 Teamwork: Konfliktauflösung Git kennt zwei Konfliktauflösungsprozesse, Rebase und Merge Beide werden im Konfliktfall unterbrochen, der Benutzer editiert seine Datei und committet sie neu, danach wird fortgesetzt. Rebase - Begradigen neuerer Commit-Pfad wird an das Ende des alten angefügt, Commits im neueren werden angepasst. Merge - Vereinheitlichen aus dem gemeinsamen Vorgänger und den Pfadenden wird ein neues Merge-Commit erzeugt und angefügt. Ein konfliktfreies Push wird als Fast-Forward-Push bezeichnet. Es bewirkt ein Rebase direkt auf dem remote Repo. 5 5

6 Teamwork: Feature Branch Workflow Das Team besschließt, dass im remote Repo-Master immer eine lauffähige, getestete Version stehen soll. Für Entwicklungen und Experimente werden Seitenzweige aufgemacht. Erst nach Fertigstellung werden Sie in den Masterzweig eingefügt. 6 6

7 Teamwork: Arbeiten mit Branches Neuen Abzweig von master (lokal) erstellen git branch mybranch Neuen Abzweig von big-feature erstellen git branch mybranch subbranch MyBranch Zwischen Zweigen wechseln: HEAD versetzen, Working Tree aktualisieren git checkout subbranch und zu einem anderen Zweig git checkout little-feature Abzweig erstmals pushen git push -u origin mybranch Abzweig zurückführen (mergen) git checkout master git pull git merge mybranch git push Abzweig löschen git branch d mybranch Es gibt immer einen aktuellen Branch. HEAD zeigt dorthin. Checkout wechselt zwischen Branches. Auch Push und Pull beziehen sich auf den aktuellen Branch; deshalb erst zum Master wechseln und dann mit Pull den aktuellen Master-Stand von Remote holen. 7

8 Teamwork: Feature Branch Workflow Mary beginnt mit einem neuen Feature und legt dafür (lokal) einen Branch an, der von Master abzweigt: git branch marys-feature master git checkout marys-feature oder kurz: git checkout b marys-feature master Vor dem Mittagessen pusht sie ihren Entwicklungszweig. Mit u und dem Zweignamen wird er beim ersten Push remote erzeugt. Danach genügt git push. git push -u origin marys-feature Am Abend ist sie fertig und pusht das Ergebnis. Sie bittet Paul und Bill, draufzusehen und es freizugeben. Man nennt das einen Pull Request (von git unterstützt). Wenn alle einverstanden sind, fügt sie das Ergebnis in den Masterzweig ein und löscht ihren Zweig. git checkout master git pull git merge marys-feature //oder pull git push git branch d marys-feature //optional 8 8

9 Teamwork Zusammenfassung Git heißt "Doofie" und will für Doofies sein... Aber: wenn man Git verstanden hat, dann hat man ein stabiles Sicherheitsnetz Der Feature-Branch-Workflow eignet sich perfekt für Einzelpersonen und kleine Teams Der Rest ist Disziplin

10 Git aus Eclipse : Egit Alle IDEs bieten die Möglichkeit der Versionsverwaltung Typischerweise integriert unter dem Stichwort "Team" Eclipse hat standardmäßig Plugin für SVN (subversive) und Git (EGit) Vorteil: Versionsverwaltung direkt integriert in die Projektverwaltung der IDE Bruchloses Arbeiten 10 10

11 Workflow in Egit Projekt anlegen An ein lokales Repo binden (ggf. neu erzeugen) Jede Änderung wird als "unstaged" oder "dirty" gekennzeichnet Staging über Teammenü, Tool oder Staging View Commit über Teammenü, Tool oder Staging View Remote Repo einrichten oder Clonen in der Repositories View Push, pull, fetch über Teammenü, Tool oder Repositories View Merge, rebase über Tool, Repositories View oder History View Branch und checkout (switch) über Repositories View oder History View Reset über Teammenü oder Commit Viewer Revert über Commit Viewer 11 11

12 Lokales Repository einrichten Team > Share > Git lokales Repo für Projekt einrichten: 12

13 Nützliche Git-Sichten Unter Window > Show View > Other > Git finden sich sehr nützliche Sichten, z.b. Git Staging Git Repositories Git Interactive Rebase 13

14 Erstes Commit aus der Staging View Commit Message eintragen! Staging per D&D 14

15 Statusanzeige im PackageExplorer Quelle: vogella.com/tutorials/eclipsegit/article.html 15

16 Commit-History Wird in der History View angezeigt nach Project > Show In > History Filter- und Suchmöglichkeiten 16

17 Details über ein Commit In der History View Rechtsklick > Open in Commit Viewer 17

18 Commits in allen Repos Navigate > Open Git Commit 18 18

19 Repositories-View Einrichten, Verwalten und Überblick für Repositories Lokale Repos Branching Zuordnung von Remotes Konfiguration von Remotes 19

20 ... genug ge-gittet. Nächstes Mal wird wieder programmiert 20 20