Diese Konfiguration hat keinerlei Einfluss auf die Authentifizierung bei entfernten Diensten; dazu siehe credential.username in git-config[1].

Das Belassen dieses Werts bei der Standardgröße ist in Ordnung, es sei denn, Sie wissen, dass entweder der Remote-Server oder ein Proxy dazwischen HTTP/1.1 (welches die Chunked Transfer Encoding eingeführt hat) nicht unterstützt oder bekanntermaßen fehlerhaft mit gechunkten Daten ist. Dies wird oft (fälschlicherweise) als Lösung für generische Push-Probleme vorgeschlagen, aber da fast jeder Server und Proxy mindestens HTTP/1.1 unterstützt, löst das Erhöhen dieses Werts normalerweise die meisten Push-Probleme nicht. Ein Server oder Proxy, der HTTP/1.1 und Chunked Transfer Encoding nicht korrekt unterstützt, wäre heute im Internet nicht sehr nützlich, da er viel Verkehr brechen würde.

Beachten Sie, dass die Erhöhung dieses Werts den Speicherbedarf bei jedem relevanten Push, den Git über HTTP oder HTTPS durchführt, erhöht, da der gesamte Puffer zugewiesen wird, unabhängig davon, ob er vollständig verwendet wird oder nicht. Daher ist es am besten, ihn beim Standardwert zu belassen, es sei denn, Sie sind sicher, dass Sie einen anderen Wert benötigen.

Wenn Sie einen allgemeinen Editor für die meisten Programme konfigurieren möchten, die einen benötigen, können Sie Ihre Shell-Konfiguration (z. B. ~/.bashrc oder ~/.zshenv) bearbeiten, um eine Zeile einzufügen, die die Umgebungsvariable EDITOR oder VISUAL auf einen geeigneten Wert setzt. Wenn Sie beispielsweise nano bevorzugen, könnten Sie Folgendes schreiben:

Wenn Sie einen Editor speziell für Git konfigurieren möchten, können Sie entweder den Konfigurationswert core.editor oder die Umgebungsvariable GIT_EDITOR setzen. Weitere Details zur Reihenfolge, in der diese Optionen berücksichtigt werden, finden Sie in git-var[1].

Beachten Sie, dass der Editorwert in allen Fällen an die Shell übergeben wird, sodass alle Argumente mit Leerzeichen entsprechend zitiert werden sollten. Zusätzlich gilt: Wenn Ihr Editor beim Aufruf normalerweise vom Terminal entkoppelt wird, sollten Sie ihn mit einem Argument angeben, das dies verhindert, andernfalls sieht Git keine Änderungen. Ein Beispiel für eine Konfiguration, die beide Probleme unter Windows adressiert, ist die Konfiguration "C:\Program Files\Vim\gvim.exe" --nofork, die den Dateinamen mit Leerzeichen zitiert und die Option --nofork angibt, um die Hintergrundausführung des Prozesses zu vermeiden.

Zusätzlich können Sie den store Credential-Manager verwenden, der Anmeldedaten in einer Datei in Ihrem Home-Verzeichnis speichert, oder den cache Credential-Manager, der Ihre Anmeldedaten nicht dauerhaft speichert, aber verhindert, dass Sie für eine bestimmte Zeit danach gefragt werden.

Sie können auch einfach Ihr Passwort eingeben, wenn Sie dazu aufgefordert werden. Obwohl es möglich ist, das Passwort (das prozentkodiert sein muss) in die URL einzufügen, ist dies nicht besonders sicher und kann zur versehentlichen Offenlegung von Anmeldedaten führen, daher wird es nicht empfohlen.

Ein solcher Shell-Befehl kann angegeben werden, indem der Optionswert mit einem Ausrufezeichen beginnt. Wenn Ihr Passwort oder Token in GIT_TOKEN gespeichert wäre, könnten Sie den folgenden Befehl ausführen, um Ihren Credential-Helper einzurichten:

Die meisten Hosting-Provider verwenden ein einziges SSH-Konto zum Pushen; das heißt, alle Benutzer pushen zum git-Konto (z. B. git@git.example.org). Wenn dies bei Ihrem Provider der Fall ist, können Sie mehrere Aliase in SSH einrichten, um klarzustellen, welches Schlüsselpaar verwendet werden soll. Zum Beispiel könnten Sie etwas wie das Folgende in ~/.ssh/config schreiben, wobei Sie die entsprechende private Schlüsseldatei ersetzen:

Dann können Sie Ihre Push-URL anpassen, um git@example_author oder git@example_committer anstelle von git@example.org zu verwenden (z. B. git remote set-url git@example_author:org1/project1.git).

Normalerweise führt dies dazu, dass git status jede Datei im Arbeitsbaum neu lesen muss. Darüber hinaus erlaubt das Sicherheitsmodell von Git nicht, einen Arbeitsbaum über nicht vertrauenswürdige Benutzer hinweg zu teilen, daher ist es nur sicher, einen Arbeitsbaum zu synchronisieren, wenn er nur von einem einzigen Benutzer auf allen Maschinen verwendet wird.

Es ist wichtig, keinen Cloud-Synchronisierungsdienst zum Synchronisieren von Teilen eines Git-Repositorys zu verwenden, da dies zu Beschädigungen führen kann, wie z. B. fehlende Objekte, geänderte oder hinzugefügte Dateien, defekte Refs und eine Vielzahl anderer Probleme. Diese Dienste synchronisieren tendenziell Datei für Datei kontinuierlich und verstehen die Struktur eines Git-Repositorys nicht. Dies ist besonders schlecht, wenn sie das Repository mitten in einer Aktualisierung synchronisieren, da dies sehr wahrscheinlich zu unvollständigen oder teilweisen Aktualisierungen und damit zu Datenverlust führt.

Ein Beispiel für die Art von Beschädigung, die auftreten kann, sind Konflikte über den Zustand von Refs, so dass beide Seiten unterschiedliche Commits in einem Branch haben, den die andere Seite nicht hat. Dies kann dazu führen, dass wichtige Objekte nicht mehr referenziert und möglicherweise von git gc bereinigt werden, was zu Datenverlust führt.

Daher ist es besser, Ihre Arbeit entweder zum anderen System oder zu einem zentralen Server über den normalen Push- und Pull-Mechanismus zu pushen. Dies bewahrt jedoch nicht immer wichtige Daten wie Stashes, daher ziehen es einige Leute vor, einen Arbeitsbaum über Systeme hinweg zu teilen.

Wenn Sie dies tun, ist der empfohlene Ansatz die Verwendung von rsync -a --delete-after (idealerweise mit einer verschlüsselten Verbindung wie mit ssh) auf dem Stammverzeichnis des Repositorys. Sie sollten dabei mehrere Dinge sicherstellen:

Es ist verlockend, bestimmte Funktionen von git update-index zu verwenden, nämlich die Bits `assume-unchanged` und `skip-worktree`, aber diese funktionieren für diesen Zweck nicht richtig und sollten nicht so verwendet werden.

Wenn Ihr Ziel darin besteht, eine Konfigurationsdatei zu ändern, kann es oft hilfreich sein, eine Datei im Repository zu haben, die eine Vorlage oder Standardeinstellungen enthält, die dann kopiert und nach Bedarf geändert werden können. Diese zweite, geänderte Datei wird normalerweise ignoriert, um ein versehentliches Committen zu verhindern.

Für SSH kann Git einen Proxy mithilfe von OpenSSH's ProxyCommand unterstützen. Häufig verwendete Werkzeuge sind netcat und socat. Sie müssen jedoch so konfiguriert sein, dass sie nicht beendet werden, wenn sie EOF auf Standardeingabe sehen, was normalerweise bedeutet, dass netcat -q benötigt und socat ein Timeout mit etwas wie -t 10 benötigt. Dies ist erforderlich, da der Git SSH-Server weiß, dass keine weiteren Anfragen gestellt werden, indem er ein EOF auf Standardeingabe erhält, aber wenn dies geschieht, hat der Server die endgültige Anfrage möglicherweise noch nicht verarbeitet, sodass das Abbrechen der Verbindung zu diesem Zeitpunkt die Anfrage unterbrechen würde.

Ein Beispiel für einen Konfigurationseintrag in ~/.ssh/config mit einem HTTP-Proxy könnte so aussehen:

Beachten Sie, dass der Proxy in allen Fällen vollständig transparent sein muss, damit Git ordnungsgemäß funktioniert. Der Proxy darf die Verbindung in keiner Weise ändern, manipulieren oder puffern, sonst wird Git mit ziemlicher Sicherheit nicht funktionieren. Beachten Sie, dass viele Proxys, einschließlich vieler TLS-Middleboxen, Windows-Antiviren- und Firewall-Programme außer Windows Defender und Windows Firewall sowie Filterproxys, diesen Standard nicht erfüllen und infolgedessen Git beschädigen. Aufgrund der vielen Berichte über Probleme und ihrer schlechten Sicherheitshistorie raten wir von der Verwendung dieser Software- und Geräteklassen ab.

