Zwischen zwei Commits - Teil 1

Was passiert eigentlich zwischen zwei Commits?

Wir schauen uns hier an, wie - grob gesprochen - die Dateien von einem Commit zum nächsten "wandern". Das sind quasi die einfachen Normalfälle. Komplexer wird es, wenn du während dieser "Wanderung" Dinge bpsw. rückgängig machen willst. Aber das lassen wir hier außen vor.

Außerdem betrachten wir nur Änderungen von Dateiinhalten, sprechen aber einfachheitshalber von Dateiänderungen. Auch hier wird es komplexer, wenn du bpsw. den Namen einer Datei ändern willst. Auch das bleibt hier außen vor.

Ausgangsituation ist ein Commit, nennen wir ihn Commit X. Nach diesem Commit X werkeln wir weiter an unserem Projekt und irgendwann sagen wir uns, jetzt machen wir einen neuen Schnappschuß, also Commit X+1.

Die Ausgangssituation: Commit X

  • Das Projektverzeichnis soll wie folgt aussehen und alles Folgende soll sich im Unterordner "Files" abspielen.
📁BetweenTwoCommits
  📁.git
  📁Files
    📄File-A.txt ⇥ "Lorem"
    📄File-B.txt ⇥ "Lorem"
    📄File-C.txt ⇥ "Lorem"

Es gibt einen Commit, Commit X, der alle derzeit vorhandenen Dateien umfasst. Das Git-Repository stimmt also mit dem gegenwärtigen Projektstand überein - die Welt ist in Ordnung.

Der aktuelle Branch soll der Initial-Branch "main" sein.

  • Status-Abfrage im Kurzformat
    • -s = Kurzformat
    • -b = aktueller Branch
.../Files> git status -s -b
## main
  • Status-Abfrage im Langformat
.../Files> git status
On branch main
nothing to commit, working tree clean

Die Abfrage des Status zeigt nichts an, das heißt das Work-Area (working tree clean) und das Stage-Area (nothing to commit) sind leer.

Änderungen vornehmen: Die Welt ist aus den Fugen

Jetzt arbeiten wir weiter und nehmen Änderungen in "File-A.txt" und "File-B.txt" vor.

"File-C.txt" bleibt unverändert.

Außerdem fügen wir eine neue Datei "File-D.txt" mit dem Inhalt "Lorem" hinzu.

Unser Projektordner sieht nun wie folgt aus:

📁Files
  📄File-A.txt ⇥ Änderung       "Lorem" ⇥ "Lorem Ipsum"
  📄File-B.txt ⇥ Änderung       "Lorem" ⇥ "Lorem Ipsum"
  📄File-C.txt ⇥ KEINE Änderung "Lorem"
  📄File-D.txt ⇥ neue Datei     "Lorem"

Und diese Änderungen spiegeln sich nun in unserem Git-Repository wieder.

BetweenTwoCommits-Changes

  • Status-Abfrage im Kurzformat
.../Files> git status -s

_M File-A.txt
_M File-B.txt

?? File-D.txt

Das Work-Area ist nicht mehr leer, sondern es werden diejenigen Dateien aufgelistet bei denen sich irgendetwas geändert hat.

Nicht aufgelistet wird "File-C.txt", denn hier hat sich ja nichts geändert.

Im Kurzformat findest du alle Informationen, die du benötigst, du musst sie "nur" lesen können, aber darauf gehe ich an anderer Stelle ein.

Der Git Dateistatus wird im Kurzformat durch zwei Zeichen angezeigt.

  • Das erste Zeichen steht für das Stage-Area.
  • Das zweite Zeichen steht für das Work-Area.
  • Mit dem Unterstrich _ kennzeichne ich hier das Leerzeichen.

  • _M = Dateistatus

    • Die Datei ist nicht im Stage-Area, erkennbar am fehlenden ersten Statuszeichen, bzw. des Leerzeichens _.
    • Die Datei ist verändert (modified) und im Work-Area, erkennbar am zweiten Statuszeichen M.
  • ?? = Dateistatus

    • Die Datei wird nicht getrackt, sprich ist "untracked". Die Datei befindet sich weder im Work-Area noch im Stage-Area.
  • Status-Abfrage im Langformat

Das Langformat beschreibt es ausführlicher und gibt dir noch Hinweise, was du denn so alles tun könntest.

.../Files> git status
On branch main

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   File-A.txt
        modified:   File-B.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        File-D.txt

no changes added to commit (use "git add" and/or "git commit -a")

