Git: Sollte ich den Index ignorieren, oder gibt es eine Killeranwendung für ihn?

Question

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).

Answer 1

Neben dem interaktiven Staging ist die andere wichtige Verwendung des Indexes während eines Merge-Konflikts: Git stellt die drei Versionen der Datei bereit, damit es weiß, dass die Datei noch nicht fertig ist, und damit eine Version zur Verfügung steht, die nicht mit Konfliktmarkierungen übersät ist. Werkzeuge von Drittanbietern könnten den Index hier nutzen, um eine schöne Schnittstelle für das Zusammenführen bereitzustellen.

Das soll nicht heißen, dass diese Funktion grundsätzlich den Index benötigt - ich bin mir sicher, dass Mercurial Merge-Konflikte auch ohne einen Index bewältigt - aber die Art und Weise, wie Git dies angeht, erscheint mir gut.

Answer 2

Ich ziehe es vor, den Index so weit wie möglich zu ignorieren.

Answer 3

Wenn Sie sichergehen wollen, dass jeder Commit Ihre Testsuite(1) baut und besteht, dann ignorieren Sie den Index so weit wie möglich.

Wenn Sie den Index verwenden (auf die nicht triviale Weise, dass Sie einige Änderungen einchecken, andere aber nicht) Sie überprüfen einen Zustand des Codes, den Sie wahrscheinlich noch nicht erstellt haben oder für den Sie die Testsuite noch nicht ausgeführt haben .

Sicher, für manche Dinge (z. B. eine Änderung der Dokumentation) spielt das wahrscheinlich keine Rolle und es ist völlig sicher, den Index zu verwenden. Aber es ist gut, sich abzugewöhnen, es auf die fehleranfällige Art zu tun und es auf die richtige Art zu tun:

• Verwenden Sie git stash um alles zu verstauen, was Sie nicht verpflichten wollen.
• Bauen Sie, was übrig ist.
• Führen Sie die Testsuite mit den verbleibenden Daten aus.
• Setzen Sie (alles) ein, was übrig ist.
• Entfernen Sie die anderen Änderungen und wiederholen Sie den Vorgang, falls erforderlich.

---

(1): Nicht jeder legt Wert darauf, dass jeder Commit ein baubarer, funktionierender Code ist.

Manche Leute tun das, weil es bedeutet, dass jede Version, die jemand auscheckt, zumindest gebaut und ausgeführt werden kann. Das ist wichtig für Open-Source-Projekte (wo jemand Ihr Projekt jederzeit klonen kann) und hilft bei der Suche nach Fehlern (Sie müssen keine Zeit damit verschwenden, nicht funktionierende Zustände zu überspringen, in denen der Testfall nicht funktioniert).

Wenn Sie sich nicht darum kümmern, dass jeder Commit ein ganzer, funktionierender Zustand des Codes ist, dann ist das nicht wirklich wichtig.