English ▾ Themen ▾ Neueste Version ▾ Einreichen von Patches zuletzt aktualisiert in 2.52.0

Diese Informationen sind spezifisch für das Git-Projekt

Bitte beachten Sie, dass diese Informationen nur für Sie relevant sind, wenn Sie planen, selbst zum Git-Projekt beizutragen. Sie sind in keiner Weise Pflichtlektüre für reguläre Git-Benutzer.

Richtlinien

Hier sind einige Richtlinien für Beiträge zu diesem Projekt. Es gibt auch ein Schritt-für-Schritt-Tutorial, das viele dieser Richtlinien abdeckt.

Ein typischer Lebenszyklus einer Patch-Serie

Um uns zu helfen, die Gründe für die im Folgenden genannten Richtlinien zu verstehen, betrachten wir zunächst den Lebenszyklus einer typischen Patch-Serie für dieses Projekt.

  1. Sie haben eine Idee. Sie programmieren sie. Sie benötigen keine vorherige Genehmigung des Projekts, um dies zu tun.

    Ihre Patches werden von anderen Mitwirkenden in der Mailingliste überprüft. Die Überprüfungen zielen darauf ab, den Wert verschiedener Aspekte zu bewerten, wie z. B. die allgemeine Idee hinter Ihrem Patch (einschließlich "löst er überhaupt ein Problem, das gelöst werden muss?"), die Gründe für das Design der Lösung und die tatsächliche Implementierung. Die hier gegebenen Richtlinien sollen Ihnen helfen, Ihre Patches zu verbessern, indem sie für die Prüfer leichter verständlich gemacht werden.

  2. Sie senden die Patches an die Liste und setzen Personen, die über die Änderung informiert sein müssen, auf CC. Ihr Ziel ist es nicht unbedingt, andere davon zu überzeugen, dass das, was Sie bauen, gut ist. Ihr Ziel ist es, Hilfe zu bekommen, um eine bessere Lösung für den "Juckreiz" zu finden, als Sie sie allein erstellen können.

    Die Personen, die informiert sein müssen, sind diejenigen, die an dem Code gearbeitet haben, den Sie bearbeiten. Diese Personen sind am wahrscheinlichsten kompetent genug, um Ihnen zu helfen, aber sie sind nicht verpflichtet, Ihnen zu helfen (d. h. Sie bitten sie um Hilfe, Sie verlangen sie nicht). git log -p -- $bereich_den_sie_modifizieren hilft Ihnen, herauszufinden, wer sie sind.

  3. Sie erhalten Kommentare und Vorschläge zur Verbesserung. Möglicherweise erhalten Sie diese sogar in Form eines Patches "auf Ihren Änderungsantrag". Sie werden gebeten, darauf mit "Allen antworten" in der Mailingliste zu reagieren und dabei die Vorschläge bei der Vorbereitung eines aktualisierten Patchesatzes zu berücksichtigen.

  4. Polieren, verfeinern und erneut senden Sie Ihre Patches an die Liste und an die Personen, die ihre Zeit damit verbracht haben, Ihren Patch zu verbessern. Gehen Sie zurück zu Schritt (2).

  5. Während die obigen Iterationen Ihre Patches verbessern, kann der Betreuer die Patches von der Liste aufnehmen und in den seen-Branch einreihen, um es den Leuten zu erleichtern, damit zu spielen, ohne die Patches selbst auf ihre Bäume anwenden zu müssen. In seen zu sein, hat keine andere Bedeutung. Insbesondere bedeutet es nicht, dass der Patch in irgendeiner Weise "akzeptiert" wurde.

  6. Wenn die Diskussion zu einem Konsens gelangt, dass die neueste Iteration der Patches in einem ausreichend guten Zustand ist, nimmt der Betreuer das Thema in den "Was ist in Arbeit"-Bericht auf, der mehrmals pro Woche an die Mailingliste gesendet wird und als "Wird in next gemerged" gekennzeichnet ist. Diese Entscheidung wird hauptsächlich vom Betreuer getroffen, mit Hilfe derer, die an der Diskussionsrunde teilgenommen haben.

  7. Nachdem die Patches in den next-Branch gemerged wurden, kann die Diskussion weitergehen, um sie durch das Hinzufügen weiterer Patches zu verbessern. Bis zu dem Zeitpunkt, an dem ein Thema in next gemerged wird, wird erwartet, dass alle zustimmen, dass der Umfang und die grundlegende Richtung des Themas angemessen sind. Daher beschränken sich solche inkrementellen Aktualisierungen auf kleine Korrekturen und Polituren. Nachdem ein Thema eine Weile (z. B. 7 Kalendertage) in next "gekocht" ist, ohne weitere Anpassungen zu benötigen, wird es in den master-Branch gemerged und wartet darauf, Teil des nächsten größeren Releases zu werden.

In den folgenden Abschnitten werden viele Techniken und Konventionen aufgeführt, um Ihre Patches in diesem Lebenszyklus effektiv überprüfen zu lassen.

Wählen Sie einen Ausgangspunkt.

Als vorbereitenden Schritt müssen Sie zunächst einen Ausgangspunkt für Ihre Arbeit wählen. Typischerweise bedeutet dies die Wahl eines Branches, obwohl es technisch gesehen tatsächlich ein bestimmter Commit ist (typischerweise der HEAD oder die Spitze des Branches).

Es gibt mehrere wichtige Branches, die Sie kennen sollten. Nämlich gibt es vier Integrationsbranches, wie in gitworkflows[7] erläutert.

  • maint

  • master

  • next

  • seen

Die Branches weiter unten in der Liste sind typischerweise Nachfahren derer, die davor kommen. Zum Beispiel ist maint ein "älterer" Branch als master, da master normalerweise Patches (Commits) auf maint hat.

Es gibt auch "Themen"-Branches, die Arbeiten von anderen Mitwirkenden enthalten. Themen-Branches werden vom Git-Betreuer (in seinem Fork) erstellt, um den aktuellen Satz eingehender Beiträge in der Mailingliste zu organisieren, und sind in den regelmäßigen "Was ist in git.git in Arbeit"-Ankündigungen aufgeführt. Um die Spitze eines Themen-Branches zu finden, führen Sie git log --first-parent master..seen aus und suchen Sie nach dem Merge-Commit. Der zweite Elternteil dieses Commits ist die Spitze des Themen-Branches.

