Das Dokument ist noch in der Entwicklung also nicht endgültig!

Transkript

1 Hochschule für Angewandte Wissenschaften Hamburg University of Applied Sciences Hamburg Fakultät Technik und Informatik Department Informatik Technische Informatik GIT on USB(-stick) WS15/16 Das Dokument ist noch in der Entwicklung also nicht endgültig! Beispiele für den GIT-Flow: Wie erinnern uns an unser Beispielteam S9T8 aus der GIT-Motivation. Gehen wir im Weiteren davon aus, dass BE bereits das Repository "Test" auf BitBucket.org angelegt hat und MO bereits die Schreibrechte gegeben hat. BE startet Eclipse und legt ein neues Java-Projekt "Test" an. BE startet nun die GIT-bash und wechselt an die "geeignete Stelle" (d.h. in das konkrete Java-Projekt im Eclipse-Workspace; also " /Test"). cd geeignete Stelle legt eine Datei ".gitignore" mit folgendem Inhalt an bin/ um Binary Files (Byte Code für die JVM) auszuschließen.ds_store wegen/für Mac OS.gitignore diskutierbar initialisiert GIT git init setzt "remote origin" git remote add origin oder alternativ git remote add origin schreibt "readme.md" (eine einzeilige Kurzbeschreibung des Projekts) echo "Test-Erklaerung" > readme.md fügt "readme.md" der Versionskontrolle hinzu und merkt die Datei "readme.md" (in ihrem aktuellen Zustand in der sogenannten "Staging-Area") für ein Commit (eine Übergabe ans lokale Repository) vor git add readme.md übernimmt "readme.md" in das lokale Repository git commit m "project start - initial check-in" lädt "readme.md" in das zentrale Repository legt eine (Entwicklungs-)Zweig dev (Kurzform für develop) an git branch dev(be) Prof. Dr. M. Schäfers HAW Hamburg Technische Informatik GITonUSB@Hamburg-UAS.eu

2 Nun startet MO die GIT-bash und wechselt an eine geeignete Stelle (in den Eclipse-Workspace für Java). Achtung MO legt kein Projekt an! (BE war vorhin im Directory Test. MO "kennt" dies noch nicht und befindet sich "davor") cd geeignete Stelle klont das Repository git clone Alternativ funktioniert auch git clone Mit git clone AndererName bzw. git clone AndererName besteht die Möglichkeit einen anderen Namen zu wählen (Default ist, dass der alte Name erhalten bleibt) wechselt in das frisch geklonte Directory cd Test legt eine (Entwicklungs-)Zweig "dev" (Kurzform für develop) an git branch dev(mo) startet Eclipse und importiert unter Eclipse das zuvor geklonte Projekt [File] [Import ] [General] [Existing Projects into Workspace] Jetzt sind die Vorbereitungen für das jeweilige Projekt bzgl. GIT abgeschlossen und beide können anfangen "normal" zu arbeiten. (Wichtig für den jeweiligen Teamkollegen ist nur, dass er/sie die entsprechenden Schritte abgeschlossen hat).

3 Sagen wir mal MO fängt an und (ist zunächst im dev-branch) legt nun eine Datei ReadMe.txt mir ausführlicheren Informationen zum Projekt an Projekt: Test, TI1-P1 SS14 Organisation: HAW-Hamburg, Informatik Team: S9T8 Autor(en): Beispielfrau, Elke Mustermann, Otto fügt ReadMe.txt der Versionskontrolle hinzu und merkt die Datei ReadMe.txt (in ihrem aktuellen Zustand in der sogenannten "Staging-Area") für ein Commit (eine Übergabe ans lokale Repository) vor git add ReadMe.txt übernimmt ReadMe.txt (alle bisher gestageten Dateien) in das lokale Repository git commit m initial check-in of new file(s) wechselt auf den (Haupt-)Zweig master aktualisiert den lokalen Zweig master mischt die Änderungen aus dem lokalen Zweig dev in den lokalen Zweig master Sofern Konflikte aufgetreten sein sollten git commit m "Kurzbeschreibun der Änderungen" lädt den aktuellen lokalen Zweig (master) in das zentrale Repository auf BitBucket dort in den Zweig master mischt mögliche gelöste Konflikte aus dem lokalen Zweig master in den lokalen Zweig dev (Effekt eine Aktualisierung) <F5> wird von MO in Eclipse getippt. Bemerkung: Durch das Umschalten der Branches/Zweige können sich Dateien ändern. Auch wenn Eclipse dies meist selbst merkt, sollte dennoch immer <F5> in Eclipse getippt werden damit Eclipse gezwungen wird, nach Änderungen zu suchen

