git-hub – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git-hub – Git-Befehlszeilenschnittstelle zu GitHub

ZUSAMMENFASSUNG

Git Hub [globale Optionen] [Optionen] [Argumente]

BESCHREIBUNG

git Nabe ist eine einfache Befehlszeilenschnittstelle zu GitHub, die die meisten nützlichen GitHub-Aufgaben ermöglicht
(wie das Erstellen und Auflisten von Pull-Requests oder Issues), auf die direkt über den Git zugegriffen werden kann
Befehlszeile.

Um diesen Befehl verwenden zu können, müssen Sie wahrscheinlich eine Erstkonfiguration vornehmen
Autorisierung von GitHub. Dazu können Sie die verwenden -Setup Befehl. Siehe die
CONFIGURATION Abschnitt für weitere Konfigurationsoptionen.

GLOBALES OPTIONAL

-H, --help
Diese Hilfe anzeigen und beenden.

--Version
Versionsnummer des Programms anzeigen und beenden.

-in, - ausführlich
Seien Sie ausführlicher (kann mehrmals angegeben werden, um mehr Ausführlichkeit zu erhalten)

-S, --Leise
Seien Sie weniger ausführlich (kann mehrmals angegeben werden, um weniger Ausführlichkeit zu erhalten)

BEFEHLE

-Setup Dieser Befehl führt eine Ersteinrichtung durch, um eine Verbindung zu GitHub herzustellen. Es fragt im Grunde
GitHub für ein Autorisierungstoken und speichert es in der Konfigurationsvariablen
hub.oauthtoken für die zukünftige Verwendung, sodass Sie nicht jedes Mal Ihr Passwort eingeben müssen (bzw
speichere es in der Konfiguration). Der Benutzername wird auch für die zukünftige Verwendung im gespeichert
hub.Benutzername Variable. Wenn die Basis-URL angegeben ist, wird sie in gespeichert hub.baseurl
Auch.

-u NUTZERNAME, --username=BENUTZERNAME
Der Benutzername (Anmeldename) von GitHub wird in der Konfigurationsvariablen gespeichert
hub.Benutzername. Wenn eine E-Mail-Adresse angegeben ist, dann ein Benutzername, der dieser E-Mail-Adresse entspricht
wird gesucht und stattdessen verwendet, wenn sie gefunden wird (damit die E-Mail funktioniert).
muss Teil des öffentlichen Profils sein).

-p PASSWORT, --password=PASSWORT
GitHub-Passwort (wird nicht gespeichert).

