Index (Staging Area)

Übungen: Beispielhafte Vorgehensweisen - soweit nicht anders erwähnt - starten wir im Ordner git-projekte.

Wir nutzen im folgenden linuxoide Befehle in der Git Bash von Git for Windows:

Ausgangssituation: (Befehle: pwd, ls -al)

$ pwd
/c/Users/joeb/Documents/git-projekte
$ ls -al
total 4
drwxr-xr-x 1 joeb 197121 0 Jul  9 18:39 ./
drwxr-xr-x 1 joeb 197121 0 Jul 10 15:20 ../

Ordner erstellen und in Ordner gehen: (Befehle: mkdir, cd)

$ mkdir testing
$ cd testing
$ pwd
/c/Users/joeb/Documents/git-projekte/testing
$ ls -al
total 4
drwxr-xr-x 1 joeb 197121 0 Jul 10 19:17 ./
drwxr-xr-x 1 joeb 197121 0 Jul 10 19:17 ../

Git Repository initialisieren: git init

$ git init
Initialized empty Git repository in C:/Users/joeb/Documents/git-projekte/testing/.git/
$ ls -al
total 8
drwxr-xr-x 1 joeb 197121 0 Jul 10 19:19 ./
drwxr-xr-x 1 joeb 197121 0 Jul 10 19:17 ../
drwxr-xr-x 1 joeb 197121 0 Jul 10 19:19 .git/

Es folgt ein entstandenes leere Git-Repo als Baum. Wir nutzen das PowerShell-Cmdlet Show-Tree aus Modul PSCX. Solche Installationen werden in meinen Seminaren für die PowerShell fertig als Git-Repo-WindowsPowerShell-Profile genutzt.

PS C:\Users\joeb\Documents\git-projekte\testing> Show-Tree -ShowLeaf -Force
C:\Users\joeb\Documents\git-projekte\testing
└──.git
    ├──hooks
    │  ├──applypatch-msg.sample
    │  ├──commit-msg.sample
    │  ├──fsmonitor-watchman.sample
    │  ├──post-update.sample
    │  ├──pre-applypatch.sample
    │  ├──pre-commit.sample
    │  ├──pre-push.sample
    │  ├──pre-rebase.sample
    │  ├──pre-receive.sample
    │  ├──prepare-commit-msg.sample
    │  └──update.sample
    ├──info
    │  └──exclude
    ├──objects
    │  ├──info
    │  └──pack
    ├──refs
    │  ├──heads
    │  └──tags
    ├──config
    ├──description
    └──HEAD

Wir rufen den ersten Status für das Git-Projekt ab: git status

$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Oder in Kurzform mit git status -s bzw. als git status --short, was hier (natürlich) nichts ausgiebt.

Dann erstellen wir mal eine erste Datei testdatei.txt: (Befehle: touch, echo mit Umleitung, cat)

$ echo "Zeile 1" > testdatei.txt
$ cat testdatei.txt
Zeile 1

Und jetzt haben wir einen neuen Git Status:

$ git status
On branch master

No commits yet

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

        testdatei.txt

nothing added to commit but untracked files present (use "git add" to track)

$ git status -s
?? testdatei.txt

Git erkennt also eine untracked Datei: testdatei.txt.

Damit Git diese Datei verarbeiten kann, muss diese Datei in den Index / Staged Area: git add

git add mit Rückmeldungen zum LineFeed Verhalten - sonst Leer!
$ git add testdatei.txt
warning: LF will be replaced by CRLF in testdatei.txt.
The file will have its original line endings in your working directory

Hinweis

Statt git add konnte man (früher) auch das Synonym git stage nutzen!

Normalerweise findet man keine Rückmeldung mit git add. Es könnte allerdings auf unterschiedliche Modi für Zeilenwechsel hingewiesen werden:

  • Unix/Linux: nur Line Feed (LF)

  • Windows: Carriage Return & Line Feed (CRLF)

Aus diesem Grund erhalten Windows-User beim Öffnen von Textdateien aus dem Netz häufig einzeilige Texte im Windows Notepad (Windows Standard: Editor).

Falls Probleme auftauchen in gemischten Entwicklungsumgebungen, bitte die folgenden Konfigurationen beachten:

  • core.eol

  • core.safecrlf

  • core.autocrlf

Literatur: s. Das Git Buch - gitbu.ch, Kapitel 1.3.4 „Zeilenenden einstellen“

Aktuellen Git Status abrufen:

$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   testdatei.txt

Wir haben die Datei gestaged - sie befindet sich jetzt in der Staged Area - dem Index.

Jetzt erstellen wir eine zweite Datei testdatei2.txt mit Befehl touch und dann mit ordentlichem Editor (z.B. Notepad++, Visual Studio Code oder auch VIm/Neovim) bearbeiten.

$ touch testdatei2.txt
$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   testdatei.txt

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

        testdatei2.txt

Auch wieder die neue Datei stagen - also dem Index hinzufügen: git add

$ git add testdatei2.txt
$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   testdatei.txt
        new file:   testdatei2.txt

Jetzt befinden sich beide Dateien im Index von Git. Wir ändern eine Datei - hier: testdatei.txt - und fügen neuen Text ein!

Das führt zum aktuellen Status:

$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   testdatei.txt
        new file:   testdatei2.txt

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

        modified:   testdatei.txt

Wir sehen, dass es die Datei testdatei.txt quasi zweimal gibt:

  • in der Staging Area und

  • als modifizierte Dateiversion, die wieder ge-add-ed werden muss

Also: git add für die Datei und wieder Status analysieren:

$ git add testdatei.txt
$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

        new file:   testdatei.txt
        new file:   testdatei2.txt

Alles wieder aktuell im Index (alt. Bez.: Staging Area).

Um unsere Arbeiten jetzt in das Git Repository einschecken zu können, müssen wir ein git commit durchführen. Hierfür sollten wir aber zuerst Anweisungen hinterlegen, welchen Dateien/Ordner ausgeschlossen sein sollen.

Tipp

For dem ersten Commit bitte die .gitignore erstellen.