git – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

git – der blöde Content-Tracker

ZUSAMMENFASSUNG

git [--version] [--help] [-C ] [-C = ]
[--exec-path[= ]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir= ] [--work-tree= ] [--namespace= ]
[ ]

BESCHREIBUNG

Git ist ein schnelles, skalierbares, verteiltes Revisionskontrollsystem mit einer ungewöhnlich umfangreichen Funktionalität
Befehlssatz, der sowohl Operationen auf hoher Ebene als auch vollen Zugriff auf Interna bietet.

See Gittutorial(7) Um zu beginnen, dann sehen Sie giteveryday(7) für einen nützlichen Mindestsatz von
Befehle. Das Git Benutzer Manuell[1] enthält eine ausführlichere Einführung.

Nachdem Sie die Grundkonzepte gemeistert haben, können Sie auf diese Seite zurückkehren, um zu erfahren, was
Befehle, die Git anbietet. Mehr über einzelne Git-Befehle erfahren Sie mit „git help“.
Befehl". gitcli(7) Die Handbuchseite gibt Ihnen einen Überblick über die Befehlszeilen-Befehlssyntax.

Die formatierte und mit einem Hyperlink versehene Version der neuesten Git-Dokumentation kann unter eingesehen werden
http://git-htmldocs.googlecode.com/git/git.html.

OPTIONAL

--Version
Druckt die Git-Suite-Version, die die git Programm kam von.

--help
Druckt die Zusammenfassung und eine Liste der am häufigsten verwendeten Befehle. Wenn die Option --alle
or -a gegeben ist, werden alle verfügbaren Befehle ausgegeben. Wenn ein Git-Befehl diesen Namen trägt
Mit dieser Option wird die Handbuchseite für diesen Befehl angezeigt.

Es stehen weitere Optionen zur Verfügung, um zu steuern, wie die Handbuchseite angezeigt wird. Sehen Git-
Hilfe(1) für weitere Informationen, da git --help ... intern in git konvertiert wird
helfen ....

-C
Führen Sie aus, als ob Git gestartet wäre anstelle des aktuellen Arbeitsverzeichnisses. Wann
Es werden mehrere -C-Optionen angegeben, wobei jedes weitere nicht absolute -C ist interpretiert wird
relativ zum vorhergehenden -C .

Diese Option betrifft Optionen, die Pfadnamen wie --git-dir und --work-tree erwarten
dass ihre Interpretationen der Pfadnamen relativ zur Arbeitsweise erfolgen würden
Verzeichnis, das durch die Option -C verursacht wird. Zum Beispiel sind die folgenden Aufrufe
Äquivalent:

git --git-dir=a.git --work-tree=b -C c Status
git --git-dir=c/a.git --work-tree=c/b Status

-C =
Übergeben Sie einen Konfigurationsparameter an den Befehl. Der angegebene Wert überschreibt die Werte
aus Konfigurationsdateien. Der wird im gleichen Format erwartet wie von aufgeführt git
Config (Unterschlüssel durch Punkte getrennt).

Beachten Sie, dass das Weglassen von = in git -c foo.bar ... zulässig ist und foo.bar auf den setzt
boolescher wahrer Wert (genau wie [foo]bar es in einer Konfigurationsdatei tun würde). Einschließlich der Gleichen
aber mit einem leeren Wert (wie git -c foo.bar= ...) wird foo.bar auf den leeren String gesetzt.

--exec-path[= ]
Pfad zu dem Ort, an dem Ihre Git-Kernprogramme installiert sind. Dies kann auch gesteuert werden durch
Festlegen der Umgebungsvariablen GIT_EXEC_PATH. Wenn kein Pfad angegeben ist, git wird gedruckt
die aktuelle Einstellung und beenden Sie den Vorgang.

--html-pfad
Geben Sie den Pfad ohne abschließenden Schrägstrich aus, in dem die HTML-Dokumentation von Git installiert ist
und verlassen.

--man-path
Drucken Sie den Manpath aus (siehe Mann(1)) für die Manpages für diese Version von Git und Exit.

--info-pfad
Geben Sie den Pfad aus, in dem die Infodateien installiert sind, die diese Version von Git dokumentieren
Ausfahrt.

-p, --paginate
Leiten Sie die gesamte Ausgabe weiter weniger (oder falls festgelegt, $PAGER), wenn die Standardausgabe ein Terminal ist. Das
überschreibt den Pager. Konfigurationsoptionen (siehe „Konfigurationsmechanismus“)
Abschnitt unten).

--kein-Pager
Leiten Sie die Git-Ausgabe nicht an einen Pager weiter.

--git-dir=
Legen Sie den Pfad zum Repository fest. Dies kann auch durch Setzen des GIT_DIR gesteuert werden
Umgebungsvariable. Es kann ein absoluter Pfad oder ein relativer Pfad zur aktuellen Arbeitsumgebung sein
Verzeichnis.

--work-tree=
Legen Sie den Pfad zum Arbeitsbaum fest. Es kann ein absoluter Pfad oder ein relativer Pfad sein
aktuelles Arbeitsverzeichnis. Dies kann auch durch Setzen des GIT_WORK_TREE gesteuert werden
Umgebungsvariable und die Konfigurationsvariable core.worktree (siehe core.worktree
in git-config(1) für eine detailliertere Diskussion).

--namespace=
Legen Sie den Git-Namespace fest. Sehen gitnamespaces(7) für weitere Einzelheiten. Entspricht Einstellung
die Umgebungsvariable GIT_NAMESPACE.

--blank
Behandeln Sie das Repository als bloßes Repository. Wenn die GIT_DIR-Umgebung nicht festgelegt ist, ist dies der Fall
auf das aktuelle Arbeitsverzeichnis setzen.

--no-replace-objects
Verwenden Sie keine Ersatzreferenzen, um Git-Objekte zu ersetzen. Sehen git-replace(1) für mehr
Informationen.

--literal-pathspecs
Behandeln Sie Pfadspezifikationen wörtlich (dh kein Globbing, keine Pfadspezifikationsmagie). Dies entspricht
Setzen der Umgebungsvariablen GIT_LITERAL_PATHSPECS auf 1.

