5.2 Distributed Git - Mitarbeit an einem Projekt

Bevor wir uns mit den spezifischen Anwendungsfällen befassen, hier ein kurzer Hinweis zu Commit-Nachrichten. Gute Richtlinien für die Erstellung von Commits und deren Einhaltung machen die Arbeit mit Git und die Zusammenarbeit mit anderen erheblich einfacher. Das Git-Projekt stellt ein Dokument zur Verfügung, das eine Reihe guter Tipps zur Erstellung von Commits für die Einreichung von Patches enthält – Sie können es im Git-Quellcode in der Datei Documentation/SubmittingPatches lesen.

Erstens sollten Ihre Einreichungen keine Whitespace-Fehler enthalten. Git bietet eine einfache Möglichkeit, dies zu überprüfen – führen Sie vor dem Commit git diff --check aus, der mögliche Whitespace-Fehler identifiziert und Ihnen auflistet.

Wenn Sie diesen Befehl vor dem Commit ausführen, können Sie feststellen, ob Sie dabei sind, Whitespace-Probleme zu committen, die andere Entwickler stören könnten.

Versuchen Sie als Nächstes, jeden Commit als logisch getrennten Satz von Änderungen zu gestalten. Wenn möglich, versuchen Sie, Ihre Änderungen verdaulich zu machen – coden Sie nicht ein ganzes Wochenende lang an fünf verschiedenen Problemen und reichen Sie sie dann am Montag alle als einen einzigen massiven Commit ein. Selbst wenn Sie am Wochenende nicht committen, verwenden Sie am Montag den Staging-Bereich, um Ihre Arbeit in mindestens einen Commit pro Problem aufzuteilen, mit einer nützlichen Nachricht pro Commit. Wenn einige der Änderungen dieselbe Datei ändern, versuchen Sie, git add --patch zu verwenden, um Dateien teilweise zu stagen (detailliert beschrieben in Interaktives Staging). Der Projekt-Snapshot am Ende des Branches ist identisch, egal ob Sie einen oder fünf Commits machen, solange alle Änderungen irgendwann hinzugefügt werden. Versuchen Sie also, es Ihren Mitentwicklern einfacher zu machen, wenn sie Ihre Änderungen überprüfen müssen.

Dieser Ansatz erleichtert auch das Herausziehen oder Zurücksetzen eines der Csets, wenn Sie es später benötigen. Das Umschreiben der Historie beschreibt eine Reihe nützlicher Git-Tricks zum Umschreiben der Historie und zum interaktiven Staging von Dateien – verwenden Sie diese Werkzeuge, um eine saubere und verständliche Historie zu erstellen, bevor Sie die Arbeit an jemand anderen senden.

Das Letzte, was Sie beachten sollten, ist die Commit-Nachricht. Die Gewohnheit, qualitativ hochwertige Commit-Nachrichten zu erstellen, erleichtert die Verwendung von Git und die Zusammenarbeit damit erheblich. Als allgemeine Regel sollten Ihre Nachrichten mit einer einzelnen Zeile beginnen, die nicht mehr als etwa 50 Zeichen lang ist und den Cset prägnant beschreibt, gefolgt von einer Leerzeile und dann einer detaillierteren Erklärung. Das Git-Projekt verlangt, dass die detailliertere Erklärung Ihre Motivation für die Änderung und den Kontrast Ihrer Implementierung mit dem vorherigen Verhalten enthält – dies ist eine gute Richtlinie. Schreiben Sie Ihre Commit-Nachricht im Imperativ: "Fehler beheben" und nicht "Behobene Fehler" oder "Behebt Fehler". Hier ist eine Vorlage, der Sie folgen können, die wir leicht von einer ursprünglich von Tim Pope verfassten angepasst haben

Wenn alle Ihre Commit-Nachrichten diesem Modell folgen, wird es für Sie und die Entwickler, mit denen Sie zusammenarbeiten, viel einfacher. Das Git-Projekt hat gut formatierte Commit-Nachrichten – versuchen Sie, git log --no-merges dort auszuführen, um zu sehen, wie eine gut formatierte Projekt-Commit-Historie aussieht.

