Alle Abgaben meiner Praktikumsaufgaben erfolgen auf GitHub mit Hilfe von Git.
Dabei ist mir, neben der Lösung der eigentlichen Aufgabenstellung, sehr wichtig, dass Sie nach den hier beschriebenen Schritten vorgehen.
Sie bekommen von mir auf dem Aufgabenblatt üblicherweise einen GitHub Classroom-Link über den Sie ein Repository für sich generieren können. Wenn Sie als Team arbeiten sollen, erzeugt der/die Erste mit dem Link ein neues Team und das Repository. Die anderen Teammitglieder treten dann über den Link dem Team bei und bekommen die Rechte für das gemeinsame Repository.
Lesen Sie sich vor dem Bearbeiten meiner Praktikumsaufgaben unbedingt die folgenden Punkte durch.
Wenn Sie noch nicht mit Git gearbeitet haben, ist https://try.github.io/ eine gute Quelle um Git kennen zu lernen.
Verwenden Sie lokal beim Committen eine E-Mail-Adresse, die Sie auch in GitHub hinzugefügt haben. Anderenfalls kann GitHub Ihnen Ihre Commits nicht zuordnen, was insbesondere bei Teams ein Problem darstellt. Dadurch gewinne ich den Eindruck Sie haben gar nichts beigetragen!
Infos, wie Sie Ihre E-Mail-Adresse lokal setzen, finden Sie unter Getting Started - First-Time Git Setup.
Committen Sie kleine sinnvolle Einheiten mit vernünftigen Commit-Messages. Eine Commit-Message sollte kurz beschreiben, was im Gegensatz zum letzten Commit verändert wurde, z.B.
Pushen Sie nach jedem Commit. Sie haben damit sofort ein Backup ihres aktuellen Stands auf GitHub. Wenn ein CI-Job für Sie eingerichtet ist, bekommen Sie sofort eine Rückmeldung. Wenn Sie im Team arbeiten, können die anderen Team-Mitglieder sofort sehen, was Sie gemacht haben und evtl. darauf reagieren.
Die Abgabe erfolgt immer als Pull-Request (PR). Committen Sie nie direkt in den master
-Branch. Die Lösung muss am Ende in einem Branch develop
sein und als Differenz zu dem master
-Branch abgegeben werden.
Tipp: Sie können in GitHub auf die Branches klicken und den develop
als Default setzen. Damit sehen Sie als erstes immer den develop
-Branch auf der Website und beim Clonen landen Sie auch gleich im develop
-Branch.
Das Feedback bekommen Sie von meinen Tutoren oder mir als Kommentar zum PR. Wenn ich den PR genehmige, haben Sie die entsprechende Aufgabe erfolgreich abgegeben.
Folgen Sie, wenn Sie alleine sind dem im Folgenden beschriebenen GitHub Flow. Im Team folgen Sie dem weiter unten beschriebenen Git-Flow mit PRs.
Wenn Sie eine Aufgabe alleine lösen, reicht es, wenn Sie dem GitHub Flow folgen. Sie können natürlich auch alleine nach dem, weiter unten beschriebenen, git-flow vorgehen.
Erzeugen Sie nach dazu einen neuen Branch develop
und wechseln Sie in diesen. Arbeiten Sie ausschließlich in diesem oder in weiteren, davon abgezweigten Branches, nie aber im master
. Committen und pushen Sie wie gewohnt oft und mit vernünftigen Commit-Messages.
Um abzugeben erzeugen Sie einen PR gegen den master
-Branch und tragen Sie mich und, sofern vorhanden, den für Sie zuständigen Tutor unter Reviewers ein.
Feedback erhalten Sie dann durch das Review. Wenn ihr PR durch mich und evtl. den Tutor approved ist, haben Sie die Abgabe bestanden und können den PR mergen.
Wenn Sie im Team arbeiten, ist es sinnvoll nicht nur in einem sondern in mehreren Branches zu arbeiten. Auch in diesem Fall ist der master
-Branch tabu.
Vincent Driessen hat in einem Blog-Post ein Git-Branching-Modell vorgeschlagen, das mittlerweile unter dem Namen git-flow als Erweiterung von Git verfügbar ist. Einige Git-GUIs, wie z.B. SourceTree, enthalten direkte Unterstützung für git-flow.
Dies ist aber letzendlich nicht notwendig. Sie können das git flow Modell auch einfach mit den in Git verfügbaren Kommandos nutzen.
Git-flow hat mit GitHub nichts zu tun. Daher sind auch die PRs nicht Teil von git-flow.
Gehen Sie daher, mit oder ohne git-flow-Toolunterstützung, folgendermaßen vor:
master
develop
develop
abzweigendevelop
-Branch develop
-Branch in den master
-Branch, wie oben, beim GitHub Flow, beschrieben.Um sich das Leben einfach zu machen, sollten Sie auf jeden Fall git-flow nutzen, außer es gibt ein Riesenproblem, bei dem ich nicht einmal helfen kann.
Mit git-flow gehen Sie dann wie im Folgenden beschrieben vor.
Installieren Sie zunächst git-flow, falls Sie kein GUI, wie z.B. SourceTree benutzen, das die Unterstützung für git-flow gleich mitbringt. Auch Git for Windows hat in der aktuellen Version git-flow mit an Bord. Die Installation ist hier beschrieben.
Initialisieren des Repositories für git-flow:
git flow init
Sie können alle Fragen mit der Default-Antwort übernehmen. Sie haben damit einen develop
-Branch erzeugt und ihn automatisch gleich ausgecheckt.
Pushen Sie den develop
-Branch dann noch auf GitHub, wenn noch niemand aus Ihrem Team das getan hat:
git push origin develop
Wenn Sie mit einem neuen Feature bzw. einer Teilaufgabe meinNeuesFeature
beginnen wollen:
git flow feature start meinNeuesFeature
Damit befinden Sie sich in einem neuen Feature-Branch, der, wie oben beschrieben, vom develop
-Branch abzweigt.
Um ihn für die anderen Teammitglieder auf GitHub zur Verfügung zu stellen:
git flow feature publish meinNeuesFeature
Achtung: Jetzt weicht es von dem normalen git-flow ab:
Pushen Sie ihren Branch auf GitHub und erzeugen Sie einen Pull-Request gegen den develop
-Branch.
Je nach Aufgabenstellung muss vielleicht ein Review durch ein Teammiglied erfolgen. Wenn nicht, können Sie mit git flow bei sich lokal mergen
git flow feature finish meinNeuesFeature
Das schließt den PR auch automatisch. Der PR ist dann nur dafür da gewesen um nachvollziehbar zu machen, was gemerged wurde. Sie müssen anschließend noch den aktuellen Stand des develop
-Branches auf GitHub pushen.
Wenn, gemäß Aufgabestellung, jemand anderes den PR mergen muss, kann er/sie das direkt auf GitHub machen. Sie als Entwickler müssen dann selbst in den develop
zurück (git checkout develop
) und die gemergeten Commits von GitHub pullen. Anschließend löschen Sie dann ihren Feature-Branch:
git branch -D meinNeuesFeature
Die Abgabe oder ein Zwischenrelease erfolgt als Pull-Request von develop
in den master
. Sie können entweder den PR direkt erzeugen und mich und den für Sie zuständigen Tutor als Reviewer eintragen. Dann gibt es wieder Feedback und wenn es ein Approval von mir gibt, können Sie in den master
mergen.
Mit git flow gehen Sie folgendermaßen vor:
Sie beginnen ein neues Release mit einem Bezeichner. Verwenden Sie den Bezeichner Abgabe
wenn nicht anders in der Aufgabenstellung vorgeschrieben:
git flow release start Abgabe
Das erzeugt einen Release-Branch vom develop
, in dem Sie noch Release-spezifische Commits machen könnten (z.B. die neue Versionsnummer in irgendwelchen Dateien eintragen).
Veröffentlichen Sie Ihren Release-Branch anschließend mit
git flow release publish Abgabe
und erzeugen Sie einen PR vom Release-Branch in den master
-Branch. Mergen Sie diesen PR auf keinen Fall über die GitHub-Website. Der PR ist nur dafür da um ein Feedback bzw. eine Freigabe von mir zu bekommen.
Wenn ich den PR approved habe, führen Sie lokal folgendes aus:
git flow release finish
git push --all
git push --tags
Wenn Sie z.B. SourceTree nutzen, können Sie gleich beide Branches inklusive der Tags pushen und brauchen nicht in den Branches hin und her zu springen.
Der git-flow-Spickzettel gibt einen guten Überblick über die git-flow Kommandos.
Sollten Sie eine Frage zu Ihrem Code haben oder konkrete Hilfe benötigen, erzeugen Sie in dem entsprechenden Repository über die GitHub-Seite des Repository ein Issue. In diesem Issue beschreiben Sie Ihr Problem und verlinken auf zusätzliche Informationen, wie Code oder Travis/Jenkins-Job. Nutzen Sie Markdown um Ihr Issue besser lesbar zu gestalten. Ein gut lesbares Issue bearbeite ich viel lieber und schneller!
Damit ich oder ein Tutor überhaupt mit bekommt, dass Sie eine Frage haben, führen Sie folgende Schritte durch:
Ohne diese beiden Schritte werden die Issues von uns nicht registriert und daher nicht bearbeitet! Durch die Zuweisung werden wir per E-Mail informiert und können, schnellstmöglich, auf Ihre Frage reagieren.
Zur Kommunikation bezüglich einer Lehrveranstaltung von mir gibt es jeweils einen Gitter-Room. Sie finden ihn auf der Seite zur Veranstaltung links unter Links.
Stellen Sie in diesem Raum inbesondere alle Fragen, die nicht nur Sie interessieren könnten. Wer weiter helfen kann, darf gerne weiter helfen. Mich selbst finden Sie in den Räumen jeweils unter dem Namen obcode.
Nutzen Sie auch in Gitter die Möglichkeit Ihre Nachricht in Markdown zu formatieren. Damit werden insbesondere Code-Schnipsel viel besser lesbar.