4 Nun wieder BE (ist zunächst im dev-branch) Datei "irgendwas.txt" anlegen (z.b. echo "blubb,blubb" > irgendwas.txt) und dann der Versionskontrolle übergeben und damit im aktuellen Zustand in der sogenannten "Staging-Area" für ein Commit (eine Übergabe ans lokale Repository) vormerken git add irgendwas.txt übergibt "irgendwas.txt" in die sogenannte "Staging-Area" (konkret in diesem Beispiel ReadMe.txt) dem lokalem Repository git commit m "initial check-in of new file(s)" wechselt auf den (Haupt-)Zweig master aktualisiert den lokalen Zweig master mischt die Änderungen aus dem lokalen Zweig dev in den lokalen Zweig master Sofern Konflikte aufgetreten sein sollten git commit m "Kurzbeschreibun der Änderungen" lädt den aktuellen lokalen Zweig (master) in das zentrale Repository auf BitBucket dort in den Zweig master mischt mögliche gelöste Konflikte aus dem lokalen Zweig master in den lokalen Zweig dev (Effekt eine Aktualisierung) <F5> wird von BE in Eclipse getippt. Jederzeit ist eine lokale Aktualisierung des lokalen Zweigs dev mit zentralen Haupt-Zweigs Master möglich mit git merge dev git checkout dev Alles bisher Vorgestellte ist darauf optimiert Merge-Konflikte auf ein Minimum zu beschränken und sofern Merge- Konflikte auftreten, diese Merge-Konflikte in den lokalen Zweig dev zu verlagern. Sofern Sie die ersten 3 Kapitel im Burch Pro-GIT von Scott Chacon durchgearbeitet haben und mit GIT vertraut sind, lässt sich einiges vereinfachen. Sie können sich dann einige Kommandos sparen.

5 Beispielablauf: Lösung von TI1-P1-Aufgabenzettel1-A1 (SS14) Nun lösen wir die Aufgabe A1 des 1.Aufgabenzettels von TI1-P1 (SS14). Ziel dieser Aufgabe war es, unter Beweis zu stellen, dass man mit dem "GIT-Flow" vertraut sind. Der Einfachheit halber beschreiben wir das Vorgehen wieder für unser Beispiel-Team S9T8 bestehend aus BE und MO. BE legt unter BitBucket ein privates Repository A1 an und gibt MO Schreibrechte. Ferner gibt BE ElCritico, den WiMis und den Tutoren Leserechte BE startet Eclipse an und legt ein (Java-)Projekt A1 an. BE startet die GIT-Bash und wechselt in den Projekt-Ordner. cd /z/ti1p1/workspace/a1 (je nachdem wo das Project liegt) git init git remote add origin Nun legt BE eine Datei.gitignore mit folgendem Inhalt an bin/ um Binary Files (Byte Code für die JVM) auszuschließen.ds_store wegen/für Mac OS.gitignore diskutierbar GIT liest die.gitignore-datei und weiß nun, was im Falle einer "Wildcard" nicht eingecheckt werden darf. Als nächstes erstellt BE die (Projekt-spezifische)Datei readme.md echo "Aufgabenzettel1 A1" > readme.md BE checkt nun alles ein, git add A oder alternativ git add -all git commit m "project start - initial check-in" git branch dev(be) Nun MO cd /z/ti1p1/workspace (je nachdem wo der Eclipse-Workspace liegt) git clone ssh://git@bitbucket.org/be/a1[.git] git branch dev(mo) MO startet Eclipse an und importiert das Projekt importiert MO legt nun eine Datei ReadMe.txt mir ausführlicheren Informationen zum Projekt an Projekt: A1, Aufgabenzettel1, TI1-P1, SS14 Organisation: HAW-Hamburg, Informatik Team: S9T8 Autor(en): Beispielfrau, Elke (Elke.Beispielfrau@HAW-Hamburg.de) Mustermann, Otto (Otto.Mustermann@HAW-Hamburg.de) git add A oder alternativ git add -all git commit m "initial check-in of new file(s) - ReadMe.txt" git commit m "merged" (Kurzbeschreibung der Änderung)

