Als Subversion-Benutzer ist der Index von Git das herausforderndste neue Konzept, mit dem ich konfrontiert werde, wenn ich erwäge, es für neue Projekte zu verwenden. Ich habe die Kommentare vieler Leute gelesen, die sagen, dass sie den Index nicht benutzen (immer commit -a), aber ich denke, dass es einen triftigen Grund geben könnte, warum ich ihn benutzen sollte. (Ich teile mir den Code mit etwa 5 anderen Entwicklern und arbeite in einer ausgereiften Entwicklungsumgebung, in der wir den Code in Test- und stabile Zweige zusammenführen und Verzweigungen für experimentelle oder wichtige neue Funktionen verwenden).
Antworten
Zu viele Anzeigen?Sie wissen natürlich, dass Sie mit dem Index nur Teile der Dateien übertragen können, die Sie dem Repository hinzufügen wollen. Im Allgemeinen finde ich es aus diesem Grund nützlich. Ich kann Änderungen an Dateien vornehmen, die irgendwie funktionieren, die Teile einchecken, die funktionieren, und dann den Rest vervollständigen und einchecken.
Für eine wirklich eindrucksvolle Demonstration können Sie interaktives Hinzufügen oder Patch-Add (mit git add -i
o git add -p
). Damit können Sie alle Ihre Änderungen durchgehen und sie selektiv in den Index aufnehmen. So können Sie eine ganze Reihe von Änderungen an Ihren Dateien vornehmen und die Übertragungen dennoch aufteilen. Nützlich für diese "Aha"-Fixes, die wir alle von Zeit zu Zeit machen.
Werfen Sie einen Blick auf dieser Screencast um zu sehen, wie es gemacht wird. Erst wenn Sie es selbst ausprobieren, werden Sie sehen, wie nützlich es ist.
Der Grund, warum ich den Index von Git schätze, ist die Bereitstellung lokaler Änderungen. Eine Sache, die man mit dem Index machen kann, ist in etwa dasselbe wie die "Changelist"-Unterstützung von Subversion, nur dass es bequemer ist. Ich stelle oft nur eine oder zwei Dateien von mehreren möglicherweise geänderten Dateien bereit, um einen einzelnen Commit zu erstellen, der nur diese Dateien enthält. Mit Subversion müsste ich mir einen Namen für diese Änderungsliste ausdenken (auch wenn es nur "work" oder "temp" ist) und diesen Namen während des Aufbaus und der Übertragung der Änderungsliste mehrmals eintippen.
Der Index unterstützt auch die git add -p
Funktion, die meiner Meinung nach eine der besten Eigenschaften von Git ist. Siehe Ryan Tomaykos Die Sache mit Git der beschreibt, wie Git das "Problem der verworrenen Arbeitskopie" löst. Sie können einfach Portionen von geänderten Dateien, ohne mit temporären Kopien herumspielen zu müssen oder mit Rückgängig in Ihrem Editor zu tricksen.
Der Index beteiligt sich nicht wirklich an Ihrer Interaktion mit anderen Entwicklern. Er kann jedoch einen erheblichen Einfluss darauf haben, wie Sie mit Git interagieren.
Ich finde den Index sehr nützlich und setze sehr selten -a ein.
Da man nicht immer in ein entferntes Repository überträgt, wenn man einen Commit macht, machen Git-Benutzer normalerweise kleinere, häufigere Commits und übertragen diese in ein gemeinsames Repository, wenn eine "Gruppe" von Änderungen abgeschlossen ist. Das gibt die Flexibilität, einzelne Commits später rückgängig zu machen oder herauszupicken. Angenommen, ich nehme drei Änderungen vor und übertrage sie mit Subversion alle auf einmal, dann möchte ich eine dieser Änderungen rückgängig machen oder nur eine dieser Änderungen auf einen anderen Zweig anwenden - ein sehr fummeliger Prozess. Mit Git können Sie jede Datei, die Sie geändert haben, in den Staging-Bereich legen und dann einzeln übertragen. Natürlich müssen Sie sicherstellen, dass ein Commit intern konsistent ist und dass jeder Änderungssatz "atomar" ist.
Es kann auch sein, dass Sie lokale Änderungen an einer Datei unter Versionskontrolle haben, die Sie nicht übertragen wollen, wie z. B. eine angepasste Konfigurationsdatei (oder ähnliches). Im Staging-Bereich können Sie diese Datei von den Änderungen, die übertragen werden, ausschließen.
Ich halte die Inszenierung von Änderungen aus drei Gründen für äußerst nützlich.
- Ich übertrage Änderungen nicht mehr so oft versehentlich, da ich die Datei in einem zusätzlichen Schritt bearbeiten muss.
- Nachdem ich Änderungen an einer Reihe von Dateien auf einmal durch Codegenerierung oder Mustersubstitution vorgenommen habe, gehe ich gerne die Diffs der einzelnen Dateien durch, bevor ich sie festlege. Die Möglichkeit, eine Datei nach der anderen zu bearbeiten, ist eine gute Möglichkeit, meinen Fortschritt zu markieren.
- Es kann vorkommen, dass ich eine Funktion durcharbeite und dabei einen veralteten Kommentar oder eine schlechte Formatierung in einem nicht verwandten Abschnitt finde. Ich kann eine solche kleine Änderung leicht einordnen und festschreiben, so dass mein Feature-Commit rein und konzentriert bleibt.
Mehrere Leute haben bereits git add -p erwähnt, aber wenn Sie es noch nie benutzt haben, wissen Sie seinen Nutzen vielleicht nicht zu schätzen. Angenommen, Sie haben die folgende Quellcodezeile, die 3 Fehler enthält:
distance= rate \* deltaT; /\* compute tax rate \*/
(Die drei Fehler sind: falsch benannte Variable deltaT, Leerzeichenfehler vor dem '=' und ein ungültiger Kommentar).
Sie haben die Datei bereits bearbeitet, aber Sie möchten 3 verschiedene Übertragungen mit einer entsprechenden Protokollmeldung für jede vornehmen. Mit Git ist das ziemlich trivial, da Sie mit add --patch direkt in einen Editor wechseln und den Patch bearbeiten können.
- See previous answers
- Weitere Antworten anzeigen