-b URL, --baseurl=URL
Die Basis-URL von GitHub für den Zugriff auf die API. Legen Sie dies fest, wenn Sie die GitHub-API verwenden
an einem anderen Ort als dem Standardspeicherort (Unternehmensserver verwenden normalerweise
https://host/api/v3).

- global
Speichern Sie die Einstellungen in der globalen Konfiguration (siehe Option --global in git
Config(1) für Details).

--System
Speichern Sie die Einstellungen in der Systemkonfiguration (siehe Option --system in git
Config(1) für Details).

klonen REPO [ZIEL]
Dieser Befehl wird zum Klonen verwendet REPO, ein GitHub-Repository, zu a ZIEL Verzeichnis
(Standardmäßig ist der Name des Projekts, das geklont wird). Wenn das Repository angegeben ist
in / bilde die REPO wird als Upstream und als persönlicher Fork verwendet
wird nachgeschaut. Wenn keine gefunden wird, wird ein neuer Fork erstellt. In beiden Fällen ist die
Fork wird anstelle des Upstream-Repositorys geklont.

Wenn nur wird angegeben als REPO, dann die Konfiguration hub.Benutzername verwendet wird
as , und das übergeordnete Repository wird auf GitHub nachgeschlagen, um das Original zu ermitteln
vorgelagertes Repository.

Das Upstream-Repository wird mit dem Namen auch als Remote-Repository hinzugefügt flussaufwärts (es sei denn
--dreieckig wird verwendet, in diesem Fall wird die Fernbedienung aufgerufen Gabel standardmäßig) und die
hub.upstream Konfigurationsvariable gesetzt ist (siehe CONFIGURATION), es sei denn nur
wurde verwendet und das resultierende Repository ist in diesem Fall nicht wirklich ein Fork
Es ist nicht möglich, das Upstream-Repository automatisch zu ermitteln.

-r NAME, --remote=NAME
Nutzen Sie NAME/FUNKTION als Upstream-Remote-Repository-Name anstelle des Standardnamens
('Gabel' wenn --dreieckig verwendet wird, andernfalls 'upstream').

-T, --dreieckig
Verwenden Sie Gits dreieckig Arbeitsablauf. Aufbau. Diese Option klont aus dem
übergeordnetes/Upstream-Repository, anstatt den Fork zu klonen, und fügt den Fork als hinzu
ein Remote-Repository. Dann setzt man die remote.pushdefault Git-Option und
hub.forkremote Git-Hub-Option für den Fork.

Dies hat zur Folge, dass das Upstream-Repository standardmäßig verwendet wird, wenn Sie
Ziehen Sie, aber verwenden Sie zum Schieben die Gabel, was normalerweise das ist, was Sie wollen
bei Verwendung der Pull-Requests von GitHub.

Zur Verwendung dieser Option ist Git-Version 1.8.3 oder neuer (und 1.8.4 oder neuer) erforderlich
wird aufgrund einiger diesbezüglicher Probleme in 1.8.3 empfohlen.

Diese Option könnte in Zukunft zur Standardeinstellung werden. Um es zur Standardeinstellung zu machen
Sie können die Option festlegen Nabe.dreieckig. Sehen CONFIGURATION .

GIT CLONE OPTIONAL
Jeder Standard git klonen Option kann übergeben werden. Möglicherweise schaffen es nicht alle
Dies ist jedoch sinnvoll, wenn Sie ein GitHub-Repo klonen, um es mit diesem Tool zu verwenden.

Problem Dieser Befehl wird verwendet, um GitHub-Probleme über eine Reihe von Unterbefehlen zu verwalten. Ist nein
Unterbefehl angegeben ist, Liste wird eingesetzt.

Liste Zeigt eine Liste offener Probleme an.

-C, --abgeschlossen
Stattdessen werden geschlossene Probleme angezeigt.

-VS, --von mir erstellt
Nur von mir erstellte Probleme anzeigen

-EIN, --Mir zugewiesen
Nur mir zugewiesene Probleme anzeigen

erklären PROBLEM [AUSGABE ...]
Von identifizierte Probleme anzeigen PROBLEM.

neu Erstellen Sie ein neues Problem.

-m NACHRICHT, --message=MSG
Titel (und Beschreibung) der Ausgabe. Als Problem wird die erste Zeile verwendet
Der Titel und der Text nach einer Leerzeile werden als optionaler Textkörper verwendet.
Wenn diese Option nicht verwendet wird, ist die Standardeinstellung GIT_EDITOR wird zum Schreiben geöffnet
eins.

-l ETIKETT, --label=LABEL
Anfügen LABEL zum Problem (kann zum Festlegen mehrmals angegeben werden).
mehrere Etiketten).

-a BENUTZER, --assign=BENUTZER
Weisen Sie dem Problem einen Benutzer zu. USER muss ein gültiger GitHub-Anmeldename sein.

-M ID, --milestone=ID
Ordnen Sie dem Problem den durch die Nummern-ID identifizierten Meilenstein zu.

Aktualisierung PROBLEM
Ähnlich neu aber aktualisieren Sie ein bestehendes Problem, das von identifiziert wurde PROBLEM.

Eine praktische Verknüpfung zum Schließen eines Problems bietet die schließen Unterbefehl.

-m NACHRICHT, --message=MSG
Titel (und Beschreibung) der neuen Ausgabe. Die erste Zeile wird als verwendet
Der Titel der Ausgabe und der Text nach einer Leerzeile werden optional verwendet
Körper.

