Wenn Sie GitHub verwenden und wie ich die Befehlszeile bevorzugen, um alles ohne Komplikationen auf der GUI zu erledigen, ist Ihnen vielleicht aufgefallen, dass GitHub begonnen hat, ihr nicht ganz so neues Tool namens „gh“ zu verwenden. Ich beschloss, es zu versuchen, weil es doch vielversprechend aussah. Und es hat mir persönlich sehr gut gefallen – so sehr, dass ich einen Artikel darüber schreiben wollte!
Bevor wir jedoch beginnen, muss ich einige Begriffe erklären, die ich in diesem Artikel verwenden werde.
„GH“ steht für „GitHub“. Daher stammt auch der Name des Tools, sodass es nicht mit Git selbst verwechselt werden kann. Um zu erklären, was es im Allgemeinen tut, können Sie Repos erstellen, forken, löschen und durchsuchen. Pull-Requests erstellen; und viele mehr. Für den Fall, dass Sie eine Funktion nicht finden, das Terminal aber auch nicht verlassen möchten, bietet es Ihnen auch einen textbasierten Browser zum Durchsuchen von Seiten in GitHub.
„CLI“ steht für „CBefehl LIne ISchnittstelle“. Dieses Terminal (oder in Windows die Eingabeaufforderung) ist eines davon. Wenn neben einem App-Namen ein „CLI“ angehängt ist („Git CLI“ für diesen Artikel), bedeutet dies, dass die App nur über das Terminal ausgeführt wird. Und „Git CLI“ ist in diesem Zusammenhang das Git, das wir kennen. Wie der Befehl, mit dem wir Commits oder Rebases durchführen.
GUI steht für „Graphisch Usehen ISchnittstelle“ und es ist die Schnittstelle, auf der wir „navigieren“. Besser gesagt ist eine Desktop-Umgebung im Allgemeinen eine GUI.
Ein „API-Schlüssel“ ist eine Art geheime Zeichenfolge/Datei, die Sie zur Authentifizierung bei Diensten verwenden. Beachten Sie, dass die 2-Faktor-Authentifizierung usw. umgangen wird, wenn Sie sich damit authentifizieren. Bewahren Sie sie daher sicher und an einem Ort auf, der mit anderen Mitteln nicht erreichbar ist.
Zunächst einmal: Was ist dieses Tool? Wie werden Vorgänge gehandhabt, die wir über die Git-CLI ausführen würden?
„gh“ kann als Open Source betrachtet werden (Source Code)-Wrapper, der Git CLI selbst und GitHub-APIs verwendet, um Dinge zu erledigen. Tatsächlich können Sie sogar Parameter an die verwendeten Git-Befehle übergeben! Darauf werde ich später noch eingehen.
Installation und Einrichtung
Denken Sie daran, dass ich die Installation mit durchführen werde Termux. Aber das Verfahren sollte im Großen und Ganzen das gleiche sein wie bei einer Debian-basierten Distribution – Ubuntu hat es zum Beispiel in seinen offiziellen Repos. Für Windows benötigen Sie vermutlich entweder CygWin oder WSL. ¯\_(ツ)_/¯
# Lassen Sie uns zuerst das Tool installieren. Außerdem wird Git installiert, da es die Backend-Nummer für gh ist. $ pkg install git gh -y # Dann müssen wir uns vor allem authentifizieren. Dadurch wird ein # neuer API-Schlüssel in der Datenbank des Tools gespeichert, sodass Sie sich nicht # erneut authentifizieren müssen. Wenn Sie GITHUB_TOKEN bereits festgelegt haben, funktioniert dies nicht. Deaktivieren Sie es daher zuerst. :) $ gh Auth-Login
Bevor wir hier fortfahren, muss ich auf einige Dinge hinweisen.
- Erstens Wählen Sie nicht „GitHub Enterprise Server“ wenn Sie keinen selbstgehosteten GitHub haben.
- Zweitens Verwenden Sie SSH anstelle von HTTPS, wenn Sie Ihren öffentlichen Schlüssel zu Ihrem GitHub-Konto hinzugefügt haben. Falls Sie den API-Schlüssel verlieren, verlieren Sie zumindest Ihren SSH-Schlüssel nicht, sodass dies auch eine gute Fallback-Methode sein kann.
- Drittens wählen Sie die Anmeldung mit dem Browser Nur wenn Sie keinen API-Schlüssel zur Hand haben! Es würde wirklich keinen Sinn machen, einen weiteren Schlüssel zu haben, solange Sie bereits einen haben.
Sobald Sie mit der Einrichtung fertig sind, informieren wir Git CLI darüber.
$ gh auth setup-git
Dadurch werden die erforderlichen Git-CLI-Konfigurationen vorgenommen, für den Fall, dass Ihre Reflexe auftauchen und Sie Git anstelle von GH verwenden.
Einige grundlegende Befehle
Nachdem Sie GH eingerichtet haben, möchte ich Ihnen einige grundlegende Befehle auf Story-Basis beibringen.
Nehmen wir zunächst an, Sie möchten eine Pull-Anfrage an mein lokales Manifest-Repository erstellen. Sie möchten es zuerst forken.
$ gh Repo-Fork windowz414/platform_manifest ! windowz414/platform_manifest existiert bereits? Möchten Sie den Fork klonen? Ja Klonen in „platform_manifest“... remote: Objekte aufzählen: 136, fertig. remote: Objekte zählen: 100 % (136/136), fertig. remote: Objekte komprimieren: 100 % (81/81), fertig. Remote: Gesamt 136 (Delta 46), wiederverwendet 89 (Delta 12), wiederverpackt 0 Empfangende Objekte: 100 % (136/136), 30.70 KiB | 166.00 KiB/s, fertig. Deltas auflösen: 100 % (46/46), fertig. Aktualisierung des Upstreams von github.com:windowz414/platform_manifest * [neuer Zweig] amyrom/rosie -> upstream/amyrom/rosie * [neuer Zweig] aosp-eleven -> upstream/aosp-eleven * [neuer Zweig] aosp-ten -> upstream/aosp-ten * [neuer Zweig] Pfeil-11.0 -> upstream/pfeil-11.0 * [neuer Zweig] cm-14.1 -> upstream/cm-14.1 * [neuer Zweig] dot11 -> upstream/dot11 * [neuer Zweig ] e/os/v1-nougat -> upstream/e/os/v1-nougat * [neuer Zweig] fluid-11 -> upstream/fluid-11 * [neuer Zweig] fox_7.1 -> upstream/fox_7.1 * [neuer Zweig] hentai-rika -> upstream/hentai-rika * [neuer Zweig] ion-pie -> upstream/ion-pie * [neuer Zweig] lineage-15.1 -> upstream/lineage-15.1 * [neuer Zweig] lineage -17.1 -> upstream/lineage-17.1 * [neuer Zweig] lineage-18.1 -> upstream/lineage-18.1 * [neuer Zweig] lineage-18.1_teos -> upstream/lineage-18.1_teos * [neuer Zweig] lineage-19.0 - > upstream/lineage-19.0 * [neuer Zweig] main -> upstream/main * [neuer Zweig] mkn-mr1 -> upstream/mkn-mr1 * [neuer Zweig] revengeos-r11.0 -> upstream/revengeos-r11.0. 1 * [neuer Zweig] stellar-S1 -> upstream/stellar-S11 * [neuer Zweig] teos-n -> upstream/teos-n * [neuer Zweig] weebprojekt-11 -> upstream/weebprojekt-XNUMX ✓ Geklonter Fork
Nehmen wir dann an, Sie haben eine separate Organisation für Ihre Experimente mit dem Namen „wz414-labs“, die Sie noch nicht in Ihrem persönlichen Profil geforkt haben und die Sie dort klonen und dann dort stattdessen eine Pull-Anfrage öffnen möchten. Sie möchten auch den „cm-14.1“-Zweig klonen, damit Sie ihn nicht erneut per Git-Checkout auschecken müssen.
$ gh Repo-Fork windowz414/platform_manifest --org="wz414-labs" -- --branch="cm-14.1" ✓ Fork wz414-labs/platform_manifest erstellt? Möchten Sie den Fork klonen? Ja Klonen in „platform_manifest“... remote: Objekte aufzählen: 136, fertig. remote: Objekte zählen: 100 % (136/136), fertig. remote: Objekte komprimieren: 100 % (81/81), fertig. Remote: Gesamt 136 (Delta 46), wiederverwendet 89 (Delta 12), wiederverpackt 0 Empfangende Objekte: 100 % (136/136), 30.70 KiB | 120.00 KiB/s, fertig. Deltas auflösen: 100 % (46/46), fertig. Aktualisierung des Upstreams von github.com:windowz414/platform_manifest * [neuer Zweig] amyrom/rosie -> upstream/amyrom/rosie * [neuer Zweig] aosp-eleven -> upstream/aosp-eleven * [neuer Zweig] aosp-ten -> upstream/aosp-ten * [neuer Zweig] Pfeil-11.0 -> upstream/pfeil-11.0 * [neuer Zweig] cm-14.1 -> upstream/cm-14.1 * [neuer Zweig] dot11 -> upstream/dot11 * [neuer Zweig ] e/os/v1-nougat -> upstream/e/os/v1-nougat * [neuer Zweig] fluid-11 -> upstream/fluid-11 * [neuer Zweig] fox_7.1 -> upstream/fox_7.1 * [neuer Zweig] hentai-rika -> upstream/hentai-rika * [neuer Zweig] ion-pie -> upstream/ion-pie * [neuer Zweig] lineage-15.1 -> upstream/lineage-15.1 * [neuer Zweig] lineage -17.1 -> upstream/lineage-17.1 * [neuer Zweig] lineage-18.1 -> upstream/lineage-18.1 * [neuer Zweig] lineage-18.1_teos -> upstream/lineage-18.1_teos * [neuer Zweig] lineage-19.0 - > upstream/lineage-19.0 * [neuer Zweig] main -> upstream/main * [neuer Zweig] mkn-mr1 -> upstream/mkn-mr1 * [neuer Zweig] revengeos-r11.0 -> upstream/revengeos-r11.0. 1 * [neuer Zweig] stellar-S1 -> upstream/stellar-S11 * [neuer Zweig] teos-n -> upstream/teos-n * [neuer Zweig] weebprojekt-11 -> upstream/weebprojekt-XNUMX ✓ Geklonter Fork
Sie sehen, ich habe nicht „-b cm-14.1“ verwendet und stattdessen das lange Argument verwendet. Zum Datum dieses Artikels, dem 16. Februar 2022, weist GH einen Fehler auf, der dazu führt, dass kurze Argumente nicht korrekt an Git CLI übergeben werden und dies stattdessen als lange Argumente erfolgen muss.
Sobald dies erledigt ist, haben Sie den Ordner regelmäßig betreten, Ihre Änderungen vorgenommen, einen Commit durchgeführt und ihn dann gepusht, und Sie sind bereit, eine Pull-Anfrage durchzuführen. Dazu benötigen Sie lediglich ein einfaches
$ gh pr create --branch="cm-14.1" Pull-Request für wz414-labs:cm-14.1 in cm-14.1 in windowz414/platform_manifest erstellen? Titeltexte: Wechsel zu Git-Polycule? Körper ? Was kommt als nächstes? Senden Sie https://github.com/windowz414/platform_manifest/pull/1
Wenn Sie „–branch=cm-14.1“ nicht anhängen, würden Sie PR in Richtung „Hauptzweig“ erstellen, was natürlich zu Problemen führt, wenn es nicht richtig gehandhabt wird.
Und jetzt muss ich diese PR zusammenführen, oder? Also klone ich zuerst das Repo, checke in den zugewiesenen Zweig aus und liste zuerst PRs auf.
# Zuerst klonen. $ git clone https://github.com/windowz414/platform_manifest Klonen in „platform_manifest“... remote: Objekte aufzählen: 136, fertig. remote: Objekte zählen: 100 % (136/136), fertig. remote: Objekte komprimieren: 100 % (81/81), fertig. Remote: Gesamt 136 (Delta 46), wiederverwendet 89 (Delta 12), wiederverpackt 0 Empfangende Objekte: 100 % (136/136), 30.70 KiB | 137.00 KiB/s, fertig. Deltas auflösen: 100 % (46/46), fertig. # Dann checken Sie in der Filiale aus. $ git checkout cm-14.1 Zweig „cm-14.1“ eingerichtet, um „origin/cm-14.1“ zu verfolgen. Zu einem neuen Zweig „cm-14.1“ gewechselt # Und jetzt werden PRs aufgelistet. $ gh pr list Zeigt 1 von 1 offenen Pull-Request in windowz414/platform_manifest #1 an: Wechseln Sie zu Git-Polycule wz414-labs:cm-14.1
Nachdem wir nun gesehen haben, dass es eine PR gibt, Remote in „Git-Polycule“ zu ändern, wollen wir sehen, was sich daran geändert hat.
$ gh pr diff 1 diff --git a/teos.xml b/teos.xml index b145fc0..3aadeb6 100644 --- a/teos.xml +++ b/teos.xml @@ -2,7 +2,7, 414 @@
Scheint vielversprechend! Zeit zum Zusammenführen!
$ gh pr merge 1 ? Welche Zusammenführungsmethode möchten Sie verwenden? Rebase und Merge? Was kommt als nächstes? Senden ✓ Neubasierte und zusammengeführte Pull-Anfrage Nr. 1 (Teos: Wechsel zu Git-Polycule)
Nachdem ich es nun zusammengeführt habe, können Sie Ihren Fork löschen.
$ gh repo delete --confirm wz414-labs/platform_manifest ✓ Gelöschtes Repository wz414-labs/platform_manifest
Sie sehen, dass das Repo direkt ohne Bestätigungsanfrage gelöscht wurde, weil ich dort den Parameter „–confirm“ übergeben habe. Wenn Sie es nicht bestehen würden, würden Sie Folgendes bekommen:
$ gh repo windowz414/systemd löschen? Geben Sie windowz414/systemd ein, um den Löschvorgang zu bestätigen:
Und Sie müssten den gesamten Repo-Namen eingeben. Zeitverschwendung…
Zusammenfassung
Einfach ausgedrückt ist „gh“ ein ziemlich vereinfachter Git-CLI/Curl-Wrapper, der einfache Git-Operationen und GitHub-API-Dinge unter einem Dach vereint. Wie nutzen Sie es? Sieht es für Sie genauso vielversprechend aus wie für mich? Freue mich von Dir zu hören!
