Ist der Staging-Bereich von Git nur ein Index?

Das Buch Pro Git sagt, dass der Staging-Bereich nur eine Liste oder ein Index ist, der angibt, welche Dateien übergeben werden, wenn a git commit ist fertig, und jetzt der Name index ist allgemein als “Staging-Bereich” bekannt.

Aber wenn wir die Datei ändern foo.txt das ist bereits Teil des Repos, und verwenden git add foo.txt um es bereitzustellen und die Datei erneut zu ändern, ist die Datei jetzt sowohl „bereitgestellt“ als auch „geändert“ (wie in git status), und wenn wir ein Commit durchführen, wird die „gestufte“ Version in das Commit aufgenommen. Die zweite Bearbeitung wird nicht eingefügt.

Wie kann also der „Staging-Bereich“ nachverfolgen, was die erste Bearbeitung war, wenn es sich nur um einen Index handelt – eine Liste von Dateien?

Index ist eine Ansicht Ihres Arbeitsverzeichnisses, das zum Commit bereit ist. Es kann als Pre-Commit-Zustand angesehen werden und ist nicht so einfach wie eine “Liste von Dateien”. Wenn Sie das tun git addwird die Datei (mit der Änderung) zum Index hinzugefügt und die neueren Änderungen werden erst angezeigt, wenn Sie sie ebenfalls hinzufügen.

Das index ist wie ein Korb aus der abgeschlossenen Arbeiten. An jedem Punkt können Sie add eine (teil-)fertige Datei dazu Korb aus und es wird die vorherige Kopie durch Ihre aktuelle Kopie ersetzen, so dass Sie sich endgültig dafür entscheiden commit es wird den Inhalt davon verwenden Korb aus (die jetzige index), um das Commit zu erstellen.

Außerdem Ihr früher add muss ein Blob-Objekt innerhalb des Repos erstellen, das bei Bedarf über die verschiedenen Protokolle gefunden werden kann. Nach einer Weile (30 Tage+) verschwindet es mit gc.

Es ist ein Index, aber zu einer Liste von Änderungsbäumen, nicht direkt zu Dateien. Sehen die verschiedenen Arten von Objekten Git-Handle.

Wie kann also der „Staging-Bereich“ nachverfolgen, was die erste Bearbeitung war, wenn es nur ein Index ist – eine Liste?

Ein Index ist eine Liste von Namen und Verweise auf Inhalte. In Büchern sind es die Seitenzahlen. Im Git-Index sind es die Objekt-IDs in der Objektdatenbank des Repositorys.

Das ist der Git-Index, eine mit Pfadnamen indizierte Liste von Inhaltszeigern.

git add für einige Pfadnamen ist im Grunde

sha=`git hash-object -w path/to/it`
git update-index --cacheinfo 100644,$sha,path/to/it 

außer git add sucht nach ausführbaren Dateien und verwendet 100755 für diese, und fügt rekursiv hinzu und überprüft Ihre .gitignore und was auch immer sonst so aussieht, als wäre es normalerweise am bequemsten. Es ist ein praktischer Befehl zum Hinzufügen von Inhalten zur Objektdatenbank und zum Aktualisieren des Index.

Der Bereitstellungsbereich ist nicht nur eine Liste, noch ein Index, der sagt die Dateien werden festgeschrieben, wenn ein Git-Commit abgeschlossen ist.

Wenn es das wäre, also eine einfache Liste, git add könnte niemals wie angekündigt funktionieren.

Eher, git add muss den Inhalt der Datei zu dem Zeitpunkt speichern, zu dem der Add-Befehl gegeben wird. So dass es Schnappschüsse Dateien und legt diese Schnappschüsse dann in den Staging-Bereich (auch bekannt als “der Index”, was meiner Meinung nach wirklich eine ziemlich schlechte Wahl für einen Namen ist).

Also ja, tatsächlich ist die Aussage des Buches irreführend und verwirrend. Aber das ist nicht allzu überraschend. Ein Großteil der Git-Dokumentation ist verwirrend und schlecht durchdacht.

Gehen Sie voran und markieren Sie mich unten. Ich bin sicher, dass ich damit recht habe.