Das einfachste Szenario, dem Sie wahrscheinlich begegnen werden, ist ein privates Projekt mit ein oder zwei anderen Entwicklern. "Privat" bedeutet in diesem Kontext Closed-Source – nicht für die Außenwelt zugänglich. Sie und die anderen Entwickler haben alle Push-Zugriff auf das Repository.

In dieser Umgebung können Sie einem Workflow folgen, der dem ähnelt, was Sie bei der Verwendung von Subversion oder einem anderen zentralisierten System tun würden. Sie profitieren immer noch von Dingen wie Offline-Committing und wesentlich einfacherem Branching und Merging, aber der Workflow kann sehr ähnlich sein; der Hauptunterschied besteht darin, dass Merges clientseitig und nicht auf dem Server zum Zeitpunkt des Commits stattfinden. Lassen Sie uns sehen, wie es aussehen könnte, wenn zwei Entwickler beginnen, mit einem gemeinsamen Repository zusammenzuarbeiten. Der erste Entwickler, John, klont das Repository, macht eine Änderung und committet lokal. Die Protokollmeldungen wurden in diesen Beispielen durch …​ ersetzt, um sie etwas zu verkürzen.

Der zweite Entwickler, Jessica, tut dasselbe – klont das Repository und committet eine Änderung

Nun pusht Jessica ihre Arbeit auf den Server, was einwandfrei funktioniert

Die letzte Zeile der obigen Ausgabe zeigt eine nützliche Rückmeldung der Push-Operation. Das Grundformat ist <oldref>..<newref> fromref → toref, wobei oldref die alte Referenz, newref die neue Referenz, fromref der Name der lokalen Referenz, die gepusht wird, und toref der Name der entfernten Referenz, die aktualisiert wird, bedeutet. Sie werden ähnliche Ausgaben wie diese unten in den Diskussionen sehen, so dass ein grundlegendes Verständnis der Bedeutung helfen wird, die verschiedenen Zustände der Repositories zu verstehen. Weitere Details finden Sie in der Dokumentation für git-push.

Weiter mit diesem Beispiel, kurz darauf macht John einige Änderungen, committet sie in seinem lokalen Repository und versucht, sie auf denselben Server zu pushen

In diesem Fall schlägt Johns Push aufgrund von Jessicas früherem Push *ihrer* Änderungen fehl. Dies ist besonders wichtig zu verstehen, wenn Sie an Subversion gewöhnt sind, da Sie feststellen werden, dass die beiden Entwickler nicht dieselbe Datei bearbeitet haben. Obwohl Subversion dies auf dem Server automatisch tut, wenn unterschiedliche Dateien bearbeitet werden, müssen Sie bei Git *zuerst* die Commits lokal zusammenführen. Mit anderen Worten, John muss zuerst Jessicas Upstream-Änderungen abrufen und sie in sein lokales Repository zusammenführen, bevor er pushen darf.

Als erster Schritt holt John Jessicas Arbeit (dies *holt* nur Jessicas Upstream-Arbeit, es führt sie noch nicht mit Johns Arbeit zusammen)

Zu diesem Zeitpunkt sieht Johns lokales Repository ungefähr so aus

Nun kann John Jessicas Arbeit, die er geholt hat, mit seiner eigenen lokalen Arbeit zusammenführen

Solange diese lokale Zusammenführung reibungslos verläuft, wird Johns aktualisierte Historie nun so aussehen

Zu diesem Zeitpunkt möchte John möglicherweise diesen neuen Code testen, um sicherzustellen, dass Jessicas Arbeit keine seiner beeinträchtigt, und solange alles in Ordnung zu sein scheint, kann er die neue zusammengeführte Arbeit endlich auf den Server pushen

Am Ende wird Johns Commit-Historie so aussehen

In der Zwischenzeit hat Jessica einen neuen Topic-Branch namens issue54 erstellt und drei Commits an diesem Branch vorgenommen. Sie hat Johns Änderungen noch nicht geholt, daher sieht ihre Commit-Historie so aus

Plötzlich erfährt Jessica, dass John neue Arbeit auf den Server gepusht hat und sie sie sich ansehen möchte, also holt sie mit git fetch alle neuen Inhalte vom Server, die sie noch nicht hat