Es gibt ein leitendes Prinzip für die Wahl des richtigen Ausgangspunkts: Im Allgemeinen sollten Sie Ihre Arbeit immer auf dem ältesten Integrationsbranch basieren, der für Ihre Änderung relevant ist (siehe "Nach oben mergen" in gitworkflows[7]). Dieses Prinzip bedeutet, dass in den meisten Fällen der Ausgangspunkt für neue Arbeiten der neueste HEAD-Commit von maint oder master sein sollte, basierend auf den folgenden Fällen:

  • Wenn Sie Fehler in der veröffentlichten Version beheben, verwenden Sie maint als Ausgangspunkt (was bedeuten kann, dass Sie Dinge beheben müssen, ohne neue API-Funktionen der neuesten Version zu verwenden, die kürzlich in master erschienen sind, aber in der veröffentlichten Version nicht verfügbar waren).

  • Andernfalls (z. B. wenn Sie neue Funktionen hinzufügen) verwenden Sie master.

Hinweis
 In Ausnahmefällen muss möglicherweise ein Fehler, der in einer alten Version eingeführt wurde, für Benutzer von Releases behoben werden, die viel älter sind als die aktuellen Releases. git describe --contains X kann X als v2.30.0-rc2-gXXXXXX für den Commit X beschreiben, der den Fehler eingeführt hat. Und der Fehler kann so schwerwiegend sein, dass wir möglicherweise eine neue Wartungsversion für die Git 2.30.x-Serie herausgeben müssen, wenn "Git 2.41.0" die aktuelle Version ist. In einem solchen Fall möchten Sie möglicherweise die Spitze des Wartungsbranches für die 2.30.x-Serie verwenden, die im Branch maint-2.30 im "ausgegliederten" Repository des Betreuers verfügbar sein könnte.

Dies bedeutet auch, dass next oder seen ungeeignete Ausgangspunkte für Ihre Arbeit sind, wenn Sie möchten, dass Ihre Arbeit eine realistische Chance hat, zu master aufzusteigen. Sie sind einfach nicht dafür gedacht, als Basis für neue Arbeiten verwendet zu werden; sie sind nur dazu da, sicherzustellen, dass laufende Themen gut zusammenarbeiten. Deshalb werden sowohl next als auch seen häufig mit eingehenden Patches in der Mailingliste re-integriert und force-gepusht, um frühere Versionen von sich selbst zu ersetzen. Ein Thema, das buchstäblich auf next aufgebaut ist, kann nicht nach master gemerged werden, ohne alle anderen Themen in next mitzuziehen, von denen einige möglicherweise noch nicht bereit sind.

Wenn Sie beispielsweise baumweite Änderungen vornehmen, während jemand anderes ebenfalls seine eigenen baumweiten Änderungen vornimmt, kann Ihre Arbeit stark mit der Arbeit der anderen Person überlappen. Diese Situation könnte Sie versucht sein lassen, next als Ihren Ausgangspunkt zu verwenden (da es die Arbeit der anderen Person enthalten würde), aber dies würde bedeuten, dass Sie nicht nur von der Arbeit der anderen Person abhängig sind, sondern auch von allen anderen zufälligen Dingen von anderen Mitwirkenden, die bereits in next integriert sind. Und sobald next mit einer neuen Version aktualisiert wird, muss Ihre gesamte Arbeit ohnehin neu gebased werden, damit sie sauber vom Betreuer angewendet werden kann.

Unter wirklich außergewöhnlichen Umständen, bei denen Sie unbedingt von einigen wenigen Themen-Branches abhängen müssen, die bereits in next, aber nicht in master sind, möchten Sie möglicherweise Ihren eigenen benutzerdefinierten Basis-Branch erstellen, indem Sie master forken und die erforderlichen Themen-Branches darin mergen. Sie könnten dann auf diesem Basis-Branch arbeiten. Beachten Sie jedoch, dass dieser Basis-Branch nur Ihnen privat bekannt wäre. Wenn Sie also bereit sind, Ihre Patches an die Liste zu senden, stellen Sie sicher, dass Sie in Ihrem Anschreiben mitteilen, wie Sie ihn erstellt haben. Diese kritische Information würde es anderen ermöglichen, Ihren Basis-Branch auf ihrer Seite neu zu erstellen, um Ihre Arbeit auszuprobieren.

Beachten Sie schließlich, dass einige Teile des Systems dedizierte Betreuer mit eigenen separaten Quellcode-Repositories haben (siehe Abschnitt "Subsysteme" unten).

Erstellen Sie separate Commits für logisch getrennte Änderungen.

Es sei denn, Ihr Patch ist wirklich trivial, sollten Sie keinen Patch versenden, der zwischen Ihrem Arbeitsbaum und Ihrem Commit-Head generiert wurde. Erstellen Sie stattdessen immer einen Commit mit einer vollständigen Commit-Nachricht und generieren Sie eine Reihe von Patches aus Ihrem Repository. Das ist gute Disziplin.

Geben Sie eine Erklärung für die Änderung(en), die detailliert genug ist, damit die Leute beurteilen können, ob sie eine gute Sache ist, ohne den eigentlichen Patchtext lesen zu müssen, um zu bestimmen, wie gut der Code das hält, was die Erklärung verspricht.

Wenn Ihre Beschreibung zu lang wird, ist das ein Zeichen dafür, dass Sie wahrscheinlich Ihren Commit in kleinere Teile aufteilen müssen. Dennoch sind Patches, die klar beschreiben, was den Prüfern hilft, den Patch zu überprüfen, und zukünftigen Betreuern den Code zu verstehen, die schönsten Patches. Beschreibungen, die den Punkt in der Betreffzeile gut zusammenfassen und die Motivation für die Änderung, den Ansatz der Änderung und, falls relevant, wie er sich erheblich von der vorherigen Version unterscheidet, sind alle gute Dinge.

Stellen Sie sicher, dass Sie Tests für den Fehler haben, den Sie beheben. Siehe t/README für Anleitungen.

