Bearbeitung und Abgabe der Praktikumsaufgaben


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.

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 mir (oder, falls vorhanden, von einem Tutor) als Kommentar zum PR. Wenn ich den PR genehmige, haben Sie die entsprechende Aufgabe erfolgreich abgegeben.

Bitte halten Sie sich genau an die Benennung. Nennen Sie den Abgabe-Branch nicht dev o.ä., sondern wirklich develop .


Um sich die Arbeit, insbesondere im Team, noch ein wenig besser zu strukturieren, bieten sich die im Folgenden beschriebenen Standardverfahren an:

  • GitHub Flow : Wenn Sie die Aufgabe alleine bearbeiten (müssen).
  • Git-Flow mit PRs : Im Team (aber auch alleine).

Alleine: GitHub Flow

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.

Im Team: Git-Flow mit Pull-Requests

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 und IDEs enthalten direkte Unterstützung für git-flow bzw. bieten Unterstützung über Plugins.

Dies ist aber letzendlich nicht notwendig. Sie könnten 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:

  • keine Commits direkt im master
  • der gemeinsame Branch heisst develop
    • in diese können “kleine” Commits gemacht werden
  • alle neuen Features die Sie implementieren wollen, entwickeln Sie in einem neuen Feature-Branch, den Sie von develop abzweigen
  • wenn Sie mit einem Feature fertig sind, erstellen Sie einen PR gegen den develop -Branch
    • je nach Aufgabenstellung müssen Sie einen Reviewer für den PR auswählen oder können gleich selbst mergen
  • die Abgabe erfolgt als PR vom 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

Ein neues Feature entwickeln bzw. eine Teilaufgabe lösen

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

Abgabe

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, falls vorhanden, 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

Der git-flow-Spickzettel gibt einen guten Überblick über die git-flow Kommandos.