Das zieht die Arbeit herunter, die John in der Zwischenzeit hochgeladen hat. Jessicas Historie sieht nun so aus

Jessica denkt, ihr Topic-Branch sei bereit, aber sie möchte wissen, welcher Teil von Johns geholter Arbeit sie zusammenführen muss, damit sie pushen kann. Sie führt git log aus, um das herauszufinden

Die Syntax issue54..origin/master ist ein Log-Filter, der Git auffordert, nur die Commits anzuzeigen, die auf dem letzteren Branch (in diesem Fall origin/master) liegen und die nicht auf dem ersten Branch (in diesem Fall issue54) liegen. Wir werden diese Syntax im Detail in Commit-Bereiche behandeln.

Aus der obigen Ausgabe können wir sehen, dass es einen einzigen Commit gibt, den John gemacht hat und den Jessica noch nicht in ihre lokale Arbeit integriert hat. Wenn sie origin/master zusammenführt, wird dieser einzelne Commit ihre lokale Arbeit ändern.

Nun kann Jessica ihre Topic-Arbeit in ihren master-Branch einfügen, Johns Arbeit (origin/master) in ihren master-Branch einfügen und dann wieder auf den Server pushen.

Zuerst (nachdem sie alle Arbeiten an ihrem issue54-Topic-Branch committet hat) wechselt Jessica zurück zu ihrem master-Branch, um all diese Arbeiten zu integrieren

Jessica kann entweder origin/master oder issue54 zuerst zusammenführen – sie sind beide Upstream, daher spielt die Reihenfolge keine Rolle. Der End-Snapshot sollte unabhängig von der gewählten Reihenfolge identisch sein; nur die Historie wird unterschiedlich sein. Sie entscheidet sich, zuerst den issue54-Branch zusammenzuführen

Es treten keine Probleme auf; wie Sie sehen können, war es ein einfacher Fast-Forward-Merge. Jessica schließt nun den lokalen Zusammenführungsprozess ab, indem sie Johns zuvor geholte Arbeit zusammenführt, die sich im origin/master-Branch befindet

Alles wird sauber zusammengeführt, und Jessicas Historie sieht nun so aus

Nun ist origin/master von Jessicas master-Branch erreichbar, so dass sie erfolgreich pushen können sollte (vorausgesetzt, John hat inzwischen keine weiteren Änderungen gepusht)

Jeder Entwickler hat ein paar Mal committet und die Arbeit des anderen erfolgreich zusammengeführt.

Das ist einer der einfachsten Workflows. Sie arbeiten eine Weile (im Allgemeinen in einem Topic-Branch) und fügen diese Arbeit in Ihren master-Branch ein, wenn sie zur Integration bereit ist. Wenn Sie diese Arbeit teilen möchten, holen und führen Sie Ihren master von origin/master zusammen, falls er sich geändert hat, und pushen Sie ihn schließlich in den master-Branch auf dem Server. Die allgemeine Reihenfolge ist ungefähr so

Im nächsten Szenario werden wir uns die Rollen von Mitwirkenden in einer größeren privaten Gruppe ansehen. Sie lernen, wie man in einer Umgebung arbeitet, in der kleine Gruppen an Features zusammenarbeiten, und diese teambasierten Beiträge dann von einer anderen Partei integriert werden.

Nehmen wir an, John und Jessica arbeiten gemeinsam an einem Feature (nennen wir es "featureA"), während Jessica und ein dritter Entwickler, Josie, an einem zweiten (nennen wir es "featureB") arbeiten. In diesem Fall verwendet das Unternehmen eine Art Integrationsmanager-Workflow, bei dem die Arbeit der einzelnen Gruppen nur von bestimmten Ingenieuren integriert wird und der master-Branch des Haupt-Repos nur von diesen Ingenieuren aktualisiert werden kann. In diesem Szenario wird die gesamte Arbeit in teambasierten Branches durchgeführt und später von den Integratoren zusammengeführt.

Folgen wir Jessicas Workflow, während sie an ihren beiden Features arbeitet und parallel mit zwei verschiedenen Entwicklern in dieser Umgebung zusammenarbeitet. Da sie ihr Repository bereits geklont hat, beschließt sie, zuerst an featureA zu arbeiten. Sie erstellt einen neuen Branch für das Feature und leistet dort einige Arbeiten