Fügen Sie beim Hinzufügen neuer Funktionen sicher, dass Sie neue Tests haben, die zeigen, dass die Funktion das neue Verhalten auslöst, wenn sie sollte, und die zeigen, dass die Funktion nicht auslöst, wenn sie nicht sollte. Nach jeder Codeänderung stellen Sie sicher, dass die gesamte Testsuite erfolgreich ist. Wenn Sie einen Fehler beheben, stellen Sie sicher, dass Sie neue Tests haben, die fehlschlagen, wenn jemand anderes versehentlich das, was Sie behoben haben, kaputt macht, um Regressionen zu vermeiden. Versuchen Sie auch, Ihre Arbeit in next und seen zu mergen und stellen Sie sicher, dass die Tests weiterhin erfolgreich sind; Themen anderer, die noch in Arbeit sind, können unerwartete Interaktionen mit dem haben, was Sie in Ihrem Thema versuchen.

Das Pushen in einen Fork von https://github.com/git/git nutzt deren CI-Integration, um Ihre Änderungen unter Linux, Mac und Windows zu testen. Details finden Sie im Abschnitt GitHub CI.

Vergessen Sie nicht, die Dokumentation zu aktualisieren, um das geänderte Verhalten zu beschreiben, und stellen Sie sicher, dass die resultierende Dokumentation gut formatiert ist (versuchen Sie das Skript Documentation/doc-diff).

