Ein geändertes Commit ist nicht anders als jedes andere Commit. In diesem Sinne ist es durchaus möglich, zwischen einem "normalen" und einem geänderten Commit zu unterscheiden.
Mit anderen Worten speichert git geänderte Commits in der Geschichte irgendwo?
Es gibt keine Liste, die alle Änderungen enthält, nein. Geänderte Commits sind in der Geschichte genauso wie alle anderen Commits.
Wenn Sie ein Commit ändern, wird es grundsätzlich entfernt und durch ein neues ersetzt (es erhält auch einen neuen Commit-Hash), der die Änderungen vom ursprünglichen Commit + den geänderten Änderungen enthält.
In git reflog können Sie Ihre letzten Aktionen sehen, und das zeigt die Änderung von Commits. Referenzen von dort können verwendet werden, um zum Beispiel eine git commit --amend rückgängig zu machen. Siehe auch Rückgängig machen von "git commit - Ergänzen Sie "done statt git commit" für weitere Details.
Ich glaube nicht, dass ich die Frage verstehe, aber ich denke, ein Teil davon ist, weil ich denke, Sie haben eine falsche Vorstellung davon, was git commit --amend tut.
Ein Commit in git kann nicht wirklich geändert werden. All das git commit --amend schreibt das neue Commit mit einer absichtlich geänderten Eltern-ID.
Sehen wir uns den normalen Prozess für ein neues Commit an.
Bevor Sie den neuen Festschreibevorgang durchführen, ändern Sie einige Dateien in Ihrem Arbeitsbaum. Anschließend verwenden Sie git add , um diese Änderungen zu übernehmen, sodass die neuen Versionen der Dateien festgeschrieben werden. Diese git add setzt die neue Version der Datei in gits "index", d. H. Seinen Staging-Bereich.
Dateien, die bereits im vorherigen Commit waren, befinden sich bereits im Staging-Bereich. Das neue Commit, das Sie vornehmen werden, enthält also alle Originaldateien, außer dass Sie nichts geändert haben und git add -ed dann die neue Version anstelle der alten Version ist.
Nun führen Sie git commit (ohne --amend ) und git folgendes aus:
-m , -F oder laufen Sie Ihren Editor); Der letzte Schritt "erweitert den Zweig", so dass, wenn Sie einige Commits hatten, etwas wie folgt:
%Vor%Sie haben jetzt noch eins:
%Vor% Der Name der Zweigstelle ( master oder was auch immer es sein mag) zeigt jetzt auf Ihre neueste commit H , und H zeigt zurück auf das, was verwendet ist Ihre neueste commit G .
Wenn Sie git commit --amend verwenden, ändert git diese Sequenz nur um ein winziges Bit: Anstatt den neuen Commit ( H ) auf den aktuellen Punkt ( G ) zurückzusetzen, setzt git den neuen einen Punkt zurück auf das übergeordnete Element des aktuellen Benutzers (in diesem Fall F ):
Jetzt zeigt master (oder welcher Zweig auch immer) auf H , was auf F zeigt, und so weiter.
Wenn Sie git log ausführen, beginnt git mit dem aktuellen Commit ( H ) und protokolliert es und wechselt dann zu seinem übergeordneten Element ( F ) und protokolliert es und so weiter. Commit G scheint weg zu sein.
Die SHA-1-ID für G ist immer noch (für 30 Tage standardmäßig) in den "Reflogs". Es gibt einen Reflog für HEAD und einen für Ihre aktuelle Filiale. Wenn du auf dem Zweig master bist und du H erstellt hast, dann ist master@{1} der letzte Tipp von master , der commit G ist. Oder wenn Sie die SHA-1-ID irgendwo auf Ihrem Bildschirm gespeichert haben, können Sie sie ausschneiden und einfügen, um das Commit G zu sehen.
(Der Schalter --amend kann auch einen Merge-Commit ändern. Dies funktioniert genauso wie oben, es bedeutet nur, dass git alle die übergeordneten IDs aus dem alten Zweig-Tipp kopieren muss zu dem neuen.)