Zu diesem Zeitpunkt muss sie ihre Arbeit mit John teilen, also pusht sie ihre featureA-Branch-Commits auf den Server. Jessica hat keinen Push-Zugriff auf den master-Branch – nur die Integratoren haben ihn – also muss sie auf einen anderen Branch pushen, um mit John zusammenzuarbeiten

Jessica E-Mailt John, um ihm mitzuteilen, dass sie einige Arbeiten in einen Branch namens featureA gepusht hat und er sie sich jetzt ansehen kann. Während sie auf Feedback von John wartet, beschließt Jessica, mit Josie an featureB zu arbeiten. Dazu startet sie einen neuen Feature-Branch, der auf dem master-Branch des Servers basiert

Nun macht Jessica ein paar Commits auf dem featureB-Branch

Jessicas Repository sieht nun so aus

Sie ist bereit, ihre Arbeit zu pushen, erhält aber eine E-Mail von Josie, dass ein Branch mit einigen anfänglichen "featureB"-Arbeiten bereits als Branch featureBee auf den Server gepusht wurde. Jessica muss diese Änderungen mit ihren eigenen zusammenführen, bevor sie ihre Arbeit auf den Server pushen kann. Jessica holt zuerst Josies Änderungen mit git fetch

Unter der Annahme, dass Jessica sich immer noch auf ihrem ausgecheckten featureB-Branch befindet, kann sie nun Josies Arbeit mit git merge in diesen Branch einfügen

Zu diesem Zeitpunkt möchte Jessica all diese zusammengeführte "featureB"-Arbeit zurück auf den Server pushen, aber sie möchte nicht einfach ihren eigenen featureB-Branch pushen. Vielmehr möchte Jessica, da Josie bereits einen Upstream-featureBee-Branch begonnen hat, zu *diesem* Branch pushen, was sie mit

Dies wird als Refspec bezeichnet. Sehen Sie sich Die Refspec für eine detailliertere Diskussion von Git-Refspecs und verschiedenen Dingen, die Sie damit tun können, an. Beachten Sie auch das Flag -u; dies steht für --set-upstream, das die Branches für einfacheres Pushen und Ziehen zu einem späteren Zeitpunkt konfiguriert.

Plötzlich erhält Jessica eine E-Mail von John, der ihr mitteilt, dass er einige Änderungen an dem featureA-Branch, an dem sie zusammenarbeiten, gepusht hat, und bittet Jessica, sich diese anzusehen. Wiederum führt Jessica ein einfaches git fetch aus, um *alle* neuen Inhalte vom Server zu holen, einschließlich (natürlich) Johns neuestem Werk

Jessica kann das Log von Johns neuer Arbeit anzeigen, indem sie den Inhalt des neu geholten featureA-Branches mit ihrer lokalen Kopie desselben Branches vergleicht

Wenn Jessica gefällt, was sie sieht, kann sie Johns neue Arbeit mit

Schließlich möchte Jessica vielleicht ein paar kleine Änderungen an all diesen zusammengeführten Inhalten vornehmen, also kann sie diese Änderungen vornehmen, sie in ihren lokalen featureA-Branch committen und das Endergebnis zurück auf den Server pushen

Jessicas Commit-Historie sieht nun ungefähr so aus

Irgendwann informieren Jessica, Josie und John die Integratoren, dass die featureA- und featureBee-Branches auf dem Server für die Integration in die Hauptlinie bereit sind. Nachdem die Integratoren diese Branches in die Hauptlinie zusammengeführt haben, holt ein Fetch den neuen Merge-Commit und lässt die Historie so aussehen

Viele Gruppen wechseln zu Git wegen dieser Fähigkeit, mehrere Teams parallel arbeiten zu lassen und die verschiedenen Arbeitsstränge spät im Prozess zusammenzuführen. Die Fähigkeit kleinerer Untergruppen eines Teams, über entfernte Branches zusammenzuarbeiten, ohne notwendigerweise das gesamte Team einbeziehen oder behindern zu müssen, ist ein großer Vorteil von Git. Die Reihenfolge für den hier gezeigten Workflow ist ungefähr so