--glob-pathspecs
Füge „Glob“-Magie zu allen Pfadspezifikationen hinzu. Dies entspricht dem Festlegen von GIT_GLOB_PATHSPECS
Umgebungsvariable auf 1 setzen. Das Deaktivieren des Globbings für einzelne Pfadspezifikationen ist möglich
Verwenden von Pathspec-Magie „:(literal)“

--noglob-pathspecs
Fügen Sie allen Pfadspezifikationen „wörtliche“ Magie hinzu. Dies entspricht dem Festlegen von
GIT_NOGLOB_PATHSPECS Umgebungsvariable auf 1. Globbing für Einzelpersonen aktivieren
Pfadspezifikationen können mit der Pfadspezifikationsmagie „:(glob)“ erstellt werden.

--icase-pathspecs
Füge „icase“-Magie zu allen Pfadspezifikationen hinzu. Dies entspricht dem Festlegen von
GIT_ICASE_PATHSPECS Umgebungsvariable auf 1.

GIT BEFEHLE

Wir unterteilen Git in High-Level-Befehle („Porcelain“) und Low-Level-Befehle („Plumbing“).

HOHES LEVEL BEFEHLE (PORZELLAN)

Wir unterteilen die Porzellanbefehle in die Hauptbefehle und einige untergeordnete Benutzerbefehle
Dienstprogramme.

Main Porzellan Befehle
git-add(1)
Dateiinhalte zum Index hinzufügen.

Idiot(1)
Wenden Sie eine Reihe von Patches aus einer Mailbox an.

git-archiv(1)
Erstellen Sie ein Archiv mit Dateien aus einem benannten Baum.

git-bisect(1)
Verwenden Sie die binäre Suche, um den Commit zu finden, der einen Fehler verursacht hat.

Git-Zweig(1)
Zweige auflisten, erstellen oder löschen.

Git-Bundle(1)
Verschieben Sie Objekte und Referenzen nach Archiv.

Git-Checkout(1)
Wechseln Sie Zweige oder stellen Sie funktionierende Baumdateien wieder her.

Git-Cherry-Pick(1)
Wenden Sie die von einigen vorhandenen Commits eingeführten Änderungen an.

git-citool(1)
Grafische Alternative zu Git-Commit.

git-sauber(1)
Entfernen Sie nicht verfolgte Dateien aus dem Arbeitsbaum.

Git-Klon(1)
Klonen Sie ein Repository in ein neues Verzeichnis.

Git-Commit(1)
Zeichnen Sie Änderungen am Repository auf.

git-describe(1)
Beschreiben Sie einen Commit mit dem aktuellsten Tag, der von ihm aus erreichbar ist.

git-diff(1)
Änderungen zwischen Commits, Commit und Arbeitsbaum usw. anzeigen.

git-holen(1)
Laden Sie Objekte und Referenzen aus einem anderen Repository herunter.

Git-Format-Patch(1)
Bereiten Sie Patches für die E-Mail-Übermittlung vor.

git-gc(1)
Bereinigen Sie unnötige Dateien und optimieren Sie das lokale Repository.

git-grep(1)
Drucken Sie Linien, die einem Muster entsprechen.

Git-GUI(1)
Eine tragbare grafische Schnittstelle zu Git.

git-init(1)
Erstellen Sie ein leeres Git-Repository oder initialisieren Sie ein vorhandenes neu.

Git-Log(1)
Commit-Protokolle anzeigen.

Git-Merge(1)
Verbinden Sie zwei oder mehr Entwicklungsgeschichten miteinander.

git-mv(1)
Verschieben oder benennen Sie eine Datei, ein Verzeichnis oder einen Symlink um.

Git-Notizen(1)
Fügen Sie Objektnotizen hinzu oder überprüfen Sie sie.

git-ziehen(1)
Von einem anderen Repository oder einem lokalen Zweig abrufen und integrieren.

Git-Push(1)
Aktualisieren Sie Remote-Referenzen zusammen mit den zugehörigen Objekten.

Git-Rebase(1)
Lokale Commits des Forward-Ports an den aktualisierten Upstream-Head.

Git-Reset(1)
Setzt den aktuellen HEAD auf den angegebenen Zustand zurück.

git-revert(1)
Setzen Sie einige vorhandene Commits zurück.

git-rm(1)
Entfernen Sie Dateien aus dem Arbeitsbaum und aus dem Index.

git-kurzlog(1)
Zusammenfassen git Log Ausgabe.

Git-Show(1)
Zeigen Sie verschiedene Arten von Objekten an.

Git-Stash(1)
Speichern Sie die Änderungen in einem schmutzigen Arbeitsverzeichnis.

Git-Status(1)
Zeigt den Status des Arbeitsbaums an.

git-submodul(1)
Submodule initialisieren, aktualisieren oder überprüfen.

Git-Tag(1)
Erstellen, listen, löschen oder überprüfen Sie ein mit GPG signiertes Tag-Objekt.

Git-Worktree(1)
Verwalten Sie mehrere Arbeitsbäume.

Idiot(1)
Der Git-Repository-Browser.

Neben- Befehle
Manipulatoren:

git-config(1)
Rufen Sie Repository- oder globale Optionen ab und legen Sie diese fest.

git-schnell-export(1)
Git-Datenexporteur.

Git-Fast-Import(1)
Backend für schnelle Git-Datenimporteure.

git-filter-Zweig(1)
Zweige neu schreiben.

Git-Mergetool(1)
Führen Sie Tools zur Lösung von Zusammenführungskonflikten aus, um Zusammenführungskonflikte zu lösen.

git-pack-refs(1)
Packen Sie Köpfe und Tags für einen effizienten Repository-Zugriff.

git-prune(1)
Entfernen Sie alle nicht erreichbaren Objekte aus der Objektdatenbank.

git-reflog(1)
Reflog-Informationen verwalten.

Git-Relink(1)
Verknüpfen Sie gemeinsame Objekte in lokalen Repositorys fest.

Git-Remote(1)
Verwalten Sie eine Reihe von verfolgten Repositorys.

git-repack(1)
Packen Sie entpackte Objekte in ein Repository.

git-replace(1)
Referenzen erstellen, auflisten und löschen, um Objekte zu ersetzen.

Vernehmer:

git-annotate(1)
Kommentieren Sie Dateizeilen mit Commit-Informationen.

git-Schuld(1)
Zeigen Sie an, welche Revision und welcher Autor jede Zeile einer Datei zuletzt geändert hat.