-e, --edit-message
Öffnen Sie die Standardeinstellung GIT_EDITOR um den aktuellen Titel zu bearbeiten (und
Beschreibung des Problems.

-Ö, --offen
Öffnen Sie das Problem erneut.

-C, --schließen
Schließen Sie das Problem.

-l ETIKETT, --label=LABEL
Wenn ein oder mehrere Labels angegeben werden, ersetzen diese das aktuelle
Etiketten ausstellen. Ansonsten bleiben die Beschriftungen unverändert. Wenn einer der
Etiketten leer ist, werden die Etiketten gelöscht (damit Sie sie verwenden können). -l'' zu
Löschen Sie die Etiketten eines Problems.

-a BENUTZER, --assign=BENUTZER
Weisen Sie dem Problem einen Benutzer zu. USER muss ein gültiger GitHub-Anmeldename sein.

-M ID, --milestone=ID
Ordnen Sie dem Problem den durch die Nummern-ID identifizierten Meilenstein zu.

Kommentar PROBLEM
Fügen Sie einen neuen Kommentar zu einem vorhandenen Problem hinzu, das von identifiziert wurde PROBLEM.

-m NACHRICHT, --message=MSG
Kommentar, der dem Problem hinzugefügt werden soll. Wenn diese Option nicht verwendet wird, wird die
Standard GIT_EDITOR wird geöffnet, um den Kommentar zu schreiben.

schließen PROBLEM
Alias ​​für Aktualisierung --schließen. (+ Kommentar if --Botschaft or --edit-message is
angegeben). Schließt das von identifizierte Problem PROBLEM.

-m NACHRICHT, --message=MSG
Fügen Sie einen Kommentar zum Problem hinzu, bevor Sie es schließen.

-e, --edit-message
Öffnen Sie die Standardeinstellung GIT_EDITOR um einen Kommentar zu schreiben, der dem hinzugefügt werden soll
Problem, bevor Sie es schließen.

ziehen Dieser Befehl wird zum Verwalten von GitHub-Pull-Anfragen verwendet. Da Pull-Requests in GitHub
Es gibt auch Probleme, die meisten Unterbefehle werden aus dem wiederholt Problem Befehl für
Bequemlichkeit. Nur der Liste und neu Befehle sind wirklich unterschiedlich, und anhängen und
zurückweisen sind hinzugefügt.

Liste Zeigt eine Liste offener Pull-Anfragen an.

--abgeschlossen
Stattdessen werden geschlossene Pull-Anfragen angezeigt.

erklären PULL [ZIEHEN ...]
Alias ​​für Problem erklären.

Kasse PULL ...
Checken Sie den Remote-Zweig (Kopf) der Pull-Anfrage aus. Dieser Befehl zuerst
holt die ganzer Referenz aus der Pull-Anfrage und ruft dann den Standard auf
git Kasse Befehl und alle zusätzlichen Argumente werden an übergeben git Kasse
wie es ist, nach der Referenz, die gerade abgerufen wurde. Denken Sie daran, dass dadurch ein erstellt wird
Standardmäßig getrennte Kasse verwenden -b wenn Sie einen neuen Zweig erstellen möchten
basierend auf der Pull-Anfrage. Bitte werfen Sie einen Blick darauf git Kasse Hilfe für mehr
Details.

neu [KOPF]
Erstellen Sie eine neue Pull-Anfrage. Wenn KOPF angegeben wird, wird es als verwendet
Zweig (oder Git-Referenz), in dem Ihre Änderungen implementiert werden. Ansonsten der
Der aktuelle Zweig wird verwendet. Wenn der als Kopf verwendete Ast nicht auf Ihren geschoben wird
Bei der Gabelfernbedienung wird automatisch ein Push ausgeführt, bevor der Pull erzeugt wird
anfordern.

Das Repository, aus dem der Pull-Request ausgegeben werden soll, wird dem entnommen hub.forkrepo
Konfiguration, die standardmäßig auf ist hub.Benutzername/ Projekt teilen>.

-m NACHRICHT, --message=MSG
Titel (und Beschreibung) der Pull-Anfrage. Die erste Zeile wird als verwendet
Der Pull-Request-Titel und jeglicher Text nach einer Leerzeile werden als verwendet
optionaler Körper. Wenn diese Option nicht verwendet wird, ist die Standardeinstellung GIT_EDITOR is
geöffnet. Wenn der HEAD-Zweig eine korrekte Beschreibung hat (siehe git Filiale
--Beschreibung bearbeiten), wird diese Beschreibung als Standard verwendet
Nachricht im Editor und wenn nicht, wird die Nachricht des letzten Commits angezeigt
stattdessen verwendet werden.

-b BASIC, --base=BASIS
Zweig (oder Git-Referenz), in den Ihre Änderungen übernommen werden sollen. Standardmäßig ist die
Tracking-Zweig (Zweig. .verschmelzen Konfigurationsvariable) verwendet wird
oder die Konfiguration hub.pullbase wenn kein Remote-Zweig verfolgt wird. Wenn
Wenn keine vorhanden ist, wird standardmäßig darauf zurückgegriffen führen zu. Das Repository, das als verwendet werden soll
Die Basis stammt aus der hub.upstream Konfiguration.

-c NAME, --create-branch=NAME
Erstellen Sie einen neuen Remote-Zweig mit (mit Namen NAME/FUNKTION) als der wahre Kopf für
die Pull-Anfrage, anstatt den übergebenen HEAD-Namen zu verwenden KOPF. Dies
ist nützlich, um eine Pull-Anfrage für einen Hotfix zu erstellen, zu dem Sie sich verpflichtet haben
Ihren regulären HEAD, ohne vorher einen Zweig zu erstellen.

-F, --force-push
Erzwingen Sie die Push-Vorgänge. Mit Vorsicht verwenden!

anhängen PROBLEM [KOPF]
Konvertieren Sie das von identifizierte Problem PROBLEM zu einer Pull-Anfrage hinzufügen, indem Sie Commits anhängen
dazu. Der Zweig (oder die Git-Referenz), in dem Ihre Änderungen implementiert werden, kann sein
optional angegeben mit KOPF (Andernfalls wird der aktuelle Zweig verwendet). Das
Der Unterbefehl ist dem sehr ähnlich neu Unterbefehl, bitte beziehen Sie sich darauf
mehr Details.

Bitte beachten Sie, dass Sie Commits nur dann an Issues anhängen können, wenn Sie über Commit-Zugriff verfügen
dem Repository hinzugefügt oder wenn Sie dem Problem zugeordnet sind.

-m NACHRICHT, --message=MSG
Fügen Sie einen Kommentar zum Issue/neuen Pull-Request hinzu.

-e, --edit-message
Öffnen Sie die Standardeinstellung GIT_EDITOR um einen Kommentar zu schreiben, der dem hinzugefügt werden soll
Ausgabe/neue Pull-Anfrage. Die Standardnachricht stammt aus dem
--Botschaft Option, falls vorhanden, andernfalls die Zweigbeschreibung oder die
Die erste Commit-Nachricht wird wie bei verwendet neu Unterbefehl.

-b BASIC, --base=BASIS
Basiszweig, an den die Pull-Anfrage gesendet wird. Wenn diese Option nicht vorhanden ist
vorhanden, dann wird der Basiszweig aus der Konfiguration übernommen
hub.pullbase (oder nur führen zu wenn diese Konfiguration nicht vorhanden ist
entweder). Das als Basis zu verwendende Repository wird aus dem entnommen
hub.upstream Konfiguration.

-c NAME, --create-branch=NAME
Erstellen Sie einen neuen Remote-Zweig mit (mit Namen NAME/FUNKTION) als der wahre Kopf für
die Pull-Anfrage, anstatt den übergebenen HEAD-Namen zu verwenden KOPF. Dies
ist nützlich, um eine Pull-Anfrage für einen Hotfix zu erstellen, zu dem Sie sich verpflichtet haben
Ihren regulären HEAD, ohne vorher einen Zweig zu erstellen.

-F, --force-push
Erzwingen Sie die Push-Vorgänge. Mit Vorsicht verwenden!

zurückweisen PULL
Schließen Sie eine Pull-Anfrage, die durch identifiziert wurde PULL durch Neubasierung seines Basiszweigs
(in der Pull-Anfrage angegeben) anstatt als GitHubs zusammenzuführen Merge Button™
würdest du.

Wenn der Vorgang erfolgreich ist, wird ein Kommentar veröffentlicht, der den Neuen darüber informiert
HEAD-Commit des Zweigs, der neu basiert wurde, und die Pull-Anfrage werden ausgeführt
geschlossen.

Der Typ der zum Abrufen und Pushen verwendeten URL kann über angegeben werden
hub.pullurltype Konfigurationsvariable (siehe CONFIGURATION für mehr Details).
Ihre Arbeitskopie sollte im Idealfall gleich bleiben, wenn alles gut gelaufen ist.

Die von diesem Unterbefehl ausgeführten Operationen sind ungefähr die folgenden:

1. Git-Stash

2. Git-Abruf Zugkopf

3. git checkout -b tmp FETCH_HEAD

4. git pull --rebase Pullbase

5. Git-Push Pullbase

6. Git-Checkout alter Kopf

7. Git-Zweig -D tmp

8. Git Stash Pop

If hub.forcerebase ist auf „true“ (Standard) gesetzt, --Macht wird weitergegeben an
rebase (nicht zu verwechseln mit dieser Befehlsoption --force-push welches wird
den Push erzwingen), andernfalls (wenn „false“ ist) wird ein regulärer Rebase durchgeführt.
Wenn das Rebase erzwungen wird, werden alle Commits in der Pull-Anfrage erzwungen
erneut festgeschrieben, sodass die Metadaten „Committer“ und „CommitterDate“ im aktualisiert werden
Commits, die die Person anzeigen, die das Rebase durchgeführt hat, und den Zeitpunkt des
rebase anstelle der ursprünglichen Werte, um so nützlichere Informationen bereitzustellen.
Als Nebeneffekt ändern sich die Hashes der Commits.

Wenn Konflikte gefunden werden, wird der Befehl auf ähnliche Weise unterbrochen git
zurückweisen würdest du. Der Benutzer sollte entweder --abbrechen die Umbasierung, --überspringen die
widersprüchlich begehen oder lösen Sie den Konflikt und --fortsetzen. Bei Verwendung eines von
Diese Aktionen müssen Sie unterlassen PULL Argument.

-m NACHRICHT, --message=MSG
Verwenden Sie diese Nachricht anstelle der Standardnachricht für den Kommentar. Geben Sie eine an
leere Nachricht (-M''), um den Kommentar komplett wegzulassen.

-e, --edit-message
Öffnen Sie die Standardeinstellung GIT_EDITOR um den Kommentar zu schreiben.

--force-push
Erzwingen Sie die Push-Vorgänge. Mit Vorsicht verwenden!

-P, --Pause
Unterbrechen Sie die Rebase, kurz bevor die Ergebnisse übertragen werden und das Problem behoben ist
zusammengeführt. Um das Pull-Rebasing der Anforderung fortzusetzen (Änderungen übertragen).
upstream und schließen Sie das Problem), verwenden Sie einfach die --fortsetzen Aktion. Das
ist besonders zum Testen nützlich.