Das Mitwirken an öffentlichen Projekten ist etwas anders. Da Sie nicht die Berechtigung haben, Branches im Projekt direkt zu aktualisieren, müssen Sie die Arbeit auf andere Weise an die Maintainer bringen. Dieses erste Beispiel beschreibt das Mitwirken über Forking auf Git-Hosts, die einfaches Forking unterstützen. Viele Hosting-Sites unterstützen dies (einschließlich GitHub, BitBucket, repo.or.cz und andere), und viele Projekt-Maintainer erwarten diesen Stil des Mitwirkens. Der nächste Abschnitt befasst sich mit Projekten, die beigesteuerte Patches per E-Mail akzeptieren.

Zuerst möchten Sie wahrscheinlich das Hauptrepository klonen, einen Topic-Branch für den Patch oder die Patch-Serie erstellen, die Sie beitragen möchten, und dort Ihre Arbeit leisten. Die Reihenfolge sieht im Grunde so aus

Wenn Ihre Branch-Arbeit abgeschlossen ist und Sie bereit sind, sie an die Maintainer zurückzugeben, gehen Sie zur ursprünglichen Projektseite und klicken Sie auf die Schaltfläche "Fork", um Ihren eigenen beschreibbaren Fork des Projekts zu erstellen. Sie müssen dann diese Repository-URL als neues Remote zu Ihrem lokalen Repository hinzufügen; in diesem Beispiel nennen wir es myfork

Sie müssen dann Ihre neue Arbeit in dieses Repository pushen. Es ist am einfachsten, den Topic-Branch, an dem Sie arbeiten, in Ihr gegabeltes Repository zu pushen, anstatt diese Arbeit in Ihren master-Branch zu integrieren und diesen zu pushen. Der Grund dafür ist, dass Sie, wenn Ihre Arbeit nicht akzeptiert wird oder "cherry-picked" wird, Ihren master-Branch nicht zurückspulen müssen (die Git cherry-pick Operation wird detaillierter in Rebase- und Cherry-Pick-Workflows behandelt). Wenn die Maintainer Ihre Arbeit mergen, rebasen oder cherry-picken, erhalten Sie sie irgendwann über das Ziehen von ihrem Repository zurück.

In jedem Fall können Sie Ihre Arbeit mit

Sobald Ihre Arbeit in Ihre Fork des Repositories gepusht wurde, müssen Sie die Maintainer des ursprünglichen Projekts benachrichtigen, dass Sie Arbeit haben, die sie zusammenführen möchten. Dies wird oft als Pull Request bezeichnet, und Sie generieren normalerweise einen solchen Request entweder über die Website – GitHub hat seinen eigenen "Pull Request"-Mechanismus, den wir in GitHub behandeln werden – oder Sie können den Befehl git request-pull ausführen und die anschließende Ausgabe manuell an den Projekt-Maintainer senden.

Der Befehl git request-pull nimmt den Basis-Branch, in den Sie Ihren Topic-Branch ziehen möchten, und die Git-Repository-URL, von der Sie möchten, dass sie ziehen, und erzeugt eine Zusammenfassung aller Änderungen, die Sie zusammengeführt haben möchten. Wenn Jessica John zum Beispiel einen Pull Request senden möchte und sie zwei Commits auf dem Topic-Branch gemacht hat, den sie gerade gepusht hat, kann sie dies tun

Diese Ausgabe kann an den Maintainer gesendet werden – sie teilt ihm mit, von wo aus die Arbeit verzweigt wurde, fasst die Commits zusammen und identifiziert, von wo die neue Arbeit gezogen werden soll.

Bei einem Projekt, für das Sie nicht der Maintainer sind, ist es generell einfacher, einen Branch wie master immer origin/master verfolgen zu lassen und Ihre Arbeit in Topic-Branches zu erledigen, die Sie leicht verwerfen können, wenn sie abgelehnt werden. Das Isolieren von Arbeitsthemen in Topic-Branches erleichtert Ihnen auch das Rebasen Ihrer Arbeit, wenn die Spitze des Haupt-Repositories sich in der Zwischenzeit bewegt hat und Ihre Commits nicht mehr sauber angewendet werden. Wenn Sie beispielsweise ein zweites Thema an das Projekt senden möchten, arbeiten Sie nicht auf dem Topic-Branch weiter, den Sie gerade hochgeladen haben – beginnen Sie erneut vom master-Branch des Haupt-Repositories