kirsche(1)
Finden Sie Commits, die noch auf den Upstream angewendet werden müssen.

Git-Count-Objekte(1)
Zählen Sie die entpackte Anzahl der Objekte und deren Festplattenverbrauch.

git-difftool(1)
Zeigen Sie Änderungen mit gängigen Diff-Tools an.

git-fsck(1)
Überprüft die Konnektivität und Gültigkeit der Objekte in der Datenbank.

git-get-tar-commit-id(1)
Extrahieren Sie die Commit-ID aus einem Archiv, das mit git-archive erstellt wurde.

Git-Hilfe(1)
Hilfeinformationen zu Git anzeigen.

git-instaweb(1)
Durchsuchen Sie sofort Ihr Arbeits-Repository in Gitweb.

Git-Merge-Baum(1)
Drei-Wege-Zusammenführung anzeigen, ohne den Index zu berühren.

git-rerere(1)
Wiederverwendung der aufgezeichneten Lösung von Konfliktzusammenführungen.

git-rev-parse(1)
Parameter auswählen und massieren.

Git-Show-Zweig(1)
Zweige und ihre Commits anzeigen.

git-verify-commit(1)
Überprüfen Sie die GPG-Signatur von Commits.

git-verify-tag(1)
Überprüfen Sie die GPG-Signatur von Tags.

git-whatchanged(1)
Zeigt Protokolle mit Unterschieden an, die jeder Commit mit sich bringt.

Gitweb(1)
Git-Webschnittstelle (Web-Frontend zu Git-Repositorys).

Interaktion mit Anders
Diese Befehle dienen der Interaktion mit fremden SCMs und anderen Personen per Patch-Over
E-Mail-Adresse.

git-archimport(1)
Importieren Sie ein Arch-Repository in Git.

git-cvsexportcommit(1)
Exportieren Sie einen einzelnen Commit in einen CVS-Checkout.

git-cvsimport(1)
Retten Sie Ihre Daten aus einem anderen SCM, das die Leute gerne hassen.

git-cvsserver(1)
Ein CVS-Server-Emulator für Git.

git-imap-send(1)
Senden Sie eine Sammlung von Patches von stdin an einen IMAP-Ordner.

git-p4(1)
Import aus und Übermittlung an Perforce-Repositorys.

Git-Quiltimport(1)
Wendet ein Quilt-Patchset auf den aktuellen Zweig an.

Git-Request-Pull(1)
Erstellt eine Zusammenfassung der ausstehenden Änderungen.

git-send-email(1)
Senden Sie eine Sammlung von Patches als E-Mails.

git-svn(1)
Bidirektionaler Betrieb zwischen einem Subversion-Repository und Git.

NIEDRIGES NIVEAU BEFEHLE (INSTALLATION)

Obwohl Git über eine eigene Porzellanschicht verfügt, reichen die Befehle auf niedriger Ebene dafür aus
Unterstützung der Entwicklung alternativer Porzellane. Entwickler solcher Porzellane könnten beginnen
indem man darüber liest Git-Update-Index(1) und Git-Read-Tree(1).

Die Schnittstelle (Eingabe, Ausgabe, Optionssatz und Semantik) zu diesen Low-Level
Befehle sollen viel stabiler sein als Befehle auf Porzellanebene, weil diese
Befehle dienen in erster Linie der skriptgesteuerten Verwendung. Zum anderen die Schnittstelle zu Porcelain-Befehlen
Änderungen vorbehalten, um das Endbenutzererlebnis zu verbessern.

Die folgende Beschreibung unterteilt die Low-Level-Befehle in manipulierende Befehle
Objekte (im Repository, Index und Arbeitsbaum), Befehle, die abfragen und
Vergleichen Sie Objekte und Befehle, die Objekte und Referenzen zwischen Repositorys verschieben.

Manipulation Befehle
git-apply(1)
Wenden Sie einen Patch auf Dateien und/oder auf den Index an.

Git-Checkout-Index(1)
Kopieren Sie Dateien aus dem Index in den Arbeitsbaum.

Git-Commit-Baum(1)
Erstellen Sie ein neues Commit-Objekt.

Git-Hash-Objekt(1)
Berechnet die Objekt-ID und erstellt optional einen Blob aus einer Datei.

Git-Index-Pack(1)
Erstellen Sie eine Pack-Indexdatei für ein vorhandenes gepacktes Archiv.

Git-Merge-Datei(1)
Führen Sie eine Drei-Wege-Dateizusammenführung durch.

Git-Merge-Index(1)
Führen Sie eine Zusammenführung für Dateien durch, die zusammengeführt werden müssen.

git-mktag(1)
Erstellt ein Tag-Objekt.

git-mktree(1)
Erstellen Sie ein Baumobjekt aus ls-tree-formatiertem Text.

Git-Pack-Objekte(1)
Erstellen Sie ein gepacktes Objektarchiv.

Git-Prune-verpackt(1)
Entfernen Sie zusätzliche Objekte, die bereits in Packdateien enthalten sind.

Git-Read-Tree(1)
Liest Bauminformationen in den Index.

git-symbolic-ref(1)
Symbolische Referenzen lesen, ändern und löschen.

git-unpack-objects(1)
Entpacken Sie Objekte aus einem gepackten Archiv.

Git-Update-Index(1)
Registrieren Sie Dateiinhalte im Arbeitsbaum im Index.

git-update-ref(1)
Aktualisieren Sie den in einer Referenz gespeicherten Objektnamen sicher.

Git-Write-Tree(1)
Erstellen Sie ein Baumobjekt aus dem aktuellen Index.

Verhör Befehle
Git-Cat-Datei(1)
Geben Sie Inhalts- oder Typ- und Größeninformationen für Repository-Objekte an.

Git-Diff-Dateien(1)
Vergleicht Dateien im Arbeitsbaum und im Index.

Git-Diff-Index(1)
Vergleichen Sie einen Baum mit dem Arbeitsbaum oder Index.

Git-Diff-Baum(1)
Vergleicht den Inhalt und Modus von Blobs, die über zwei Baumobjekte gefunden wurden.

git-für-jede-ref(1)
Ausgabeinformationen zu jeder Referenz.

Git-LS-Dateien(1)
Informationen zu Dateien im Index und im Arbeitsbaum anzeigen.

git-ls-remote(1)
Referenzen in einem Remote-Repository auflisten.