-du, --stash-include-untracked
Passiert die --include-untracked Option zum Verstauen. Bei Gebrauch alles ohne Spur
Dateien werden ebenfalls zwischengespeichert und dann mit git clean bereinigt, so dass übrig bleibt
das Arbeitsverzeichnis in einem sehr sauberen Zustand, wodurch Konflikte vermieden werden
beim Auschecken der Pull-Anfrage zum Rebase.

-a, --stash-all
Passiert die --alle Option zum Verstauen. Ist wie --stash-include-untracked
aber die ignorierten Dateien werden zusätzlich zu den Dateien zwischengespeichert und bereinigt
nicht verfolgte Dateien, wodurch die Möglichkeit vollständig ausgeschlossen ist
Konflikte beim Auschecken der Pull-Anfrage zum Rebase.

-D, --delete-branch
Löschen Sie den Pull-Request-Zweig, wenn das Rebase erfolgreich war. Das ist
Ähnlich wie das Klicken auf die Schaltfläche „Zweig löschen“ (TM) in der Weboberfläche
nach der Fusion.

Aktionen:

--fortsetzen
Setzen Sie eine laufende Rebase fort.

--abbrechen
Brechen Sie eine laufende Rebase ab.

--überspringen Überspringen Sie den aktuellen Patch in einem laufenden Rebase und fahren Sie fort.