Nun ist jedes Ihrer Themen in einem Silo enthalten – ähnlich einer Patch-Warteschlange –, das Sie umschreiben, rebasen und ändern können, ohne dass sich die Themen gegenseitig stören oder voneinander abhängen, so

Nehmen wir an, der Projekt-Maintainer hat eine Reihe anderer Patches übernommen und Ihren ersten Branch ausprobiert, aber er lässt sich nicht mehr sauber zusammenführen. In diesem Fall können Sie versuchen, diesen Branch auf origin/master zu rebasen, die Konflikte für den Maintainer zu lösen und dann Ihre Änderungen erneut einzureichen

Dies schreibt Ihre Historie um, sodass sie nun wie in Commit-Historie nach featureA-Arbeit aussieht.

Da Sie den Branch neu gebasst haben, müssen Sie für Ihren Push-Befehl die Option -f angeben, um den featureA-Branch auf dem Server durch einen Commit zu ersetzen, der kein Nachkomme davon ist. Eine Alternative wäre, diese neue Arbeit auf einen anderen Branch auf dem Server zu pushen (vielleicht featureAv2 genannt).

Sehen wir uns ein weiteres mögliches Szenario an: Der Maintainer hat die Arbeit in Ihrem zweiten Branch angesehen und mag das Konzept, möchte aber, dass Sie ein Implementierungsdetail ändern. Sie werden diese Gelegenheit auch nutzen, um die Arbeit basierend auf dem aktuellen master-Branch des Projekts zu verschieben. Sie starten einen neuen Branch, der auf dem aktuellen origin/master-Branch basiert, squashen die featureB-Änderungen dort, lösen alle Konflikte, nehmen die Implementierungsänderung vor und pushen diese dann als neuen Branch

Die Option --squash nimmt die gesamte Arbeit des zusammengeführten Branches und zerlegt sie in einen einzigen Cset, der den Repository-Zustand so erzeugt, als ob eine echte Zusammenführung stattgefunden hätte, ohne tatsächlich einen Merge-Commit zu erstellen. Das bedeutet, dass Ihr zukünftiger Commit nur einen Elternteil haben wird und es Ihnen ermöglicht, alle Änderungen von einem anderen Branch einzuführen und dann weitere Änderungen vorzunehmen, bevor Sie den neuen Commit aufzeichnen. Auch die Option --no-commit kann nützlich sein, um den Merge-Commit im Falle eines Standard-Merge-Prozesses zu verzögern.

Zu diesem Zeitpunkt können Sie den Maintainer benachrichtigen, dass Sie die angeforderten Änderungen vorgenommen haben und dass er diese Änderungen in Ihrem featureBv2-Branch finden kann.

Viele Projekte haben etablierte Verfahren zur Annahme von Patches – Sie müssen die spezifischen Regeln für jedes Projekt überprüfen, da sie unterschiedlich sein werden. Da es mehrere ältere, größere Projekte gibt, die Patches über eine Entwickler-Mailingliste akzeptieren, werden wir nun ein Beispiel dafür durchgehen.

Der Workflow ist dem vorherigen Anwendungsfall ähnlich – Sie erstellen Topic-Branches für jede Patch-Serie, an der Sie arbeiten. Der Unterschied besteht darin, wie Sie sie dem Projekt übermitteln. Anstatt das Projekt zu forken und in Ihre eigene beschreibbare Version zu pushen, erstellen Sie E-Mail-Versionen jeder Commit-Serie und senden sie per E-Mail an die Entwickler-Mailingliste

Nun haben Sie zwei Commits, die Sie an die Mailingliste senden möchten. Sie verwenden git format-patch, um die im mbox-Format vorliegenden Dateien zu generieren, die Sie an die Liste senden können – es wandelt jeden Commit in eine E-Mail-Nachricht um, wobei die erste Zeile der Commit-Nachricht der Betreff und der Rest der Nachricht plus der Patch, den der Commit einführt, der Körper ist. Das Schöne daran ist, dass das Anwenden eines Patches aus einer mit format-patch generierten E-Mail alle Commit-Informationen ordnungsgemäß beibehält.