Wir haben derzeit eine liberale Mischung aus US-amerikanischen und britischen englischen Rechtschreib- und Grammatikregeln, was etwas bedauerlich ist. Ein riesiger Patch, der Dateien überall berührt, nur um die Inkonsistenz zu korrigieren, wird jedoch nicht begrüßt. Mögliche Konflikte mit anderen Änderungen, die aus einem solchen Patch resultieren können, sind es nicht wert. Wir ziehen es vor, die Inkonsistenzen schrittweise zugunsten des US-amerikanischen Englisch mit kleinen und leicht verdaulichen Patches zu bereinigen, als Nebeneffekt bei der Durchführung anderer tatsächlicher Arbeiten in der Nähe (z. B. das Umschreiben eines Absatzes zur Klarheit, während en_UK-Schreibweisen in en_US geändert werden). Offensichtliche Tippfehler sind viel mehr willkommen ("teh → "the"), vorzugsweise als unabhängige Patches, getrennt von anderen Dokumentationsänderungen.

Oh, noch eine Sache. Wir sind wählerisch, was Leerzeichen angeht. Stellen Sie sicher, dass Ihre Änderungen keine Fehler mit dem Beispiel-Pre-Commit-Hook auslösen, der in templates/hooks--pre-commit mitgeliefert wird. Um sicherzustellen, dass dies nicht passiert, führen Sie git diff --check auf Ihren Änderungen aus, bevor Sie committen.

Beschreiben Sie Ihre Änderungen gut.

Die Protokollnachricht, die Ihre Änderungen erklärt, ist genauso wichtig wie die Änderungen selbst. Ihr Code mag klar geschrieben sein und Kommentare enthalten, die ausreichend erklären, wie er mit dem umgebenden Code funktioniert, aber diejenigen, die Ihren Code in Zukunft reparieren oder verbessern müssen, müssen wissen, warum Ihr Code das tut, was er tut, aus mehreren Gründen:

  1. Ihr Code tut möglicherweise etwas anderes, als Sie es beabsichtigt hatten. Das Aufschreiben dessen, was Sie tatsächlich erreichen wollten, hilft ihnen, Ihren Code zu reparieren und ihn dazu zu bringen, das zu tun, was er tun sollte (auch entdecken Sie oft Ihre eigenen Fehler, während Sie die Protokollnachricht schreiben, um den dahinter stehenden Gedanken zusammenzufassen).

  2. Ihr Code tut möglicherweise Dinge, die nur für Ihre unmittelbaren Bedürfnisse notwendig waren (z. B. "mache X mit Verzeichnissen", ohne zu implementieren oder auch nur zu entwerfen, was mit Dateien geschehen soll). Das Aufschreiben, warum Sie ausgeschlossen haben, was der Code nicht tut, hilft zukünftigen Entwicklern. Das Aufschreiben von "wir tun X mit Verzeichnissen, weil Verzeichnisse die Eigenschaft Y haben" würde ihnen helfen zu schlussfolgern: "Oh, Dateien haben auch die gleiche Eigenschaft Y, also wäre es vielleicht sinnvoll, auch X auf sie anzuwenden?". Das Sagen "wir tun nicht dasselbe X für Dateien, weil..." hilft ihnen zu entscheiden, ob die Begründung stichhaltig ist (in diesem Fall verschwenden sie keine Zeit damit, Ihren Code zu erweitern, um Dateien abzudecken) oder anders zu argumentieren (in diesem Fall können sie erklären, warum sie Ihren Code erweitern, um auch Dateien abzudecken).

Das Ziel Ihrer Protokollnachricht ist es, das Warum hinter Ihrer Änderung zu vermitteln, um zukünftigen Entwicklern zu helfen. Die Prüfer werden auch sicherstellen, dass Ihre vorgeschlagene Protokollnachricht diesem Zweck gut dient.

Die erste Zeile der Commit-Nachricht sollte eine kurze Beschreibung sein (50 Zeichen ist die weiche Grenze, siehe DISKUSSION in git-commit[1]) und sollte den Punkt überspringen. Es ist auch in den meisten Fällen üblich, die erste Zeile mit "bereich: " zu präfixen, wobei der Bereich ein Dateiname oder eine Kennung für den allgemeinen Bereich des modifizierten Codes ist, z. B.:

  • doc: klären Sie die Unterscheidung zwischen Sign-off und PGP-Signierung

  • githooks.txt: verbessern Sie den Einführungsteil

Wenn Sie sich bei der zu verwendenden Kennung nicht sicher sind, führen Sie git log --no-merges auf den Dateien aus, die Sie modifizieren, um die aktuellen Konventionen zu sehen.

Die Titelzeile nach dem Präfix "bereich:" lässt den Punkt am Ende weg, und das erste Wort wird nicht großgeschrieben (das Weglassen der Großschreibung gilt nur für das Wort nach dem Präfix "bereich:" des Titels), es sei denn, es gibt einen Grund, es großzuschreiben, außer weil es das erste Wort im Satz ist. Z. B. "doc: klären Sie...", nicht "doc: Klären Sie...", oder "githooks.txt: verbessern Sie...", nicht "githooks.txt: Verbessern Sie...". Aber "refs: HEAD wird auch als ref behandelt" ist korrekt, da wir HEAD in Großbuchstaben schreiben, auch wenn es mitten im Satz vorkommt.

Der Körper sollte eine aussagekräftige Commit-Nachricht enthalten, die

  1. erklärt das Problem, das die Änderung zu lösen versucht, d.h. was ist falsch am aktuellen Code ohne die Änderung.

  2. rechtfertigt die Art und Weise, wie die Änderung das Problem löst, d.h. warum das Ergebnis mit der Änderung besser ist.

  3. alternative Lösungen, die in Betracht gezogen, aber verworfen wurden, falls vorhanden.

Die Problembeschreibung, die den Status Quo beschreibt, wird im Präsens geschrieben. Schreiben Sie "Der Code macht X, wenn er die Eingabe Y erhält", anstatt "Der Code tat früher Y, wenn er die Eingabe X erhielt". Sie müssen nicht "Aktuell" sagen - der Status Quo in der Problembeschreibung bezieht sich nach Projektkonvention auf den Code ohne Ihre Änderung.

Beschreiben Sie Ihre Änderungen im Imperativ, z. B. "lass xyzzy frotz machen" anstatt "[Dieser Patch] macht xyzzy frotz" oder "[Ich] habe xyzzy geändert, um frotz zu machen", als ob Sie dem Codebefehle zur Änderung seines Verhaltens geben. Versuchen Sie sicherzustellen, dass Ihre Erklärung ohne externe Ressourcen verstanden werden kann. Anstatt eine URL zu einem Mailinglistenarchiv anzugeben, fassen Sie die relevanten Punkte der Diskussion zusammen.

Es gibt mehrere Gründe, warum Sie auf einen anderen Commit im "stabileren" Teil der Historie (d. h. in Branches wie maint, master und next) verweisen möchten:

  1. Ein Commit, der die Ursache eines Fehlers eingeführt hat, den Sie beheben.

  2. Ein Commit, der eine Funktion eingeführt hat, die Sie erweitern.

  3. Ein Commit, der mit Ihrer Arbeit kollidiert, als Sie einen Test-Merge Ihrer Arbeit in next und seen zum Testen vorgenommen haben.

Wenn Sie auf einen Commit in einem stabileren Branch (wie master, maint und next) verweisen, verwenden Sie das Format "abgekürzter Hash (Betreff, Datum)", wie folgt:

	Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
	noticed that ...

Der Befehl "Commit-Referenz kopieren" von gitk kann verwendet werden, um dieses Format zu erhalten (mit dem Betreff in doppelte Anführungszeichen eingeschlossen), oder dieser Aufruf von git show:

	git show -s --pretty=reference <commit>

oder, auf einer älteren Git-Version ohne Unterstützung für --pretty=reference:

	git show -s --date=short --pretty='format:%h (%s, %ad)' <commit>

Zertifizieren Sie Ihre Arbeit durch Hinzufügen Ihres Signed-off-by-Trailers

Um die Nachverfolgung zu verbessern, wer was getan hat, bitten wir Sie, zu zertifizieren, dass Sie den Patch geschrieben haben oder das Recht haben, ihn unter der gleichen Lizenz wie unsere weiterzugeben, indem Sie Ihren Patch "signieren". Ohne Unterschrift können wir Ihre Patches nicht annehmen.

Wenn Sie (und nur dann, wenn) Sie das Folgende zertifizieren:

Entwicklerzertifikat für Herkunft 1.1

Durch meinen Beitrag zu diesem Projekt bestätige ich, dass

  1. Der Beitrag wurde ganz oder teilweise von mir erstellt und ich habe das Recht, ihn unter der in der Datei angegebenen Open-Source-Lizenz einzureichen; oder

  2. Der Beitrag basiert auf früheren Arbeiten, die meiner Kenntnis nach unter einer geeigneten Open-Source-Lizenz stehen und ich habe das Recht unter dieser Lizenz, diese Arbeit mit Modifikationen, ob ganz oder teilweise von mir erstellt, unter der gleichen Open-Source-Lizenz (sofern ich nicht berechtigt bin, unter einer anderen Lizenz einzureichen) einzureichen, wie in der Datei angegeben; oder

  3. Der Beitrag wurde mir direkt von einer anderen Person zur Verfügung gestellt, die (a), (b) oder (c) zertifiziert hat, und ich habe ihn nicht modifiziert.

  4. Ich verstehe und stimme zu, dass dieses Projekt und der Beitrag öffentlich sind und dass eine Aufzeichnung des Beitrags (einschließlich aller persönlichen Informationen, die ich damit einreiche, einschließlich meiner Unterschrift) auf unbestimmte Zeit aufbewahrt wird und im Einklang mit diesem Projekt oder den beteiligten Open-Source-Lizenz(en) weiterverbreitet werden kann.

fügen Sie Ihrem Commit einen "Signed-off-by"-Trailer hinzu, der so aussieht:

	Signed-off-by: Random J Developer <random@developer.example.org>

Diese Zeile kann von Git hinzugefügt werden, wenn Sie den git-commit-Befehl mit der Option -s ausführen.

Beachten Sie, dass Sie Ihren eigenen Signed-off-by-Trailer platzieren können, wenn Sie den Patch eines anderen weiterleiten, unter den oben genannten Regeln für D-C-O. Tatsächlich werden Sie dazu ermutigt. Vergessen Sie nicht, eine "From: "-Zeile im Text am Anfang zu platzieren, um die Änderung ordnungsgemäß dem tatsächlichen Autor zuzuschreiben (siehe (2) oben).

Dieses Verfahren stammt ursprünglich aus dem Linux-Kernel-Projekt, daher ist unsere Regel recht ähnlich zu deren, aber was genau es bedeutet, Ihren Patch zu signieren, unterscheidet sich von Projekt zu Projekt, daher kann es sich von dem Projekt unterscheiden, an das Sie gewöhnt sind.

Bitte verwenden Sie eine bekannte Identität im Signed-off-by-Trailer, da wir keine anonymen Beiträge annehmen können. Es ist üblich, aber nicht zwingend erforderlich, eine Form Ihres echten Namens zu verwenden. Wir erkennen an, dass einige Mitwirkende sich damit nicht wohlfühlen oder es vorziehen, unter einem Pseudonym oder einem bevorzugten Namen beizutragen, und wir können Ihren Patch in beiden Fällen annehmen, solange der verwendete Name und die E-Mail-Adresse eindeutig, identifizierbar und nicht irreführend sind.

Ziel dieser Richtlinie ist es, uns genügend Informationen zu geben, um Sie kontaktieren zu können, wenn Fragen zu Ihrem Beitrag aufkommen.

Wenn Sie möchten, können Sie zusätzliche Trailer am Ende hinzufügen:

  1. Reported-by: wird verwendet, um jemanden zu würdigen, der den Fehler gefunden hat, den der Patch zu beheben versucht.

  2. Acked-by: bedeutet, dass die Person, die mit dem Bereich, den der Patch zu ändern versucht, vertrauter ist, den Patch mochte.

  3. Reviewed-by: kann, im Gegensatz zu den anderen Trailern, nur von den Prüfern selbst angeboten werden, wenn sie nach einer detaillierten Analyse vollständig mit dem Patch zufrieden sind.

  4. Tested-by: wird verwendet, um anzuzeigen, dass die Person den Patch angewendet und festgestellt hat, dass er die gewünschte Wirkung hat.

  5. Co-authored-by: wird verwendet, um anzuzeigen, dass Personen Entwürfe eines Patches ausgetauscht haben, bevor sie ihn eingereicht haben.

  6. Helped-by: wird verwendet, um jemanden für die Bereitstellung von Ideen für Änderungen zu würdigen, ohne die genauen Änderungen in Patchform bereitzustellen.

  7. Mentored-by: wird verwendet, um jemanden für die Unterstützung bei der Entwicklung eines Patches als Teil eines Mentoring-Programms (z. B. GSoC oder Outreachy) zu würdigen.

  8. Suggested-by: wird verwendet, um jemanden für die Anregung der Idee für einen Patch zu würdigen.

Während Sie auch Ihren eigenen Trailer erstellen können, wenn die Situation dies erfordert, ermutigen wir Sie, stattdessen einen der gängigen Trailer in diesem Projekt zu verwenden, der oben hervorgehoben ist.

Kapitalisieren Sie nur den allerersten Buchstaben des Trailers, d.h. bevorzugen Sie "Signed-off-by" gegenüber "Signed-Off-By" und "Acked-by:" gegenüber "Acked-By".

Verwendung von künstlicher Intelligenz (KI)

Das Entwicklerzertifikat für Herkunft verlangt von den Mitwirkenden, dass sie bestätigen, dass sie die Herkunft ihrer Beiträge zum Projekt kennen und dass sie das Recht haben, ihn unter der Lizenz des Projekts einzureichen. Es ist noch nicht klar, ob dies rechtlich erfüllt werden kann, wenn erhebliche Mengen an Inhalten eingereicht werden, die von KI-Werkzeugen generiert wurden.

Ein weiteres Problem mit KI-generierten Inhalten ist, dass KIs oft immer noch halluzinieren oder einfach schlechten Code, Commit-Nachrichten, Dokumentation oder Ausgaben produzieren, selbst wenn Sie sie auf ihre Fehler aufmerksam machen.

Um diese Probleme zu vermeiden, werden wir alles ablehnen, was KI-generiert aussieht, übermäßig formell oder aufgebläht klingt, wie KI-Schrott aussieht, oberflächlich gut aussieht, aber keinen Sinn ergibt, oder das die Absender nicht verstehen oder erklären können.

Wir empfehlen dringend, KI-Werkzeuge sorgfältig und verantwortungsbewusst zu verwenden.

Mitwirkende profitieren oft mehr von KI, indem sie sie nutzen, um sie schrittweise zu einer Lösung zu führen und zu unterstützen, anstatt eine vollständige Lösung zu verlangen, die sie dann hauptsächlich kopieren und einfügen würden. Sie können KI auch zur Fehlersuche oder zur Überprüfung auf offensichtliche Fehler, Dinge, die verbessert werden können, Dinge, die nicht mit unserem Stil, unseren Richtlinien oder unserem Feedback übereinstimmen, verwenden, bevor sie sie uns senden.

Generieren Sie Ihren Patch mit Git-Tools aus Ihren Commits.

Git-basierte Diff-Tools generieren unidiff, das das bevorzugte Format ist.

Sie müssen keine Angst haben, die Option -M für git diff oder git format-patch zu verwenden, wenn Ihr Patch Umbenennungen von Dateien beinhaltet. Die empfangende Seite kann damit gut umgehen.

Bitte stellen Sie sicher, dass Ihr Patch keinen auskommentierten Debugging-Code enthält oder zusätzliche Dateien, die nichts mit dem zu Erreichenden zu tun haben. Überprüfen Sie Ihren Patch nach der Generierung auf Genauigkeit. Bevor Sie ihn absenden, stellen Sie sicher, dass er sich sauber auf den in der Sektion "Wählen Sie einen Ausgangspunkt" gewählten Ausgangspunkt anwenden lässt.

Hinweis
 Aus der Sicht derjenigen, die Ihren Patch überprüfen, ist der master-Branch der standardmäßige erwartete Ausgangspunkt. Wenn Sie also einen anderen Ausgangspunkt gewählt haben, kommunizieren Sie diese Wahl in Ihrem Anschreiben.

Senden Sie Ihre Patches.

Wählen Sie Ihre Prüfer aus

Hinweis
 Patches, die sicherheitsrelevant sein könnten, sollten privat an die Git Security Mailingliste[1] gesendet werden, anstatt an die öffentliche Mailingliste.

Senden Sie Ihren Patch mit "An:" an die Mailingliste, mit "cc:" an Personen, die im betroffenen Bereich involviert sind (das Skript git-contacts in contrib/contacts/[2] kann helfen, sie zu identifizieren), um Kommentare und Überprüfungen zu erhalten. Außerdem haben Sie, als Sie Test-Merges Ihres Themas in next und seen vorgenommen haben, möglicherweise Arbeiten anderer bemerkt, die mit Ihren Änderungen kollidieren. Es besteht eine gute Möglichkeit, dass diese Personen den Bereich, den Sie bearbeiten, gut kennen.

Wenn Sie send-email verwenden, können Sie ihm die Ausgabe von git-contacts wie folgt übergeben:

	git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch

Nachdem die Liste zu dem Konsens gelangt ist, dass die Anwendung des Patches eine gute Idee ist, senden Sie ihn erneut mit "An:" an den Betreuer[3] und "cc:" an die Liste[4] zur Aufnahme. Dies ist besonders relevant, wenn der Betreuer nicht stark an der Diskussion teilgenommen hat und stattdessen die Überprüfung vertrauenswürdigen anderen überlassen hat.

Vergessen Sie nicht, Trailer wie Acked-by:, Reviewed-by: und Tested-by: nach Bedarf hinzuzufügen, um Personen zu würdigen, die Ihren Patch unterstützt haben, und sie bei der Zusendung einer solchen finalen Version zur Aufnahme auf "cc" zu setzen.

format-patch und send-email

Lernen Sie, wenn möglich, format-patch und send-email zu verwenden. Diese Befehle sind für den Arbeitsablauf des Sendens von Patches optimiert und vermeiden viele Möglichkeiten, bei denen Ihr bestehender E-Mail-Client (oft für "multipart/*" MIME-Typ-E-Mails optimiert) Ihre Patches unbrauchbar machen könnte.

Hinweis
 Hier skizzieren wir das Verfahren mit format-patch und send-email, aber Sie können stattdessen GitGitGadget verwenden, um Ihre Patches einzureichen (siehe MyFirstContribution).

Personen in der Git-Mailingliste müssen in der Lage sein, die von Ihnen eingereichten Änderungen zu lesen und zu kommentieren. Es ist wichtig für einen Entwickler, Ihre Änderungen mit Standard-E-Mail-Tools "zitieren" zu können, damit sie bestimmte Teile Ihres Codes kommentieren können. Aus diesem Grund sollte jeder Patch "inline" in einer separaten Nachricht eingereicht werden.

Alle nachfolgenden Versionen einer Patch-Serie und andere verwandte Patches sollten in ihren eigenen E-Mail-Thread gruppiert werden, um Lesern zu helfen, alle Teile der Serie zu finden. Zu diesem Zweck senden Sie sie als Antwort entweder auf eine zusätzliche "Cover Letter"-Nachricht (siehe unten), den ersten Patch oder den entsprechenden vorherigen Patch. Hier ist eine Schritt-für-Schritt-Anleitung zur Einreichung aktualisierter Versionen einer Patch-Serie.

Wenn Ihre Protokollnachricht (einschließlich Ihres Namens im Signed-off-by-Trailer) nicht in ASCII schreibbar ist, stellen Sie sicher, dass Sie eine Nachricht in der richtigen Kodierung senden.

Warnung
 Seien Sie vorsichtig mit dem Zeilenumbruch Ihres MUA, der Ihren Patch beschädigt. Kopieren und fügen Sie Ihren Patch nicht ein; Sie können Tabs dabei verlieren, wenn Sie nicht vorsichtig sind.

Es ist eine gängige Konvention, Ihre Betreffzeile mit [PATCH] zu versehen. Dies ermöglicht es den Leuten, Patches leicht von anderen E-Mail-Diskussionen zu unterscheiden. Die Verwendung von Markern zusätzlich zu PATCH innerhalb der Klammern, um die Art des Patches zu beschreiben, wird ebenfalls empfohlen. Z.B. [RFC PATCH] (wobei RFC für "request for comments" steht) wird oft verwendet, um anzuzeigen, dass ein Patch weitere Diskussionen benötigt, bevor er akzeptiert wird, [PATCH v2], [PATCH v3] usw. werden oft gesehen, wenn Sie eine Aktualisierung des zuvor Gesendeten senden.

Der Befehl git format-patch folgt den besten aktuellen Praktiken zur Formatierung des Nachrichtentexts einer E-Mail. Am Anfang des Patches sollte Ihre Commit-Nachricht stehen, die mit den Signed-off-by Trailern endet, gefolgt von einer Zeile, die aus drei Bindestrichen besteht, dann den Diffstat-Informationen und dem Patch selbst. Wenn Sie einen Patch von jemand anderem weiterleiten, können Sie optional am Anfang der E-Mail, direkt vor der Commit-Nachricht, eine "From: "-Zeile einfügen, um diese Person zu benennen. Um den Standard "[PATCH]" im Betreff zu "[<text>]" zu ändern, verwenden Sie git format-patch --subject-prefix=<text>. Als Abkürzung können Sie --rfc anstelle von --subject-prefix="RFC PATCH" oder -v <n> anstelle von --subject-prefix="PATCH v<n>" verwenden.

Sie möchten oft zusätzliche Erklärungen zum Patch hinzufügen, die über die Commit-Nachricht selbst hinausgehen. Platzieren Sie solches "Cover Letter"-Material zwischen der Drei-Bindestrich-Linie und dem Diffstat. Für Patches, die mehrere Iterationen von Überprüfung und Diskussion erfordern, kann eine Erklärung der Änderungen zwischen jeder Iteration in Git-Notizen aufbewahrt und automatisch nach der Drei-Bindestrich-Linie über git format-patch --notes eingefügt werden.

Dies ist EXPERIMENTELL.

Wenn Sie ein Thema senden, können Sie optional einen Themanamen und/oder eine einabsätzige Zusammenfassung vorschlagen, die im "What’s cooking" Bericht erscheinen soll, wenn das Thema aufgenommen wird, um es zu erklären. Wenn Sie dies tun, schreiben Sie bitte einen 2-5 Zeilen langen Absatz, der gut in unsere Release Notes passt (siehe viele aufzählungspunkte in den Dateien Documentation/RelNotes/* als Beispiele) und machen Sie ihn zum ersten (oder zweiten, wenn ein vorgeschlagener Themaname enthalten ist) Absatz des Cover Letters. Wenn Sie einen Themanamen vorschlagen, verwenden Sie das Format "XX/your-topic-name", wobei "XX" ein Platzhalter für die Initialen des Hauptautors ist und "your-topic-name" eine kurze, mit Bindestrichen getrennte Beschreibung dessen ist, was Ihr Thema tut. Für eine Einzel-Patch-Serie verwenden Sie den Raum zwischen der Drei-Bindestrich-Linie und dem Diffstat, wie oben beschrieben.

Wenn Ihre Patch-Serie Teil einer größeren Anstrengung ist, die sich über mehrere Patch-Serien erstreckt, beschreiben Sie kurz das übergeordnete Ziel und geben Sie an, wo die aktuelle Serie in dieses Ziel passt. Wenn Sie einen Themanamen vorschlagen, wie im obigen Abschnitt, ziehen Sie "XX/the-broader-goal-part-one", "XX/the-broader-goal-part-two" usw. in Betracht.

Hängen Sie den Patch nicht als MIME-Anhang an, weder komprimiert noch unkomprimiert. Lassen Sie Ihren E-Mail-Client kein quoted-printable senden. Lassen Sie Ihren E-Mail-Client kein format=flowed senden, da dies Whitespaces in Ihren Patches zerstören würde. Viele gängige E-Mail-Anwendungen übertragen einen MIME-Anhang nicht immer als Klartext, was es unmöglich macht, Ihren Code zu kommentieren. Ein MIME-Anhang benötigt auch etwas mehr Zeit für die Verarbeitung. Dies verringert nicht die Wahrscheinlichkeit, dass Ihre MIME-angehängte Änderung akzeptiert wird, aber es macht es wahrscheinlicher, dass sie verschoben wird.

Ausnahme: Wenn Ihr Mailer Patches beschädigt, kann es sein, dass jemand Sie bittet, sie erneut über MIME zu senden, das ist in Ordnung.

Signieren Sie Ihren Patch nicht mit PGP. Höchstwahrscheinlich hätten Ihr Maintainer oder andere auf der Liste nicht Ihren PGP-Schlüssel und würden ihn auch nicht besorgen wollen. Ihr Patch wird nicht danach beurteilt, wer Sie sind; ein guter Patch unbekannter Herkunft hat eine weitaus bessere Chance, akzeptiert zu werden, als ein Patch von einem bekannten, angesehenen Ursprung, der schlecht gemacht ist oder falsche Dinge tut.

Wenn Sie wirklich, wirklich, wirklich, wirklich einen PGP-signierten Patch machen möchten, formatieren Sie ihn als "multipart/signed", nicht als text/plain-Nachricht, die mit -----BEGIN PGP SIGNED MESSAGE----- beginnt. Das ist kein text/plain, es ist etwas anderes.

Umgang mit Konflikten und Iterieren von Patches

Bei der Überarbeitung von Änderungen an Ihren Patches ist es wichtig, die Möglichkeit von Konflikten mit anderen laufenden Themen anzuerkennen. Um diese potenziellen Konflikte effektiv zu bewältigen, befolgen Sie die unten aufgeführten empfohlenen Schritte.

  1. Bauen Sie auf einem geeigneten Basis-Branch auf, siehe oben, und formatieren Sie die Serie als Patch. Wenn Sie "rebase -i" inplace durchführen, um von der vorherigen Runde zu aktualisieren, wird die vorherige Basis wiederverwendet, so dass (2) und (3) trivial werden können.

  2. Finden Sie die Basis, von der die letzte Runde eingereiht wurde.

    $ mine='kn/ref-transaction-symref'
$ git checkout "origin/seen^{/^Merge branch '$mine'}...master"

  3. Wenden Sie Ihr format-patch-Ergebnis an. Es gibt zwei Fälle:

    1. Die Dinge werden sauber angewendet und die Tests sind in Ordnung. Gehen Sie zu (4).

    2. Die Dinge werden sauber angewendet, aber der Build schlägt fehl oder die Tests schlagen fehl, oder die Dinge werden nicht sauber angewendet.

      Im letzteren Fall haben Sie textuelle oder semantische Konflikte, die sich aus dem Unterschied zwischen der alten Basis und der Basis ergeben, die Sie in (1) verwendet haben. Identifizieren Sie, was die Fehler verursacht hat (z. B. könnten ein oder zwei Themen zusammengeführt worden sein, seit der Basis, die von (2) verwendet wurde, bis zur Basis, die von (1) verwendet wurde).

      Überprüfen Sie die neueste Version von origin/master (die neuer sein kann als die von (2) verwendete Basis), "merge --no-ff" die Themen, auf die Sie neu angewiesen sind, und verwenden Sie das Ergebnis der Zusammenführung(en) als Basis, bauen Sie die Serie neu auf und testen Sie erneut. Führen Sie format-patch von den letzten solchen Zusammenführungen bis zur Spitze Ihres Themas aus. Wenn Sie

      $ git checkout origin/master
$ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar
$ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux
... rebuild the topic ...

      Dann würden Sie Ihr Thema oberhalb dieser "Vorbereitung des Bodens"-Zusammenführungen formatieren, z.B.

      $ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD

      Vergessen Sie nicht, im Cover Letter zu erwähnen, dass Sie dies getan haben, einschließlich der Themen, die Sie auf Basis von master haben. Gehen Sie dann zu (4).

  4. Machen Sie eine Testzusammenführung Ihres Themas in next und seen, z.B.

    $ git checkout --detach 'origin/seen'
$ git revert -m 1 <the merge of the previous iteration into seen>
$ git merge kn/ref-transaction-symref

    Der "revert" ist notwendig, wenn die vorherige Iteration Ihres Themas bereits in seen ist (wie in diesem Fall). Sie könnten wählen, master..origin/seen von Grund auf neu aufzubauen und Ihre vorherige Iteration auszuschließen, was dem Vorgehen des Maintainers näherkommen könnte.

    Diese Testzusammenführung kann zu Konflikten führen. Sie dient hauptsächlich dazu, zu sehen, welche Konflikte *andere* Themen mit Ihrem Thema haben. Mit anderen Worten, Sie müssen sich nicht darauf verlassen, damit Ihr Thema auf master funktioniert. Es kann die Aufgabe der anderen Thema-Besitzer sein, Konflikte zu lösen, wenn Ihr Thema vor ihren in next geht.

    Machen Sie im Cover Letter eine Notiz über die aufgetretenen Konflikte. Sie müssen sie nicht unbedingt lösen, aber es wäre eine gute Gelegenheit, zu lernen, was andere in verwandten Bereichen tun.

    $ git checkout --detach 'origin/next'
$ git merge kn/ref-transaction-symref

    Dies dient dazu, zu sehen, welche Konflikte Ihr Thema mit anderen Themen hat, die bereits in Arbeit sind. Dies sollte keine Konflikte geben, wenn (3)-2 eine Basis vorbereitet hat, die auf aktualisiertem master plus abhängigen Themen aus next aufgebaut ist. Es sei denn, der Kontext ist schwerwiegend (eine Möglichkeit, dies zu erkennen, ist der Versuch derselben Testzusammenführung mit Ihrer alten Iteration, die auf ähnliche Weise Konflikte haben kann), erwarten Sie, dass dies vom Maintainer behandelt wird (wenn es unüberschaubar wird, werde ich Sie bitten, neu zu basen, wenn ich Ihre Patches erhalte).

Subsysteme mit dedizierten Maintainern

Einige Teile des Systems haben dedizierte Maintainer mit eigenen Repositories.

  • git-gui/ kommt vom git-gui-Projekt, gepflegt von Johannes Sixt

    https://github.com/j6t/git-gui
    Contibutions should go via the git mailing list.

  • gitk-git/ kommt vom gitk-Projekt, gepflegt von Johannes Sixt

    https://github.com/j6t/gitk
    Contibutions should go via the git mailing list.

  • po/ kommt vom Lokalisierungs-Koordinator, Jiang Xin

    https://github.com/git-l10n/git-po/

Patches für diese Teile sollten auf ihren Trees basieren.

  • Das "Git documentation translations"-Projekt, geleitet von Jean-Noël Avila, übersetzt unsere Dokumentationsseiten. Ihre Arbeitsergebnisse werden separat von diesem Projekt gepflegt, nicht als Teil unseres Trees.

    https://github.com/jnavila/git-manpages-l10n/

GitHub CI

Mit einem GitHub-Konto können Sie GitHub CI verwenden, um Ihre Änderungen unter Linux, Mac und Windows zu testen. Sehen Sie sich https://github.com/git/git/actions/workflows/main.yml an, um Beispiele für aktuelle CI-Läufe zu sehen.

Befolgen Sie für die anfängliche Einrichtung diese Schritte

  1. Forken Sie https://github.com/git/git zu Ihrem GitHub-Konto. Detaillierte Anweisungen zum Forken finden Sie hier: https://help.github.com/articles/fork-a-repo/

Nach der anfänglichen Einrichtung läuft CI jedes Mal, wenn Sie neue Änderungen in Ihren Git-Fork auf GitHub pushen. Sie können den Teststatus aller Ihrer Branches hier überwachen: https://github.com/<Your GitHub handle>/git/actions/workflows/main.yml

Wenn ein Branch nicht alle Testfälle besteht, wird er mit einem roten x anstelle eines grünen Häkchens markiert. In diesem Fall können Sie auf den fehlgeschlagenen Job klicken und zu "ci/run-build-and-tests.sh" und/oder "ci/print-test-failures.sh" navigieren. Sie können auch "Artifacts" herunterladen, bei denen es sich um Zip-Archive mit tar- oder Zip-Archiven handelt, die Testdaten für das Debugging enthalten.

Beheben Sie dann das Problem und pushen Sie Ihre Korrektur in Ihren GitHub-Fork. Dies löst einen neuen CI-Build aus, um sicherzustellen, dass alle Tests bestanden werden.

MUA spezifische Hinweise

Einige der Patches, die ich erhalte oder von der Liste aufgreife, weisen gemeinsame Bruchmuster auf. Bitte stellen Sie sicher, dass Ihr MUA richtig konfiguriert ist, um Whitespaces nicht zu beschädigen.

Siehe den ABSCHNITT DISKUSSION von git-format-patch[1] für Hinweise zum Überprüfen Ihres Patches, indem Sie ihn an sich selbst mailen und mit git-am[1] anwenden.

Während Sie dabei sind, überprüfen Sie die resultierende Commit-Log-Nachricht eines Testlaufs der Patch-Anwendung. Wenn das, was im resultierenden Commit steht, nicht genau das ist, was Sie sehen möchten, ist es sehr wahrscheinlich, dass Ihr Maintainer die Log-Nachricht bearbeiten wird, wenn er Ihren Patch anwendet. Dinge wie "Hi, this is my first patch.\n", wenn Sie sie wirklich in die Patch-E-Mail aufnehmen möchten, sollten nach der Drei-Bindestrich-Linie kommen, die das Ende der Commit-Nachricht signalisiert.

Pine

(Johannes Schindelin)

I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.

... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.

(Linus Torvalds)

And 4.58 needs at least this.

diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Mon Aug 15 17:23:51 2005 -0700

    Fix pine whitespace-corruption bug

    There's no excuse for unconditionally removing whitespace from
    the pico buffers on close.

diff --git a/pico/pico.c b/pico/pico.c
--- a/pico/pico.c
+++ b/pico/pico.c
@@ -219,7 +219,9 @@ PICO *pm;
	    switch(pico_all_done){	/* prepare for/handle final events */
	      case COMP_EXIT :		/* already confirmed */
		packheader();
+#if 0
		stripwhitespace();
+#endif
		c |= COMP_EXIT;
		break;

(Daniel Barkalow)

> A patch to SubmittingPatches, MUA specific help section for
> users of Pine 4.63 would be very much appreciated.

Ah, it looks like a recent version changed the default behavior to do the
right thing, and inverted the sense of the configuration option. (Either
that or Gentoo did it.) So you need to set the
"no-strip-whitespace-before-send" option, unless the option you have is
"strip-whitespace-before-send", in which case you should avoid checking
it.

Thunderbird, KMail, GMail

Siehe den ABSCHNITT MUA-SPECIFIC HINTS von git-format-patch[1].

Gnus

"|" im *Summary* Buffer kann verwendet werden, um die aktuelle Nachricht an ein externes Programm zu übergeben, und dies ist ein praktischer Weg, git am zu steuern. Wenn die Nachricht jedoch MIME-kodiert ist, wird das, was in das Programm übergeben wird, die Darstellung sein, die Sie in Ihrem *Article* Buffer nach dem Auspacken von MIME sehen. Das ist oft aus zwei Gründen nicht das, was Sie wollen. Es neigt dazu, Nicht-ASCII-Zeichen (am auffälligsten in Namen von Personen) und auch Whitespaces zu verfälschen (fatal in Patches). Das Ausführen von "C-u g", um die Nachricht im Rohformat anzuzeigen, bevor "|" zum Übergeben verwendet wird, kann dieses Problem umgehen.

1. Die Git Security Mailingliste: git-security@googlegroups.com
2. Skripte unter `contrib/` sind nicht Teil des Kerns `git`-Binärprogramms und müssen direkt aufgerufen werden. Klonen Sie den Git-Quellcode und führen Sie `perl contrib/contacts/git-contacts` aus.
3. Der aktuelle Maintainer: gitster@pobox.com
4. Die Mailingliste: git@vger.kernel.org