Zum Verständnis des Unterschieds zwischen git commit y git commit -a müssen Sie wissen, dass die Index in Git, auch bekannt als die Bereitstellungsraum .
Der Index speichert im Wesentlichen den Zustand jeder Datei, die in die nächste Übertragung einfließen wird. (Mit "Zustand" meine ich hier den genauen Inhalt der Datei, den Git durch seinen Hash identifiziert.) Wenn Sie Folgendes eingeben git commit ohne weitere Parameter, wird git einen neuen Commit machen, in dem die Zustände aller Dateien genau wie im Index sind. Dies kann sich stark von Ihrem Arbeitsbaum unterscheiden, und das ist eine nützliche Funktion von Git, wie ich weiter unten erklären werde.
Was git add ist es, eine Datei "in Szene zu setzen" bzw. ihre aktueller Stand auf den Index. Es spielt keine Rolle, ob die Datei ursprünglich verfolgt wurde oder nicht, Sie sagen: "Bei der nächsten Übertragung soll diese Datei mit genau diesem Inhalt vorhanden sein". Es ist wichtig zu wissen, dass dies den Inhalt aufzeichnet, den Sie hinzufügen wollen, und nicht den Dateinamen - das bedeutet, dass wenn Sie dann weiterhin Änderungen an einer Datei vornehmen, nachdem Sie sie mit git add sehen Sie die Ausgabe von git status das manchmal Leute verwirrt, die von anderen Versionskontrollsystemen kommen:
$ git status
[...]
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# modified: foo.txt
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo.txt
... aber das macht absolut Sinn, wenn man den Index kennt. Sie können die Änderungen sehen, die Sie bereits bereitgestellt haben (d.h. den Unterschied zwischen dem Zustand der Dateien im Index und HEAD, was normalerweise der letzte Commit auf dem Zweig ist, an dem Sie arbeiten) mit:
$ git diff --cached
... und Sie können alle Änderungen, die noch nicht bereitgestellt wurden (d.h. die Differenz zwischen Ihrer Arbeitskopie und dem Index) mit sehen:
$ git diff
Warum ist dies also so nützlich? Im Wesentlichen geht es darum, dass die Geschichte Ihres Projekts am nützlichsten ist, wenn jeder Commit nur eine logisch gruppierte Menge von Änderungen enthält, die eine klar definierte Verbesserung des Projekts darstellen. Je kleiner Sie diese Commits machen können, desto besser, da später das wunderbare Werkzeug git bisect können Sie schnell herausfinden, welche Änderung einen Fehler verursacht hat. Wenn Sie nicht außerordentlich diszipliniert sind, werden Sie bei der Behebung eines Fehlers oft andere Dateien bearbeiten, die Sie nicht wirklich ändern müssen, um das Problem zu beheben, oder Sie werden zwei logisch unterschiedliche Probleme beheben, bevor Sie sich entscheiden, Ihre Änderungen zu übertragen. In diesen Fällen kann der Index Ihnen helfen, die Änderungen zu trennen - einfach git add jede Datei, die Änderungen enthält, die Sie in der ersten Übertragung haben wollen, führen Sie git commit und erstellen dann auf die gleiche Weise die zweite Übertragung. [1]
Wenn Sie sich daran gewöhnt haben und Ihnen der Arbeitsablauf gefällt, werden Sie manchmal nur noch die Bühne benutzen wollen. einige der Änderungen in einer Datei und andere nicht, in diesem Fall sollten Sie sich über git add -p (und dann seine interaktive s y e Optionen!)
Um jedoch auf die ursprüngliche Frage zurückzukommen - was bedeutet git commit -a das anders ist? Im Wesentlichen heißt es: "Bevor du diesen Commit erstellst, überprüfe auch jede Datei, die geändert (oder gelöscht) wurde, auf ihren aktuellen Stand." Wenn Sie also nicht der Meinung sind, dass es sinnvoll ist, die Dateien vor der Übertragung sorgfältig in den Index zu stellen, können Sie einfach immer "git commit -a" verwenden. Ich denke jedoch, dass einer der Vorteile von Git darin besteht, dass es Sie dazu ermutigt, eigene Dateien zu erstellen. schön Übertragungen, und die aktive Nutzung des Indexes ist dabei eine große Hilfe :)
Anmerkungen:
Um die obige Erklärung einfach zu halten, sind einige Aussagen etwas grob (z.B. habe ich nicht erwähnt, dass der Index auch den (nicht-)ausführbaren Zustand der Datei speichert, dass es während einer Zusammenführung mehrere Versionen geben kann, usw. usw.)
[1] Sie sollten damit vorsichtig sein, wenn Sie sicherstellen wollen, dass jeder Commit in Ihrer Historie ordnungsgemäß getestet wurde - wenn das in Ihrem Projekt wichtig ist, sollten Sie den Baum bei jedem neuen Commit testen, bevor Sie ihn pushen...