Der Befehl format-patch gibt die Namen der von ihm erstellten Patch-Dateien aus. Der Schalter -M weist Git an, nach Umbenennungen zu suchen. Die Dateien sehen dann so aus

Sie können diese Patch-Dateien auch bearbeiten, um zusätzliche Informationen für die E-Mail-Liste hinzuzufügen, die nicht in der Commit-Nachricht erscheinen sollen. Wenn Sie Text zwischen der ----Zeile und dem Beginn des Patches (der Zeile diff --git) einfügen, können die Entwickler ihn lesen, aber dieser Inhalt wird vom Patch-Prozess ignoriert.

Um dies an eine Mailingliste zu senden, können Sie entweder die Datei in Ihr E-Mail-Programm einfügen oder sie über ein Befehlszeilenprogramm senden. Das Einfügen von Text verursacht oft Formatierungsprobleme, insbesondere bei "intelligenteren" Clients, die Zeilenumbrüche und andere Leerzeichen nicht korrekt beibehalten. Glücklicherweise bietet Git ein Werkzeug, das Ihnen hilft, ordnungsgemäß formatierte Patches über IMAP zu senden, was für Sie einfacher sein kann. Wir werden demonstrieren, wie man einen Patch über Gmail sendet, was zufällig der E-Mail-Agent ist, den wir am besten kennen; detaillierte Anweisungen für eine Reihe von Mail-Programmen finden Sie am Ende der bereits erwähnten Datei Documentation/SubmittingPatches im Git-Quellcode.

Zuerst müssen Sie den IMAP-Abschnitt in Ihrer Datei ~/.gitconfig einrichten. Sie können jeden Wert separat mit einer Reihe von git config-Befehlen festlegen oder sie manuell hinzufügen, aber am Ende sollte Ihre Konfigurationsdatei ungefähr so aussehen

Wenn Ihr IMAP-Server kein SSL verwendet, sind die letzten beiden Zeilen wahrscheinlich nicht notwendig und der Hostwert ist imap:// anstelle von imaps://. Wenn dies eingerichtet ist, können Sie git imap-send verwenden, um die Patch-Serie im Ordner "Entwürfe" des angegebenen IMAP-Servers zu platzieren

Zu diesem Zeitpunkt sollten Sie in der Lage sein, zu Ihrem Entwurfsordner zu gehen, das Feld "An" in die Mailingliste zu ändern, an die Sie den Patch senden, möglicherweise den Maintainer oder die verantwortliche Person mit in CC zu nehmen und ihn zu versenden.

Sie können die Patches auch über einen SMTP-Server senden. Wie zuvor können Sie jeden Wert separat mit einer Reihe von git config-Befehlen festlegen oder sie manuell im Abschnitt sendemail in Ihrer Datei ~/.gitconfig hinzufügen

Danach können Sie git send-email verwenden, um Ihre Patches zu senden

Dann gibt Git für jeden Patch, den Sie senden, eine Menge Protokollinformationen aus, die etwa so aussehen

In diesem Abschnitt haben wir mehrere Workflows behandelt und die Unterschiede zwischen der Arbeit als Teil eines kleinen Teams an Closed-Source-Projekten und der Mitarbeit an einem großen öffentlichen Projekt besprochen. Sie wissen jetzt, dass Sie vor dem Committen auf Whitespace-Fehler prüfen und eine großartige Commit-Nachricht schreiben können. Sie haben gelernt, wie man Patches formatiert und sie per E-Mail an eine Entwickler-Mailingliste sendet. Der Umgang mit Merges wurde ebenfalls im Kontext der verschiedenen Workflows behandelt. Sie sind nun gut darauf vorbereitet, an jedem Projekt zusammenzuarbeiten.

Als Nächstes sehen Sie, wie die andere Seite der Medaille funktioniert: die Wartung eines Git-Projekts. Sie lernen, wie man ein wohlwollender Diktator oder Integrationsmanager wird.