Git Fetch-Pull-Request: Fertigkeit freigeschaltet
Nicola Paolucci
Developer Advocate
Heutzutage ist das Einfügen von Korrekturen in ein Projekt so einfach wie das Erstellen von Forks (dabei erhältst du eine vollständige Remote-Kopie des Projekts, in der du munter werkeln kannst): Du musst nur die zu ändernde Datei auswählen, auf Bearbeiten klicken und einen Commit für deine Korrekturen durchführen.
Was aber, wenn du am anderen Ende sitzt und derjenige bist, der den Pull-Request (im Folgenden kurz PR) erhält? Oft hilft eine optimierte Webbenutzeroberfläche, mehr braucht es nicht. Ein Klick auf Approve (Genehmigen) und ein Klick auf Merge (Mergen) und schon bist du fertig.
Doch so läuft es nicht immer. Oft ist es erforderlich, die Änderungen des Pull-Requests (PR) lokal zu speichern, um Tests durchzuführen und sich das Ganze in der eigenen IDE vor Augen zu führen.
Die Schritte zum Herunterladen der Pull-Requests deiner Kollegen – oder genauer genommen zum Fetchen und Auschecken – sind prinzipiell einfach. Du kannst dir das Ganze sogar noch leichter machen, wenn du einige wichtige Punkte und Tricks kennst.
Deshalb möchte ich dir näherbringen, welche Kniffe Git für Befehlszeilen bereithält, wenn es um Pull-Requests geht.
Vor dem Start: Branch-Name und Status in der Shell-Eingabeaufforderung
Es überrascht mich immer wieder, wie viele Entwickler eine Eingabeaufforderung verwenden, die nicht einmal anzeigt, auf welchem git-Branch sie sich befinden, oder ob in ihrem Arbeitsverzeichnis geänderte/nicht committete Dateien vorhanden sind. Hast du dich darin gerade wiedererkannt? Dann erlaube mir, dir ein paar Tipps zu geben und dich gleichzeitig schwer zu beeindrucken!
Tu dir selbst einen Gefallen und installiere den großartigen Liquid Prompt und du erhältst hervorragende Erläuterungen zum Status deines Arbeitsverzeichnisses in Git (oder einem beliebigen anderen VCS):
(Im Screenshot oben siehst du, dass auf meine Eingabe hin angezeigt wird, dass ich mich im Branch neuerbrach befinde und 5 Zeilen zu den von mir verfolgten Dateien in meinem Arbeitsverzeichnis hinzugefügt und 0 entfernt habe.)
Zugehöriges Material
Git installieren
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
Alle arbeiten im selben Repository
Wenn du mit deinem Team im selben Repository arbeitest, ist das Auschecken eines Pull-Requests eine einfache Sache: Du musst den Branch, von dem der Pull-Request erstellt wurde, nur fetchen und auschecken:
- Rufe alle Branches ab, die in eurem gemeinsamen Repository veröffentlicht wurden:
git fetch origin- Erstelle einen lokalen Branch, der den für dich interessanten Remote Branch verfolgt:
git checkout -b PRJ-1234 origin/PRJ-1234- Jetzt kannst du
diffundmergeausführen und nach Herzenslust testen:
git diff main ./run-tests.sh- Wenn du mit dem Code zufrieden bist, kannst du zur Webbenutzeroberfläche zurückkehren, Feedback geben oder die Änderung vollständig genehmigen.
Mitarbeitende arbeiten in ihren eigenen Forks
Der Prozess sieht ein wenig anders aus, wenn einige der Beitragenden in separaten Abspaltungen arbeiten. In diesem Fall könntest du mit fetch den Remote-Branch abrufen, in dem der Beitrag oder das Feature committed wurde:
- Füge zuerst den Remote Branch des Mitarbeiters hinzu:
git remote add jsmith http://bitbucket.org/jsmith/coolproject.git- Erfasse zunächst die neuesten Updates von
origin, deinem Haupt-Repository:
git checkout main git fetch origin git merge main- Rufe alle Branches ab, die in der Fork des Mitarbeiters veröffentlicht wurden:
git fetch jsmith
- Erstelle einen lokalen Branch, der den für dich interessanten Remote Branch verfolgt:
git checkout -b jsmith-PRJ-1234 jsmith/PRJ-1234
- Jetzt kannst du
diffundmergeausführen und nach Herzenslust testen:
git diff main ./run-tests.sh
Weniger Arbeitsaufwand dank Pull-Request-Referenzen
Die obige Methode funktioniert, aber gewisse Faktoren können dir dein Leben erschweren:
- Was passiert, wenn du viele Mitarbeiter hast, die alle über ihre eigene Fork verfügen? Das Hinzufügen aller Forks und ihre separate Behandlung ist nicht zweckmäßig.
- Was passiert, wenn du nicht einmal Zugriff auf einige dieser Forks hast und du den Quell-Branch nicht auschecken kannst?
In beiden Fällen lautet die Lösung: Pull-Request-Refs. Diese werden von einigen Git-Servern bereitgestellt. Meine Methode wird auf einigen Git-Servern unterstützt und kann auf deinem Server etwas anders ablaufen. Im Folgenden erkläre ich, wie du sämtliche Pull-Requests in Stash (jetzt Bitbucket Data Center) und GitHub mit dem Befehl fetch abrufen kannst.
Keine Angst vor den Refspecs
Zuallererst solltest du dich mit Refspecs vertraut machen. Kein Grund zur Sorge, Refspecs sind eine tolle Sache. Darunter versteht man einfache Zuordnungen von Remote-Branches zu lokalen Referenzen oder, anders ausgedrückt, einen direkten Weg, Git aufzufordern: "Ordne diesen Remote-Branch (oder diese Remote-Branches) diesem Namensraum lokal zu".
Ein Befehl wie z. B.:
git fetch +refs/heads/main:refs/remotes/origin/main
Dieser Befehl ordnet den Remote-Branch main in deiner origin-Remote-Verbindung einem lokalen origin/main zu. Jetzt kannst du Folgendes eingeben:
git checkout origin/main
Der Verweis bezieht sich weiterhin auf diesen Remote Branch. Das Plus-Zeichen (+) in der Definition zeigt Git, dass wir die Referenz aktualisieren wollen, wenn auch nicht per Fast-Forward.
Dies nutzen wir zum Herunterladen aller Pull-Requests, indem wir zuordnen, wie das Remote-Repository die PR-HEADS speichert, und sie einem lokalen Namensraum zuordnen, um sie leicht referenzieren zu können.
Wenn du ein origin- (oder upstream)-Remote-Repository definiert hast, gehst du wie folgt vor.
Hinweis: Wie einige Stash-Entwickler (jetzt Bitbucket Data Center) zu Recht bemerkt haben, sind meine folgenden Refs undokumentiert und privat und Änderungen an ihnen jederzeit möglich.
Herunterladen aller Pull-Requests: Stash
- Forke ein Repository.
- Klone deine Fork lokal:
git clone git@stash.atlassian.com:durdn/tis.git- Füge das ursprüngliche Upstream-Repository als
upstreamhinzu.
git remote add upstream git@stash.atlassian.com:tpettersen/tis.git- Hole dir die neuesten Heads vom Maintainer "upstream".
git fetch upstream
- Füge das
Refspechinzu, das die Heads der Remote-Pull-Requests dem lokalenpr-Namensraum zuordnet. Führe dazu den Befehlconfigaus:
git config --add remote.origin.fetch '+refs/pull-requests/*/from:refs/remotes/origin/pr/*'- In
.git/configwerden diefetch-Einträge zu:
[remote "upstream"]
url = git@stash.atlassian.com:docker/libswarm.git
fetch = +refs/heads/*:refs/remotes/upstream/*
fetch = +refs/pull-requests/*/from:refs/remotes/upstream/pr/*- Jetzt kannst du mit
fetcheinfach alle Pull-Anfrage-Branches abrufen:
$ git fetch upstream
remote: Counting objects: 417, done.
remote: Compressing objects: 100% (274/274), done.
remote: Total 417 (delta 226), reused 277 (delta 128)
Receiving objects: 100% (417/417), 105.28 KiB | 0 bytes/s, done.
Resolving deltas: 100% (226/226), done.
From stash.atlassian.com:docker/libswarm
* [new ref] refs/pull-requests/10/from-> upstream/pr/10
[...]
* [new ref] refs/pull-requests/100/from -> upstream/pr/100
* [new ref] refs/pull-requests/101/from -> upstream/pr/101
[...]
* [new ref] refs/pull-requests/109/from -> upstream/pr/109
* [new ref] refs/pull-requests/110/from -> upstream/pr/110
[...]- Nun kannst du einfach folgendermaßen zu einem bestimmten Pull-Request wechseln:
git checkout pr/102Herunterladen aller Pull-Requests: Github
Wenn sich die Abspaltungen oder Upstreams auf GitHub befinden, funktioniert es genau wie oben, nur der Befehl config ändert sich zu:
git config --add remote.origin.fetch '+refs/pull//head:refs/remotes/origin/pr/'Und das Remote-Repository in .git/config wird so geändert, dass er eine zusätzliche fetch-Konfiguration enthält, mit der die PR-Heads einem lokalen Namensbereich mit der Bezeichnung pr zugeordnet werden:
[remote "upstream"] url = git@github.com:docker/libswarm.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*
Abrufen eines einzelnen Pull-Requests mithilfe von Referenzen
Wenn du keine fetch-Einträge in .git/config machen und schnell mit einem Pull-Request fortfahren willst, ist hier der passende Befehl:
- Auschecken einer einzelnen PA in Bitbucket:
git fetch refs/pull-requests/your-pr-number/from:local-branch-name- Auschecken eines einzelnen PR in Github:
git fetch refs/pull/your-pr-number/head:local-branch-nameWenn du den obigen Befehl häufig verwendest, kannst du den Prozess mit einem git-Alias optimieren:
# For Stash
git config alias.spr '!sh -c "git fetch origin pull-requests/${1}/from:pr/${1}" -'
# For Github
git config alias.gpr '!sh -c "git fetch origin pull/${1}/head:pr/${1}" -'Wenn dieser Alias konfiguriert ist, können wir mit einem einfachen Befehl (danke, Inuit) eine Pull-Anfrage abrufen:
Fazit
Sobald du ein paar einfache Aliasse erstellt oder die richtigen Refspecs zu deiner .git/config hinzugefügt hast, ist es einfach, die Arbeit deiner Kollegen oder Beitragenden im Auge zu behalten.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