git-ls-tree(1)
Listen Sie den Inhalt eines Baumobjekts auf.

Git-Merge-Basis(1)
Finden Sie möglichst gute gemeinsame Vorfahren für eine Zusammenführung.

Git-Name-Rev(1)
Finden Sie symbolische Namen für bestimmte Drehzahlen.

Git-Pack-redundant(1)
Finden Sie redundante Paketdateien.

git-rev-Liste(1)
Listet Commit-Objekte in umgekehrter chronologischer Reihenfolge auf.

Git-Show-Index(1)
Gepackten Archivindex anzeigen.

git-show-ref(1)
Referenzen in einem lokalen Repository auflisten.

Git-Unpack-Datei(1)
Erstellt eine temporäre Datei mit dem Inhalt eines Blobs.

git-var(1)
Zeigt eine logische Git-Variable an.

Git-Verify-Pack(1)
Validieren Sie gepackte Git-Archivdateien.

Im Allgemeinen berühren die Abfragebefehle nicht die Dateien im Arbeitsbaum.

Synchronisieren Repositories
git-Daemon(1)
Ein wirklich einfacher Server für Git-Repositories.

Git-Fetch-Pack(1)
Erhalten Sie fehlende Objekte aus einem anderen Repository.

git-http-backend(1)
Serverseitige Implementierung von Git über HTTP.

git-send-pack(1)
Schieben Sie Objekte über das Git-Protokoll in ein anderes Repository.

Git-Update-Server-Info(1)
Aktualisieren Sie die Hilfsinformationsdatei, um dummen Servern zu helfen.

Im Folgenden finden Sie Hilfsbefehle, die von den oben genannten Benutzern verwendet werden. Endbenutzer verwenden sie normalerweise nicht
direkt.

git-http-fetch(1)
Von einem Remote-Git-Repository über HTTP herunterladen.

git-http-push(1)
Pushen Sie Objekte über HTTP/DAV in ein anderes Repository.

git-parse-remote(1)
Routinen, die beim Parsen von Remote-Repository-Zugriffsparametern helfen.

Git-Receive-Pack(1)
Erhalten Sie, was in das Repository übertragen wird.

Git-Shell(1)
Eingeschränkte Login-Shell für Git-only SSH-Zugriff.

git-upload-archiv(1)
Archiv zurück an Git-Archive senden.

Git-Upload-Pack(1)
Senden Sie gepackte Objekte zurück an git-fetch-pack.

Intern Helfer Befehle
Dies sind interne Hilfsbefehle, die von anderen Befehlen verwendet werden. Endbenutzer verwenden sie normalerweise nicht
sie direkt.

git-check-attr(1)
Gitattributes-Informationen anzeigen.

git-check-ignore(1)
Gitignore-/Ausschlussdateien debuggen.

git-check-mailmap(1)
Kanonische Namen und E-Mail-Adressen von Kontakten anzeigen.

Git-Check-Ref-Format(1)
Stellt sicher, dass ein Referenzname wohlgeformt ist.

Git-Spalte(1)
Daten in Spalten anzeigen.

Git-Anmeldeinformationen(1)
Benutzeranmeldeinformationen abrufen und speichern.

Git-Anmeldeinformationen-Cache(1)
Helfer zum vorübergehenden Speichern von Passwörtern im Speicher.

Git-Credential-Store(1)
Helfer zum Speichern von Anmeldeinformationen auf der Festplatte.

git-fmt-merge-msg(1)
Erstellen Sie eine Merge-Commit-Nachricht.

Git-Interpret-Trailer(1)
Helfen Sie dabei, strukturierte Informationen in Commit-Nachrichten einzufügen.

git-mailinfo(1)
Extrahiert Patch und Urheberschaft aus einer einzelnen E-Mail-Nachricht.

git-mailsplit(1)
Einfaches UNIX-Mbox-Splitter-Programm.

git-merge-one-file(1)
Das Standardhilfsprogramm zur Verwendung mit git-merge-index.

Git-Patch-ID(1)
Berechnen Sie die eindeutige ID für einen Patch.

git-sh-i18n(1)
Gits i18n-Setup-Code für Shell-Skripte.

git-sh-setup(1)
Allgemeiner Git-Shell-Skript-Setup-Code.

Git-Stripspace(1)
Entfernen Sie unnötige Leerzeichen.

CONFIGURATION MECHANISMUS

Git verwendet ein einfaches Textformat, um Repository-spezifische Anpassungen zu speichern
Benutzer. Eine solche Konfigurationsdatei könnte wie folgt aussehen:

#
# Ein '#' oder ';' Das Zeichen weist auf einen Kommentar hin.
#

; Kernvariablen
[Ader]
; Vertrauen Sie den Dateimodi nicht
Dateimodus = false

; Benutzeridentität
[User]
name = „Junio ​​C Hamano“
email = "[E-Mail geschützt] "

Verschiedene Befehle lesen aus der Konfigurationsdatei und passen ihre Funktionsweise entsprechend an.
See git-config(1) für eine Liste und weitere Details zum Konfigurationsmechanismus.

IDENTIFIKATOR TERMINOLOGIE

Gibt den Objektnamen für jeden Objekttyp an.


Gibt einen Blob-Objektnamen an.


Gibt einen Baumobjektnamen an.


Gibt einen Commit-Objektnamen an.


Gibt den Namen eines Baum-, Commit- oder Tag-Objekts an. Ein Befehl, der a dauert
Argument will letztlich auf a operieren Objekt, aber automatisch Dereferenzierungen
Und Objekte, die auf a zeigen .


Gibt den Namen eines Commit- oder Tag-Objekts an. Ein Befehl, der a dauert Streit
will letztendlich eine operieren Objekt, aber automatisch Dereferenzierungen
Objekte, die auf a zeigen .


Zeigt an, dass ein Objekttyp erforderlich ist. Derzeit einer von: Blob, Tree, Commit oder
-Tag.


Gibt einen Dateinamen an – fast immer relativ zur Wurzel der Baumstruktur
GIT_INDEX_FILE beschreibt.

SYMBOLISCH IDENTIFIKATIONEN

Jeder Git-Befehl akzeptiert jeden kann auch die folgende symbolische Notation verwenden:

KOPF
gibt den Leiter des aktuellen Zweigs an.


ein gültiges Tag Name (also ein refs/tags/ Referenz).