Wenn Git einen normalen Merge zwischen zwei Branches durchführt, werden genau drei Punkte betrachtet: die beiden Branches und ein dritter Commit, der sogenannte *Merge-Basis*, der normalerweise der gemeinsame Vorfahre der Commits ist. Das Ergebnis des Merges ist die Summe der Änderungen zwischen der Merge-Basis und jedem Head. Wenn Sie zwei Branches mit einem normalen Merge-Commit zusammenführen, entsteht ein neuer Commit, der als Merge-Basis fungiert, wenn sie erneut zusammengeführt werden, da es nun einen neuen gemeinsamen Vorfahren gibt. Git muss keine Änderungen berücksichtigen, die vor der Merge-Basis aufgetreten sind, sodass Sie keine Konflikte neu lösen müssen, die Sie zuvor gelöst haben.

Wenn Sie einen Squash-Merge durchführen, wird kein Merge-Commit erstellt; stattdessen werden die Änderungen von einer Seite als regulärer Commit auf die andere Seite angewendet. Das bedeutet, dass sich die Merge-Basis für diese Branches nicht geändert hat, und wenn Git zum nächsten Merge übergeht, berücksichtigt es alle Änderungen, die es beim letzten Mal berücksichtigt hat, plus die neuen Änderungen. Das bedeutet, dass Konflikte möglicherweise erneut gelöst werden müssen. Ähnlich wird alles, was die ...-Notation in git diff, git log oder einer GUI verwendet, dazu führen, dass alle Änderungen seit der ursprünglichen Merge-Basis angezeigt werden.

Daher ist es am besten, immer einen regulären Merge-Commit zu verwenden, wenn Sie zwei langlebige Branches wiederholt zusammenführen möchten.

Infolgedessen, wenn beide Seiten eine Änderung haben und eine Seite diese Änderung rückgängig gemacht hat, ist das Ergebnis, die Änderung einzubeziehen. Dies liegt daran, dass sich der Code auf einer Seite geändert hat und auf der anderen Seite keine Nettoänderung vorhanden ist. In diesem Szenario übernimmt Git die Änderung.

Wenn dies für Sie ein Problem darstellt, können Sie stattdessen einen Rebase durchführen, indem Sie den Branch mit dem Revert auf den anderen Branch rebasen. Ein Rebase in diesem Szenario macht die Änderung rückgängig, da ein Rebase jeden einzelnen Commit, einschließlich des Reverts, anwendet. Beachten Sie, dass Rebase die Historie umschreibt, daher sollten Sie veröffentlichte Branches nur rebasen, wenn Sie sich sicher sind, dass Sie damit einverstanden sind. Weitere Details finden Sie im Abschnitt NOTES in git-rebase[1].

Es ist üblich, pre-commit-Hooks (oder für Commit-Nachrichten commit-msg-Hooks) zu verwenden, um diese Dinge zu überprüfen. Dies ist großartig, wenn Sie als Einzelentwickler arbeiten und möchten, dass die Werkzeuge Ihnen helfen. Die Verwendung von Hooks auf einem Entwicklerrechner ist jedoch keine effektive Richtlinienkontrolle, da ein Benutzer diese Hooks mit --no-verify umgehen kann, ohne bemerkt zu werden (neben verschiedenen anderen Möglichkeiten). Git geht davon aus, dass der Benutzer die Kontrolle über seine lokalen Repositories hat und versucht nicht, dies zu verhindern oder den Benutzer zu verraten.

Darüber hinaus empfinden einige fortgeschrittene Benutzer pre-commit-Hooks als Hindernis für Workflows, die temporäre Commits zum Stagen von Arbeit im Gange verwenden oder Fixup-Commits erstellen. Daher ist es besser, diese Art von Überprüfungen ohnehin auf den Server zu verlagern.

Dazu können Sie ein Muster in gitattributes[5] mit dem Attribut working-tree-encoding angeben. Zum Beispiel setzt das folgende Muster alle C-Dateien auf die Verwendung von UTF-16LE-BOM, was eine gängige Kodierung unter Windows ist:

Sie müssen git add --renormalize ausführen, damit dies wirksam wird. Beachten Sie, dass, wenn Sie diese Änderungen an einem Projekt vornehmen, das plattformübergreifend verwendet wird, Sie diese wahrscheinlich in einer benutzerspezifischen Konfigurationsdatei oder in $GIT_DIR/info/attributes vornehmen möchten, da die Angabe in einer .gitattributes-Datei im Repository für alle Benutzer des Repositorys gilt.

Siehe den folgenden Eintrag für Informationen zur Normalisierung von Zeilenenden und gitattributes[5] für weitere Informationen zu Attributdateien.

Sie können die Dateien im Repository mit Unix-Zeilenenden speichern und sie automatisch auf die Zeilenenden Ihrer Plattform konvertieren. Um dies zu tun, setzen Sie die Konfigurationsoption core.eol auf native und siehe die Frage zu empfohlenen Speicher-Einstellungen für Informationen darüber, wie Dateien als Text oder Binärdateien konfiguriert werden.

Sie können dieses Verhalten auch mit der Einstellung core.whitespace steuern, wenn Sie die Wagenrückläufe nicht aus Ihren Zeilenenden entfernen möchten.

Es ist am besten, eine der Dateien zu entfernen, so dass Sie nur noch eine Datei haben. Sie können dies mit Befehlen wie den folgenden tun (angenommen, zwei Dateien AFile.txt und afile.txt) auf einem ansonsten sauberen Arbeitsbaum:

Dies vermeidet die Berührung der Festplatte, entfernt aber die zusätzliche Datei. Ihr Projekt bevorzugt möglicherweise die Übernahme einer Benennungskonvention, z. B. nur Kleinbuchstaben, um zu verhindern, dass dieses Problem erneut auftritt. Eine solche Konvention kann mit einem pre-receive-Hook oder als Teil eines Continuous Integration (CI)-Systems überprüft werden.

Es ist auch möglich, dass auf jeder Plattform dauerhaft geänderte Dateien auftreten, wenn ein Smudge- oder Clean-Filter auf Ihrem System verwendet wird, aber eine Datei zuvor committet wurde, ohne den Smudge- oder Clean-Filter auszuführen. Um dies zu beheben, führen Sie Folgendes auf einem ansonsten sauberen Arbeitsbaum aus:

Zusätzlich, wenn Sie die Wahl zwischen textbasierten oder nicht-textbasierten Speicherformaten haben, empfehlen wir, Dateien im Textformat zu speichern und sie bei Bedarf in das andere Format zu transformieren. Zum Beispiel wird ein textbasierter SQL-Dump mit einem Datensatz pro Zeile viel besser für Diffing und Merging funktionieren als eine tatsächliche Datenbankdatei. Ähnlich werden textbasierte Formate wie Markdown und AsciiDoc besser funktionieren als Binärformate wie Microsoft Word und PDF.

Ebenso wird im Allgemeinen nicht empfohlen, binäre Abhängigkeiten (z. B. Shared Libraries oder JAR-Dateien) oder Build-Artefakte im Repository zu speichern. Abhängigkeiten und Build-Artefakte werden am besten auf einem Artefakt- oder Paketserver gespeichert, wobei nur Referenzen, URLs und Hashes im Repository gespeichert werden.

Wir empfehlen außerdem, eine gitattributes[5]-Datei einzurichten, um explizit zu kennzeichnen, welche Dateien Text und welche Binärdateien sind. Wenn Sie möchten, dass Git rät, können Sie das Attribut text=auto setzen.

Bei Textdateien stellt Git im Allgemeinen sicher, dass LF-Endungen im Repository verwendet werden. Die Konfigurationsvariablen core.autocrlf und core.eol legen fest, welche Konvention für Zeilenenden beim Auschecken von Textdateien befolgt wird. Sie können auch das Attribut eol (z. B. eol=crlf) verwenden, um zu überschreiben, welche Dateien welche Behandlung von Zeilenenden erhalten.

Zum Beispiel müssen Shell-Dateien im Allgemeinen LF-Endungen haben und Batch-Dateien müssen CRLF-Endungen haben, daher könnte das Folgende in einigen Projekten angemessen sein:

Diese Einstellungen helfen Tools, das richtige Format für Ausgaben wie Patches auszuwählen, und führen dazu, dass Dateien auf der Plattform mit den entsprechenden Zeilenenden ausgecheckt werden.