Aktualisierung PULL
Alias ​​für Problem Aktualisierung.

Kommentar PULL
Alias ​​für Problem Kommentar.

schließen PULL
Alias ​​für Problem schließen.

CONFIGURATION

Dieses Programm verwendet die Git-Konfigurationsfunktionen, um seine Konfiguration abzurufen. Diese sind
Die verwendeten Git-Konfigurationsschlüssel:

hub.Benutzername
Ihr GitHub-Benutzername. [Standard: Strom OS Benutzername]

hub.oauthtoken falls angefordert
Dies ist das über den erhaltene Autorisierungstoken -Setup Befehl. Auch wenn es erforderlich ist,
Sie sollten diese Variable nicht manuell festlegen müssen. Benutzen Sie die -Setup Befehl stattdessen.

hub.upstream falls angefordert
Gesegnetes Repository, das zum Abrufen der Issues und zum Senden der Pull-Anfragen verwendet wird. Der
Format ist /. Diese Option kann vom automatisch eingestellt werden klonen
Befehl und wird von ihm oder dem nicht wirklich benötigt -Setup Befehl.

hub.forkrepo
Dein gesegneter Repository-Fork. Das Format ist /. Wird zum Einstellen des Kopfes verwendet
für Ihre Pull-Anfragen. [Standard: /(stromaufwärts Aktie)]