ein gültiger Kopf Name (d. h. ein Schiedsrichter/Köpfe/ Referenz).

Eine vollständigere Liste der Möglichkeiten zur Schreibweise von Objektnamen finden Sie im Abschnitt „REVISIONEN ANGEBEN“.
in gitrevisionen(7).

DATEI/VERZEICHNIS STRUKTUR

Bitte beachten Sie die Gitrepository-Layout(5) Dokument.

Lesen Sie mehr Githooks(5) für weitere Details zu jedem Haken.

SCMs höherer Ebenen können zusätzliche Informationen im $GIT_DIR bereitstellen und verwalten.

TERMINOLOGIE

Bitte ansehen Gitglossar(7).

VARIABLEN

Verschiedene Git-Befehle verwenden die folgenden Umgebungsvariablen:

Das Git Dokumente
Diese Umgebungsvariablen gelten für alle Kern-Git-Befehle. Hinweis: Das ist erwähnenswert
Sie können von SCMS, das über Git sitzt, verwendet/überschrieben werden. Seien Sie also vorsichtig, wenn Sie ein fremdes verwenden
Frontend.

GIT_INDEX_FILE
Diese Umgebung ermöglicht die Angabe einer alternativen Indexdatei. Wenn nicht
angegeben, wird der Standardwert $GIT_DIR/index verwendet.

GIT_INDEX_VERSION
Diese Umgebungsvariable ermöglicht die Angabe einer Indexversion für new
Repositories. Es hat keine Auswirkungen auf vorhandene Indexdateien. Standardmäßig ist die Indexdatei Version 2 oder
3 wird verwendet. Sehen Git-Update-Index(1) für weitere Informationen.

GIT_OBJECT_DIRECTORY
Wenn das Objektspeicherverzeichnis über diese Umgebungsvariable angegeben wird, dann wird das
Darunter werden sha1-Verzeichnisse erstellt – ansonsten der Standardwert $GIT_DIR/objects
Verzeichnis verwendet wird.

GIT_ALTERNATE_OBJECT_DIRECTORIES
Aufgrund der Unveränderlichkeit von Git-Objekten können alte Objekte in gemeinsam genutzten,
schreibgeschützte Verzeichnisse. Diese Variable gibt ein durch „:“ getrenntes (unter Windows „;“
getrennte) Liste von Git-Objektverzeichnissen, die zur Suche nach Git-Objekten verwendet werden können.
In diese Verzeichnisse werden keine neuen Objekte geschrieben.

GIT_DIR
Besitzt das GIT_DIR Wenn die Umgebungsvariable festgelegt ist, gibt sie einen Pfad an, der stattdessen verwendet werden soll
die Standard-.git-Datei für die Basis des Repositorys. Der --git-dir Befehlszeilenoption
legt auch diesen Wert fest.

GIT_WORK_TREE
Legen Sie den Pfad zum Stammverzeichnis des Arbeitsbaums fest. Dies kann auch über das gesteuert werden
--arbeitsbaum Befehlszeilenoption und die Konfigurationsvariable core.worktree.

GIT_NAMESPACE
Legen Sie den Git-Namespace fest; sehen gitnamespaces(7) für Einzelheiten. Der --Namensraum Befehlszeilen
Die Option legt auch diesen Wert fest.

GIT_CEILING_DIRECTORIES
Dies sollte eine durch Doppelpunkte getrennte Liste absoluter Pfade sein. Wenn festgelegt, handelt es sich um eine Liste von
Verzeichnisse, in die Git bei der Suche nach einem Repository-Verzeichnis nicht chdiren sollte
(nützlich, um langsam ladende Netzwerkverzeichnisse auszuschließen). Es wird das nicht ausschließen
aktuelles Arbeitsverzeichnis oder ein GIT_DIR, das in der Befehlszeile oder in der Umgebung festgelegt ist.
Normalerweise muss Git die Einträge in dieser Liste lesen und eventuelle Symlinks auflösen
vorhanden sein, um sie mit dem aktuellen Verzeichnis vergleichen zu können. Allerdings, wenn überhaupt
Der Zugriff ist langsam. Sie können der Liste einen leeren Eintrag hinzufügen, um Git mitzuteilen, dass der nächste
Einträge sind keine Symlinks und müssen nicht aufgelöst werden; z.B,
GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM
Wenn Git in einem Verzeichnis ausgeführt wird, das nicht über das Repository-Verzeichnis „.git“ verfügt, versucht es dies
Suchen Sie ein solches Verzeichnis in den übergeordneten Verzeichnissen, um den oberen Rand des Arbeitsbaums zu finden.
aber standardmäßig überschreitet es keine Dateisystemgrenzen. Diese Umgebungsvariable kann
auf „true“ gesetzt werden, um Git anzuweisen, nicht an Dateisystemgrenzen anzuhalten. Wie
GIT_CEILING_DIRECTORIES, dies hat keine Auswirkungen auf ein explizites Repository-Verzeichnis, das über festgelegt wurde
GIT_DIR oder auf der Kommandozeile.

GIT_COMMON_DIR
Wenn diese Variable auf einen Pfad gesetzt ist, werden Nicht-Worktree-Dateien, die sich normalerweise in $GIT_DIR befinden
wird stattdessen von diesem Pfad übernommen. Worktree-spezifische Dateien wie HEAD oder Index
werden aus $GIT_DIR entnommen. Sehen Gitrepository-Layout(5) und Git-Worktree(1) für Details.
Diese Variable hat eine niedrigere Priorität als andere Pfadvariablen wie GIT_INDEX_FILE,
GIT_OBJECT_DIRECTORY...

Git Commits
GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME,
GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE, EMAIL
sehen Git-Commit-Baum(1)

Git Differenzen
GIT_DIFF_OPTS
Die einzig gültige Einstellung ist „--unified=??“ oder „-u??“ um die Anzahl der Kontextzeilen festzulegen
wird angezeigt, wenn ein einheitliches Diff erstellt wird. Dies hat Vorrang vor jedem „-U“ oder
„--unified“-Optionswert, der in der Git-Diff-Befehlszeile übergeben wird.