Das sind wirklich wichtige Hinweise, die du dir genau anschauen solltest auch wenn du nicht alles sofort verstehen kannst.

  • (use "git restore <file>..." to discard changes in working directory) Ich habe zwar jetzt keine Ahnung was das denn nun bedeutet, aber immerhin kann ich wohl erahnen, dass es wohl einen Git-Befehl gibt, mit dem ich irgendetwas rückgängig machen kann. Darum geht es hier zwar überhaupt nicht, wie ich anfangst erläutert habe, aber ich ahne doch schon für irgendwann später, wenn ich mal Mist baue, was bei mir nicht gerade selten vorkommt, kann ich das eventuell ganz einfach rückgängig machen.

git add :: Die Verfolgung aufnehmen

BetweenTwoCommits-Tracking

Wollen wir die neue Datei "File-D.txt" tracken? Ja, wollen wir, oder?

.../Files>git add "File-D.txt"
  • Status-Abfrage im Kurzformat
.../Files> git status -s

vorher          |  nachher
----------------|--------------------
_M File-A.txt   |  _M File-A.txt
_M File-B.txt   |  _M File-B.txt
?? File-D.txt   |  A_ File-D.txt
  • A_ = Dateistatus für "File-D.txt".
    • Die Datei ist im Stage-Area, erkennbar am ersten Statuszeichen A, wobei A für "added" steht.
    • Die Datei ist nicht im Work-Area, erkennbar am fehlenden zweiten Statuszeichen, bzw. dem Leerzeichen _.

Beachte: "File-D.txt" landet nicht etwa im Work-Area, wie man durchaus denken könnte, sondern direkt im Stage-Area. Denn - der Git-Befehl git add ... fügt die entsprechenden Dateien immer dem Stage-Area hinzu. In diesem Sinne gibt es einen expliziten Git-Befehl eine Datei zu tracken eigentlich gar nicht.

Überhaupt gilt, für das Work-Area brauchst du keinen speziellen Befehl, eine Datei (die getrackt wird) landet automatisch im Work-Area, sobald du irgendeine Änderung vornimmst.

  • Status-Abfrage im Langformat
.../Files> git status
On branch main

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   File-D.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   File-A.txt
        modified:   File-B.txt

git add :: Die Vorbereitungen treffen

BetweenTwoCommits-Preparations

Und nun noch einmal den git add Befehl, diesmal in seiner offensichtlichen Funktion, nämlich eine Datei dem Stage-Area hinzuzufügen.

.../Files> git add File-A.txt
  • Status Abfrage im Kurzformat
.../Files> git status -s

vorher          |  nachher
----------------|--------------------
_M File-A.txt   |  M_ File-A.txt
_M File-B.txt   |  _M File-B.txt
A_ File-D.txt   |  A_ File-D.txt
  • M_ File-A.txt ist nun im Stage-Area M und nicht mehr im Work-Area _.

git commit :: Die Endsituation Commit X+1

BetweenTwoCommits_CommitX1

Und jetzt wollen wir mal commiten.

...\Files> git commit -m "Commit X+1"

[main f0cd052] Commit X+1

2 files changed, 3 insertions(+), 1 deletion(-)
create mode 100644 Files/File-D.txt

"Commit X+1" spiegelt nun den aktuellen Stand des Git-Repositories wieder. Dieser stimmt aber nicht mit dem aktuellen Projektstand überein, denn "File-B.txt" wurde ja nicht übernommen.

  • Status-Abfrage im Kurzformat
.../Files> git status -s

vorher          |  nachher
----------------|--------------------
M_ File-A.txt   |  
_M File-B.txt   |  _M File-B.txt
A_ File-D.txt   |  

"File-A.txt" und "File-D.txt" waren im Stage-Area und wurden damit in "Commit X+1" übernommen. Sie werden nicht mehr angezeigt, denn für sie gilt ja jetzt, dass ihr gegenwärtiger Stand mit dem Stand des Git-Repository übereinstimmt, anders ausgedrückt, für diese Dateien ist die Welt wieder in Ordnung.

Übrig bleibt "File-B.txt", die sich nach wie vor im Work-Area befindet. Das ist nicht ungewöhnlich, du hast in "File-B.txt" etwas geändert, bist aber noch nicht fertig oder willst oder brauchst diese Änderung für "Commit X+1" nicht.

Mach dir zum Schluß noch einmal klar, wie es in der wirklichen Welt, sprich deinem Projektverzeichnis aussieht.

📁Files
  📄File-A.txt ⇥ "Lorem Ipsum"
  📄File-B.txt ⇥ "Lorem Ipsum"
  📄File-C.txt ⇥ "Lorem"
  📄File-D.txt ⇥ "Lorem"

In dem letzten Commit deines Git-Repositories, also "Commit X+1", dagegen:

BetweenTwoCommits-CommitX+1-Standalone