hub.forkremote
Remote-Name für den Zugriff auf Ihren Fork. Wird verwendet, um Zweige zu schieben, bevor ein Pull erstellt wird
Anfrage. [Standard: Herkunft]

hub.pullbase
Standard-Remote-Zweig (oder Git-Referenz), in den Ihre Änderungen wann übernommen werden sollen
Erstellen einer Pull-Anfrage. [Standard: führen zu]

hub.urltype
URL-Typ, der verwendet werden soll, wenn eine URL von einer GitHub-API benötigt wird (z. B. wenn „pull
rebase‘ verwendet wird). Zum Zeitpunkt des Schreibens könnte es so sein ssh_url or clone_url für
HTTP). Weitere Details oder Optionen finden Sie in der API-Dokumentation von GitHub[1]. [Standard:
ssh_url]

hub.baseurl
Die Basis-URL von GitHub für den Zugriff auf die API. Legen Sie dies fest, wenn Ihre GitHub-API aktiviert ist
einen anderen Speicherort als den Standardspeicherort (Unternehmensserver verwenden ihn normalerweise).
https://host/api/v3). Dies wird allen GitHub-API-Aufrufen vorangestellt und muss dies auch tun
eine vollständige URL sein, nicht nur etwas wie „www.example.com/api/v3/“.

hub.forcerebase
Wenn auf „true“ gesetzt ist, --Macht wird an rebase übergeben. Wenn auf „false“ gesetzt ist a
Es wird ein regelmäßiger Rebase durchgeführt. Siehe die ziehen zurückweisen Befehl für Details. [Standard:
was immer dies auch sein sollte.]

Nabe.dreieckig
Macht --dreieckig für klonen wenn auf „true“ (boolescher Wert) gesetzt. Sehen klonen
Dokumentation für Details.

[1] https://developer.github.com/v3/pulls/#get-a-single-pull-request

Nutzen Sie Git-Hub online über die Dienste von onworks.net