GIT_EXTERNAL_DIFF
Wenn die Umgebungsvariable GIT_EXTERNAL_DIFF gesetzt ist, ist das von ihm benannte Programm
aufgerufen, anstelle des oben beschriebenen Diff-Aufrufs. Für einen Pfad, der hinzugefügt wird,
entfernt oder geändert, GIT_EXTERNAL_DIFF wird mit 7 Parametern aufgerufen:

Pfad alte Datei, altes Hex, alter Modus, neue Datei, neues Hex, neuer Modus

wo:

-Datei
sind Dateien, die GIT_EXTERNAL_DIFF zum Lesen des Inhalts verwenden kann ,

-verhexen
sind die 40-hexstelligen SHA-1-Hashes,

-Modus
sind die oktale Darstellung der Dateimodi.

Die Dateiparameter können auf die Arbeitsdatei des Benutzers verweisen (z. B. neue Datei in).
„git-diff-files“), /dev/null (z. B. old-file, wenn eine neue Datei hinzugefügt wird) oder eine temporäre Datei
Datei (z. B. alte Datei im Index). GIT_EXTERNAL_DIFF sollte sich keine Sorgen machen
Verknüpfung der temporären Datei aufheben --- Sie wird entfernt, wenn GIT_EXTERNAL_DIFF Ausgänge.

Für einen Pfad, der nicht zusammengeführt ist, GIT_EXTERNAL_DIFF wird mit 1 Parameter aufgerufen, .

Für jeden Pfad GIT_EXTERNAL_DIFF heißt, zwei Umgebungsvariablen,
GIT_DIFF_PATH_COUNTER und GIT_DIFF_PATH_TOTAL eingestellt sind.

GIT_DIFF_PATH_COUNTER
Ein 1-basierter Zähler, der für jeden Pfad um eins erhöht wird.

GIT_DIFF_PATH_TOTAL
Die Gesamtzahl der Pfade.

Sonstiges
GIT_MERGE_VERBOSITY
Eine Zahl, die die Ausgabemenge steuert, die von der rekursiven Zusammenführungsstrategie angezeigt wird.
Überschreibt merge.verbosity. Sehen Git-Merge(1)

GIT_PAGER
Diese Umgebungsvariable überschreibt $PAGER. Wenn es auf eine leere Zeichenfolge oder auf die festgelegt ist
Wenn Sie den Wert „cat“ angeben, startet Git keinen Pager. Siehe auch die Option core.pager in Git-
Config(1).

GIT_EDITOR
Diese Umgebungsvariable überschreibt $EDITOR und $VISUAL. Es wird von mehreren Git verwendet
Befehle, wenn im interaktiven Modus ein Editor gestartet werden soll. Siehe auch git-var(1)
und die Option core.editor in git-config(1).

GIT_SSH, GIT_SSH_COMMAND
Wenn eine dieser Umgebungsvariablen festgelegt ist, dann git holen und git drücken wird benutzen
den angegebenen Befehl statt ssh wenn sie eine Verbindung zu einem Remote-System herstellen müssen. Der
Dem Befehl werden genau zwei oder vier Argumente übergeben: the Benutzername@Host (oder nur Gastgeber)
aus der URL und dem Shell-Befehl, der optional auf diesem Remote-System ausgeführt werden soll
vorangestellt von -p (wörtlich) und die port aus der URL, wenn dort etwas anderes angegeben ist
als der Standard-SSH-Port.

$GIT_SSH_COMMAND hat Vorrang vor $GIT_SSH und wird von der Shell interpretiert.
Dadurch können zusätzliche Argumente einbezogen werden. $GIT_SSH hingegen muss es sein
nur der Pfad zu einem Programm (bei dem es sich ggf. um ein Wrapper-Shell-Skript handeln kann).
Argumente sind nötig).

Normalerweise ist es einfacher, alle gewünschten Optionen über Ihr persönliches Konto zu konfigurieren
.ssh/config-Datei. Weitere Informationen finden Sie in Ihrer SSH-Dokumentation.

GIT_ASKPASS
Wenn diese Umgebungsvariable festgelegt ist, werden Git-Befehle benötigt, um Passwörter abzurufen
oder Passphrasen (z. B. für HTTP- oder IMAP-Authentifizierung) rufen dieses Programm mit einem auf
Geben Sie die entsprechende Eingabeaufforderung als Befehlszeilenargument ein und lesen Sie das Kennwort aus der STDOUT-Ausgabe. Sehen
auch die core.askPass Option in git-config(1).

GIT_TERMINAL_PROMPT
Wenn diese Umgebungsvariable auf 0 gesetzt ist, gibt git keine Eingabeaufforderung auf dem Terminal aus (z. B.
wenn Sie nach einer HTTP-Authentifizierung fragen).

GIT_CONFIG_NOSYSTEM
Ob das Lesen der Einstellungen aus der systemweiten Datei $(prefix)/etc/gitconfig übersprungen werden soll.
Diese Umgebungsvariable kann zusammen mit $HOME und $XDG_CONFIG_HOME zum Erstellen verwendet werden
Eine vorhersehbare Umgebung für ein wählerisches Skript, oder Sie können es vorübergehend festlegen, um dies zu vermeiden
Verwenden einer fehlerhaften /etc/gitconfig-Datei, während Sie darauf warten, dass jemand über ausreichende Kenntnisse verfügt
Berechtigungen, um das Problem zu beheben.

GIT_FLUSH
Wenn diese Umgebungsvariable auf „1“ gesetzt ist, werden Befehle wie git Schuld (in
Inkrementalmodus), git Drehzahlliste, git Log, git Prüfattr und git check-ignorieren werden wir
Erzwingen Sie eine Leerung des Ausgabestreams, nachdem jeder Datensatz geleert wurde. Wenn dies
Ist die Variable auf „0“ gesetzt, erfolgt die Ausgabe dieser Befehle vollständig
gepufferte E/A. Wenn diese Umgebungsvariable nicht festgelegt ist, wählt Git „gepuffert“ oder „gepuffert“.
Datensatzorientiertes Leeren basierend darauf, ob stdout scheinbar in eine Datei umgeleitet wird oder
nicht.

GIT_TRACE
Ermöglicht allgemeine Trace-Meldungen, z. B. Alias-Erweiterung, integrierte Befehlsausführung und
externe Befehlsausführung.

Wenn diese Variable auf „1“, „2“ oder „true“ gesetzt ist (bei dem Vergleich wird die Groß-/Kleinschreibung nicht beachtet), wird eine Ablaufverfolgung durchgeführt
Nachrichten werden auf stderr gedruckt.

