Betreuer-Workflow

Diese Seite ist für Betreuer – diejenigen von uns, die unsere eigenen oder die Änderungen anderer Leute in das Upstream-Repository einbinden.

Als Betreuer haben Sie die grundlegenden Dinge im Entwicklungs-Workflow vollständig im Griff .

Die Anweisungen in Verknüpfen Ihres Repositorys mit dem Upstream -Repository fügen ein Remote hinzu, das schreibgeschützten Zugriff auf das Upstream-Repository hat. Als Betreuer haben Sie Lese- und Schreibzugriff.

Es ist gut, wenn Ihre Upstream-Fernbedienung einen gruseligen Namen hat, um Sie daran zu erinnern, dass es sich um eine Lese-/Schreib-Fernbedienung handelt:

git remote add upstream-rw [email protected]:matplotlib/matplotlib.git
git fetch upstream-rw

Änderungen integrieren

Nehmen wir an, Sie haben einige Änderungen, die in trunk ( upstream-rw/main) gehen müssen.

Die Änderungen befinden sich in einem Zweig, in dem Sie sich gerade befinden. Zum Beispiel sehen Sie sich die Änderungen von jemandem so an:

git remote add someone https://github.com/someone/matplotlib.git
git fetch someone
git branch cool-feature --track someone/cool-feature
git checkout cool-feature

Jetzt sind Sie also auf dem Zweig mit den Änderungen, die stromaufwärts eingearbeitet werden sollen. Der Rest dieses Abschnitts geht davon aus, dass Sie sich auf diesem Zweig befinden.

Ein paar Commits

Wenn es nur wenige Commits gibt, erwägen Sie ein Rebasing auf Upstream:

# Fetch upstream changes
git fetch upstream-rw
# rebase
git rebase upstream-rw/main

Denken Sie daran, dass Sie alle Github-Pull-Anforderungen manuell schließen müssen, wenn Sie eine Rebase durchführen und diese pushen, da Github nicht erkennen kann, dass die Änderungen bereits zusammengeführt wurden.

Eine lange Reihe von Commits

Wenn es eine längere Reihe verwandter Commits gibt, ziehen Sie stattdessen eine Zusammenführung in Betracht:

git fetch upstream-rw
git merge --no-ff upstream-rw/main

Die Zusammenführung wird von github erkannt und sollte alle zugehörigen Pull-Anforderungen automatisch schließen.

Beachten Sie das --no-ffoben. Dies zwingt git dazu, einen Merge-Commit durchzuführen, anstatt einen schnellen Vorlauf zu machen, so dass diese Gruppe von Commits von trunk abzweigen und dann mit einem Merge wieder in die Haupthistorie eintreten, anstatt den Anschein zu erwecken, direkt über trunk gemacht worden zu sein.

Überprüfen Sie den Verlauf

Jetzt sollten Sie in jedem Fall überprüfen, ob der Verlauf sinnvoll ist und Sie die richtigen Commits haben:

git log --oneline --graph
git log -p upstream-rw/main..

Die erste Zeile oben zeigt nur den Verlauf in kompakter Form mit einer Textdarstellung des Verlaufsdiagramms. Die zweite Zeile zeigt das Protokoll der Commits mit Ausnahme derjenigen, die von trunk ( upstream-rw/main) aus erreichbar sind, und einschließlich derjenigen, die vom aktuellen HEAD aus erreichbar sind (impliziert mit dem .. am Ende). Es zeigt also die Commits, die für diesen Zweig einzigartig sind, im Vergleich zu Trunk. Die -pOption zeigt den Unterschied für diese Commits in Patch-Form.

Push-to-Trunk

git push upstream-rw my-new-feature:main

Dadurch wird der my-new-featureZweig in diesem Repository zum main Zweig im upstream-rwRepository verschoben.