6 Durch das Umschalten der Branches/Zweige können sich Dateien ändern. Meist bekommt Eclipse dies selber mit. Dennoch sollte unbedingt BE legt nun unter Eclipse ein Package a1 an und erstellt eine erste Programm-Version. Etwa package a1; public class HelloWorld { public static void main( String[] args ){ System.out.printf( "Hey Ihr da" ); git commit m "initial check-in of new file(s) - Hello World class" git commit m "merged" (Kurzbeschreibung der Änderung) BE prüft noch einmal den Code. Sofern BE (Tipp-)Fehler feststellt korrigiert BE diese. git commit m snapshot: simple corrections git commit m merged (Kurzbeschreibung der Änderung) BE ist nun zuversichtlich, dass ein Test Sinn macht. BE kennzeichnet dies mit git tag -a "v0.1" -m "start testing" BE startet das Programm an und prüft ob es das tut, was es soll. Mögliche Fehler, die BE dabei findet korrigiert BE und git commit m "bug fix: " (Kurzbeschreibung der Änderung) git commit m merged (Kurzbeschreibung der Änderung) BE ist nun zufrieden mit dem Code und kennzeichnet dies mit git tag -a "v0.2" -m "all tests passed"

7 MO hat inzwischen viele Nachrichten ( s) von BitBucket erhalten und weiß daher, das BE bereits gute Arbeit geleistet hat. MO aktualisiert also sein Repository. MO schaut sich das Programm und baut ein paar Verbesserungen ein. Etwa package a1; /* * Aufgabenzettel1 A1 * Beispielfrau, Elke Elke.Beispielfrau@HAW-Hamburg.de * Mustermann, Otto Otto.Mustermann@@HAW-Hamburg.de */ public class HelloWorld { public static void main( String[] args ){ System.out.printf( "Hello World" ); git commit m "changing message" (Kurzbeschreibung der Änderung) git commit m "merged" (Kurzbeschreibung der Änderung) MO testet und befindet Alles für so gut, dass er zur Abnahme taugt (Vergleichbar einer Auslieferung an den Kunden) MO kennzeichnet dies mit git tag -a "v1.0" -m "first release" für das Kennzeichnen Einschub: An dieser Stelle halten wir die Regel fest, dass vor jeder Abnahme (bzw. jedem Abnahmeversuch) die VersionsNr um 1 (gegenüber dem letzten Abnahmeversuch) erhöht werden muss. Vor dem 1.Abnahmeversuch lautet die Versionsnr also v1.x (mögliche Stellen nach 1. vergeben Sie in sinnvoller Weise) Vor dem 2.Abnahmeversuch lautet die Versionsnr also v2.x (mögliche Stellen nach 2. vergeben Sie in sinnvoller Weise) Vor dem 3.Abnahmeversuch lautet die Versionsnr also v3.x (mögliche Stellen nach 3. vergeben Sie in sinnvoller Weise) usw. BE und MO stellen beim Labortermin Ihrer Lösung vor, beantworten die Fragen und geben ab. Oder aber bauen die geforderten Änderungen einen und nutzen GIT dabei in der nun bekannten Weise. Sicherlich ist Ihnen aufgefallen, das BE und MO recht viele Kommandos tippen mussten. Dies ist der Preis, den Sie beim Benutzen dieses Flows zahlen. Der Gewinn ist, dass Sie wenig über GIT wissen müssen und keine/kaum Merge-Konflikte haben werden. Je nach Veranstaltung (ist GIT ein direktes Lernziel?) können Sie u.u. ein Script bekommen, das einen Eincheck-Vorgang auf ein Kommando verkürzt. Dieses Script setzt allerdings mehr Kenntnisse voraus.