Wenn die Variable auf einen ganzzahligen Wert größer als 2 und kleiner als 10 (streng) eingestellt ist
dann interpretiert Git diesen Wert als offenen Dateideskriptor und versucht zu schreiben
die Trace-Meldungen in diesen Dateideskriptor.

Wenn die Variable alternativ auf einen absoluten Pfad festgelegt ist (beginnend mit a /
Zeichen), Git interpretiert dies als Dateipfad und versucht, den Trace zu schreiben
Nachrichten hinein.

Deaktivieren Sie die Variable oder setzen Sie sie auf leer, „0“ oder „false“ (Groß- und Kleinschreibung wird nicht beachtet)
deaktiviert Trace-Meldungen.

GIT_TRACE_PACK_ACCESS
Aktiviert Trace-Nachrichten für alle Zugriffe auf beliebige Pakete. Für jeden Zugriff die Packdatei
Name und ein Offset im Paket werden erfasst. Dies kann bei der Fehlerbehebung hilfreich sein
einige paketbezogene Leistungsprobleme. Sehen GIT_TRACE für die verfügbare Trace-Ausgabe
Optionen.

GIT_TRACE_PACKET
Aktiviert Trace-Meldungen für alle Pakete, die in einem bestimmten Programm ein- oder ausgehen. Das kann
Hilfe beim Debuggen von Objektverhandlungen oder anderen Protokollproblemen. Die Ablaufverfolgung ist deaktiviert
bei einem Paket, das mit „PACK“ beginnt (aber siehe GIT_TRACE_PACKFILE unten). Sehen GIT_TRACE für
verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_PACKFILE
Ermöglicht die Verfolgung von Paketdateien, die von einem bestimmten Programm gesendet oder empfangen werden. Im Gegensatz zu anderen Spuren
Ausgabe ist diese Ablaufverfolgung wörtlich: keine Header und keine Anführungszeichen von Binärdaten. Du hast fast
Ich möchte auf jeden Fall lieber in eine Datei (z. B. GIT_TRACE_PACKFILE=/tmp/my.pack) verweisen
als es auf dem Terminal anzuzeigen oder mit anderen Trace-Ausgaben zu mischen.

Beachten Sie, dass dies derzeit nur für die Clientseite von Klonen und implementiert ist
holt.

GIT_TRACE_PERFORMANCE
Ermöglicht leistungsbezogene Trace-Meldungen, z. B. Gesamtausführungszeit jedes Git
Befehl. Sehen GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_TRACE_SETUP
Ermöglicht Ablaufverfolgungsmeldungen zum Drucken der .git-Datei, des Arbeitsbaums und des aktuellen Arbeitsverzeichnisses
nachdem Git seine Setup-Phase abgeschlossen hat. Sehen GIT_TRACE für die verfügbare Trace-Ausgabe
Optionen.

GIT_TRACE_SHALLOW
Aktiviert Ablaufverfolgungsmeldungen, die beim Debuggen des Abrufens/Klonens von Shallow helfen können
Repositories. Sehen GIT_TRACE für verfügbare Trace-Ausgabeoptionen.

GIT_LITERAL_PATHSPECS
Wenn Sie diese Variable auf 1 setzen, behandelt Git alle Pfadspezifikationen eher wörtlich
als als Kugelmuster. Führen Sie beispielsweise GIT_LITERAL_PATHSPECS=1 git log -- '*.c' aus.
sucht nach Commits, die den Pfad *.c berühren, nicht nach Pfaden, die den Glob *.c betreffen
Streichhölzer. Möglicherweise möchten Sie dies, wenn Sie Git Literalpfade zuführen (z. B. paths
zuvor von git ls-tree, --raw diff-Ausgabe usw. bereitgestellt).

GIT_GLOB_PATHSPECS
Wenn Sie diese Variable auf 1 setzen, behandelt Git alle Pfadspezifikationen als Glob-Muster (auch bekannt als „Glob Patterns“)
„Glob“-Magie).

GIT_NOGLOB_PATHSPECS
Wenn Sie diese Variable auf 1 setzen, behandelt Git alle Pfadspezifikationen als Literal (auch bekannt als:
„buchstäbliche“ Magie).

GIT_ICASE_PATHSPECS
Wenn Sie diese Variable auf 1 setzen, behandelt Git alle Pfadspezifikationen ohne Berücksichtigung der Groß- und Kleinschreibung.

GIT_REFLOG_ACTION
Wenn eine Referenz aktualisiert wird, werden Reflog-Einträge erstellt, um den Grund dafür zu verfolgen
ref wurde aktualisiert (normalerweise der Name des übergeordneten Befehls, der aktualisiert wurde).
der Referenz), zusätzlich zu den alten und neuen Werten der Referenz. Ein Porzellan mit Schriftzug
Der Befehl kann die Hilfsfunktion set_reflog_action in git-sh-setup verwenden, um seinen Namen auf festzulegen
diese Variable, wenn sie vom Endbenutzer als Befehl der obersten Ebene aufgerufen wird
im Hauptteil des Reflogs aufgezeichnet.

GIT_REF_PARANOIA
Wenn auf 1 gesetzt, werden defekte oder falsch benannte Refs beim Durchlaufen von Ref-Listen einbezogen. In
Bei einem normalen, unbeschädigten Repository hat dies keine Auswirkung. Es kann jedoch hilfreich sein, es zu aktivieren
git, um einige Vorgänge bei defekten Refs zu erkennen und abzubrechen. Git legt dies fest
Variable automatisch, wenn destruktive Operationen wie ausgeführt werden git-prune(1). Du
Es sollte nicht nötig sein, es selbst einzustellen, es sei denn, Sie möchten Angst davor haben, sicherzustellen, dass ein
Der Vorgang hat jede Referenz berührt (z. B. weil Sie ein Repository klonen, um eine zu erstellen
Sicherung).

GIT_ALLOW_PROTOCOL
Wenn festgelegt, wird eine durch Doppelpunkte getrennte Liste der Protokolle bereitgestellt, mit denen verwendet werden darf
Abrufen/Push/Klonen. Dies ist nützlich, um die rekursive Submodulinitialisierung einzuschränken
ein nicht vertrauenswürdiges Repository. Jedes Protokoll, das nicht erwähnt wird, wird nicht zugelassen (d. h., dies ist
eine Whitelist, keine Blacklist). Wenn die Variable überhaupt nicht gesetzt ist, sind es alle Protokolle
ermöglicht. Die derzeit von Git verwendeten Protokollnamen sind:

· Datei: jeder lokale dateibasierte Pfad (einschließlich file://-URLs oder lokale Pfade)

· git: das anonyme Git-Protokoll über eine direkte TCP-Verbindung (oder einen Proxy, falls
konfiguriert)

· ssh: git über ssh (einschließlich Host:Pfad-Syntax, git+ssh:// usw.).

· rsync: Git über rsync

· http: Git über http, sowohl „smart http“ als auch „dumb http“. Beachten Sie, dass dies der Fall ist nicht
https einschließen; Wenn Sie beides möchten, sollten Sie beide als http:https angeben.

· Alle externen Helfer werden nach ihrem Protokoll benannt (verwenden Sie z. B. hg, um das zu ermöglichen
git-remote-hg Helfer)

DISKUSSION

Weitere Einzelheiten zu Folgendem finden Sie im Git Konzepte Kapitel of
Benutzerhandbuch[2] und Gitcore-Tutorial(7).

Ein Git-Projekt besteht normalerweise aus einem Arbeitsverzeichnis mit einem „.git“-Unterverzeichnis am
Höchststufe. Das .git-Verzeichnis enthält unter anderem eine komprimierte Objektdatenbank
die den gesamten Verlauf des Projekts darstellt, eine „Index“-Datei, die diesen Verlauf verknüpft
auf den aktuellen Inhalt des Arbeitsbaums und benannte Zeiger in diesen Verlauf, z
Tags und Zweigköpfe.

Die Objektdatenbank enthält Objekte von drei Haupttypen: Blobs, die Dateidaten enthalten;
Bäume, die auf Blobs und andere Bäume verweisen, um Verzeichnishierarchien aufzubauen; Und
Commits, die jeweils auf einen einzelnen Baum und eine bestimmte Anzahl übergeordneter Commits verweisen.

Der Commit, der dem entspricht, was andere Systeme als „Changeset“ oder „Version“ bezeichnen, stellt einen dar
Schritt im Projektverlauf, und jedes übergeordnete Element stellt einen unmittelbar vorhergehenden Schritt dar.
Commits mit mehr als einem übergeordneten Element stellen Zusammenführungen unabhängiger Entwicklungslinien dar.

Alle Objekte werden nach dem SHA-1-Hash ihres Inhalts benannt, der normalerweise als Zeichenfolge geschrieben wird
40 Hexadezimalziffern. Solche Namen sind weltweit einzigartig. Der gesamte Verlauf bis zu einem Commit
kann durch die Unterzeichnung dieses Commits bestätigt werden. Ein vierter Objekttyp, das Tag, wird bereitgestellt
für diesen Zweck.

Bei der ersten Erstellung werden Objekte in einzelnen Dateien gespeichert, aus Effizienzgründen kann dies jedoch später erfolgen
in „Packdateien“ komprimiert werden.

Benannte Zeiger, sogenannte Refs, markieren interessante Punkte in der Geschichte. Ein Verweis kann den SHA-1 enthalten
Name eines Objekts oder der Name einer anderen Referenz. Refs mit Namen beginnend mit ref/head/ include
der SHA-1-Name des letzten Commits (oder „Kopfes“) eines Zweigs in der Entwicklung. SHA-1
Namen der Tags von Interesse werden unter ref/tags/ gespeichert. Eine spezielle Referenz namens HEAD enthält
der Name des aktuell ausgecheckten Zweigs.

Die Indexdatei wird mit einer Liste aller Pfade und für jeden Pfad einem Blob-Objekt initialisiert
und eine Reihe von Attributen. Das Blob-Objekt stellt den Inhalt der Datei zum Stand dar
Leiter der aktuellen Niederlassung. Die Attribute (letzte Änderungszeit, Größe usw.) werden übernommen
die entsprechende Datei im Arbeitsbaum. Nachträgliche Änderungen am Arbeitsbaum können erfolgen
durch Vergleich dieser Attribute gefunden. Der Index kann mit neuen und neuen Inhalten aktualisiert werden
Commits können aus dem im Index gespeicherten Inhalt erstellt werden.

Der Index ist auch in der Lage, mehrere Einträge (sogenannte „Stufen“) für einen bestimmten Wert zu speichern
Pfadname. Diese Stufen werden verwendet, um die verschiedenen nicht zusammengeführten Versionen einer Datei zu speichern, wenn a
Die Zusammenführung ist im Gange.

DES WEITEREN DOKUMENTATION

Sehen Sie sich die Referenzen im Abschnitt „Beschreibung“ an, um mit der Verwendung von Git zu beginnen. Das Folgende ist
wahrscheinlich detaillierter als für einen Erstbenutzer nötig.

Das Git Konzepte Kapitel of Benutzerhandbuch[2] und Gitcore-Tutorial(7) Beide bieten
Einführungen in die zugrunde liegende Git-Architektur.

See Gitworkflows(7) für einen Überblick über empfohlene Arbeitsabläufe.

Siehe auch die Howto[3] Dokumente für einige nützliche Beispiele.

Die Interna sind im dokumentiert Git API Dokumentation[4].

Benutzer, die von CVS migrieren, möchten möglicherweise auch lesen Gitcvs-Migration(7).

AUTOREN

Git wurde von Linus Torvalds gestartet und wird derzeit von Junio ​​C Hamano gepflegt. Zahlreiche
Die Beiträge stammen von der Git-Mailingliste[E-Mail geschützt] [5]>.
http://www.openhub.net/p/git/contributors/summary gibt Ihnen eine vollständigere Liste von
Mitwirkenden.

Wenn Sie einen Klon von git.git selbst haben, wird die Ausgabe von git-kurzlog(1) und git-Schuld(1 Dose
Zeigen Sie die Autoren für bestimmte Teile des Projekts an.

REPORTING Fehler

Melden Sie Fehler an die Git-Mailingliste[E-Mail geschützt] [5]> wo die Entwicklung und
Die Wartung erfolgt hauptsächlich. Sie müssen die Liste nicht abonniert haben, um eine zu senden
Nachricht dort.

Verwenden Sie Git online über die Dienste von onworks.net