Lokales Git-Repository unter Linux verwalten

Einleitung

In diesem Lab lernen Sie die grundlegenden Befehle zur Verwaltung eines lokalen Git-Repositorys in einer Linux-Umgebung. Sie beginnen mit der Initialisierung eines neuen Repositorys mit git init und der Konfiguration Ihrer Benutzeridentität mit git config, was die wesentlichen ersten Schritte für jedes Projekt sind, das Git für die Versionskontrolle verwendet.

Nach der anfänglichen Einrichtung üben Sie den Kern-Git-Workflow. Dazu gehört das Erstellen einer neuen Datei, das Staging für die Nachverfolgung mit git add und das Speichern im Repository-Verlauf mit git commit. Anschließend ändern Sie die Datei, committen die Änderungen und lernen, wie Sie den vollständigen Commit-Verlauf mit dem Befehl git log überprüfen, um die Entwicklung des Projekts zu verstehen.

Ein Git-Repository initialisieren und Benutzereinstellungen konfigurieren

In diesem Schritt beginnen Sie mit der Initialisierung eines neuen Git-Repositorys und der Konfiguration Ihrer Benutzerinformationen. Ein Git-Repository ist ein Verzeichnis, in dem Git Änderungen an Ihren Projektdateien verfolgt. Die Initialisierung eines Repositorys ist der erste Schritt bei der Verwendung von Git für die Versionskontrolle.

Ihr aktuelles Arbeitsverzeichnis ist /home/labex/project. Wir werden dieses Verzeichnis verwenden, um unser Git-Repository zu erstellen.

Führen Sie zuerst den Befehl git init aus. Dieser Befehl erstellt ein neues, leeres Git-Repository im aktuellen Verzeichnis. Dies geschieht durch die Erstellung eines versteckten Unterverzeichnisses namens .git, das alle notwendigen Repository-Dateien enthält.

git init

Sie sollten eine Ausgabe sehen, die bestätigt, dass ein leeres Repository initialisiert wurde:

Initialized empty Git repository in /home/labex/project/.git/

Nachdem das Repository nun erstellt ist, besteht der nächste Schritt darin, Ihre Benutzeridentität einzurichten. Git verwendet diese Informationen, um Ihren Namen und Ihre E-Mail-Adresse mit jedem Commit zu verknüpfen, den Sie erstellen. Dies ist entscheidend, um zu verfolgen, wer welche Änderungen in einem kollaborativen Projekt vorgenommen hat.

Wir verwenden den Befehl git config mit dem Flag --global. Das Flag --global stellt sicher, dass diese Konfiguration für alle Git-Repositorys gilt, mit denen Sie auf diesem System für den Benutzer labex arbeiten.

Führen Sie die folgenden Befehle aus, um Ihren Benutzernamen und Ihre E-Mail-Adresse festzulegen. Für dieses Lab verwenden wir labex als Benutzernamen und [email protected] als E-Mail.

git config --global user.name "labex"
git config --global user.email "[email protected]"

Diese Befehle erzeugen bei Erfolg keine Ausgabe. Um zu überprüfen, ob die Konfiguration korrekt gesetzt wurde, können Sie alle Git-Konfigurationseinstellungen für Ihren Benutzer auflisten:

git config --list

Die Ausgabe zeigt eine Liste aller Einstellungen an, einschließlich des gerade konfigurierten user.name und user.email:

user.name=labex
[email protected]
...

Sie haben nun erfolgreich ein Git-Repository initialisiert und Ihre Benutzeridentität konfiguriert. Sie sind bereit, Dateien hinzuzufügen und Änderungen zu verfolgen.

Die erste Datei mit git add und git commit erstellen und committen

In diesem Schritt erstellen Sie Ihre erste Datei und committen sie in das Git-Repository. Committen ist der Prozess des Speicherns eines Snapshots Ihrer gestagten Änderungen im Verlauf des Repositorys. Dieser Prozess umfasst zwei Hauptbefehle: git add und git commit.

Zuerst erstellen wir eine einfache Datei README.md. Dies ist eine gängige Datei in Projekten, die Informationen über das Projekt liefert. Wir verwenden den Befehl echo, um die Datei zu erstellen und Text hinzuzufügen. Alle Befehle sollten in Ihrem aktuellen Verzeichnis /home/labex/project ausgeführt werden.

echo "Hello, Git" > README.md

Nachdem Sie eine Datei erstellt haben, können Sie den Status Ihres Repositorys mit dem Befehl git status überprüfen. Dieser Befehl zeigt Ihnen den Zustand des Arbeitsverzeichnisses und des Staging-Bereichs an.

git status

Die Ausgabe wird wie folgt aussehen:

On branch master

No commits yet

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

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

Diese Ausgabe besagt, dass README.md eine "untracked file" (nicht verfolgte Datei) ist. Das bedeutet, Git erkennt die Datei, aber sie ist noch kein Teil der Versionshistorie des Repositorys.

Um die neue Datei zu verfolgen, müssen Sie sie zum Staging-Bereich hinzufügen. Der Staging-Bereich ist ein Zwischenschritt, in dem Sie eine Reihe von Änderungen vorbereiten können, bevor Sie sie committen. Verwenden Sie den Befehl git add, um README.md zu staggen.

git add README.md

Dieser Befehl erzeugt keine Ausgabe. Um zu sehen, was passiert ist, führen Sie git status erneut aus.

git status

Nun hat sich die Ausgabe geändert:

On branch master

No commits yet

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

Die Datei wird nun unter "Changes to be committed" (Änderungen, die committet werden sollen) aufgeführt, was bedeutet, dass sie sich im Staging-Bereich befindet und für den nächsten Commit bereit ist.

Schließlich speichern Sie diesen Snapshot mit dem Befehl git commit in der Historie Ihres Projekts. Es ist eine bewährte Methode, jede Commit mit einer beschreibenden Nachricht über das Flag -m zu versehen. Diese Nachricht erklärt, welche Änderungen vorgenommen wurden.

git commit -m "Initial commit: Added README.md"

Nach Ausführung des Befehls sehen Sie eine Bestätigungsnachricht, die den Commit zusammenfasst:

[master (root-commit) <commit_hash>] Initial commit: Added README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Sie haben erfolgreich Ihren ersten Commit durchgeführt! Die Datei README.md ist nun offiziell Teil der Historie Ihres Git-Repositorys.

Eine Datei ändern und die Änderungen committen

In diesem Schritt lernen Sie, wie Sie Änderungen an einer vorhandenen Datei verfolgen. Ein Hauptmerkmal der Versionskontrolle ist die Möglichkeit, zu sehen, wie sich Dateien im Laufe der Zeit entwickeln. Dies geschieht durch das Committen von Änderungen jedes Mal, wenn eine Datei aktualisiert wird.

Wir arbeiten weiterhin mit der Datei README.md im Verzeichnis /home/labex/project. Fügen wir eine neue Textzeile hinzu. Wir verwenden erneut den Befehl echo, aber diesmal mit dem Operator >>, der Inhalt an eine Datei anhängt, anstatt sie zu überschreiben.

echo "This is a new line." >> README.md

Nachdem die Datei geändert wurde, überprüfen wir den Status des Repositorys mit git status.

git status

Git meldet, dass die Datei README.md geändert wurde:

On branch master
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:   README.md

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

Die Ausgabe zeigt modified: README.md unter "Changes not staged for commit" (Änderungen, die nicht für den Commit vorbereitet sind). Das bedeutet, Git hat die Änderung erkannt, aber sie wurde noch nicht zum Staging-Bereich für den nächsten Commit hinzugefügt.

Genau wie bei einer neuen Datei müssen Sie git add verwenden, um die Änderungen zu staggen. Dies teilt Git mit, dass Sie diese spezifischen Änderungen in Ihren nächsten Commit aufnehmen möchten.

git add README.md

Auch dieser Befehl erzeugt keine Ausgabe. Führen wir git status noch einmal aus, um zu bestätigen, dass die Änderung gestaggt wurde.

git status

Die Ausgabe zeigt die Datei nun unter "Changes to be committed" (Änderungen, die committet werden sollen):

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md

Nachdem die Änderungen nun gestaggt sind, können Sie sie in die Historie des Repositorys committen. Verwenden Sie git commit mit einer klaren Nachricht, die die Aktualisierung beschreibt.

git commit -m "Added a new line to README.md"

Sie sehen eine Bestätigungsnachricht für den Commit:

[master <commit_hash>] Added a new line to README.md
 1 file changed, 1 insertion(+)

Sie haben nun erfolgreich eine Datei geändert und die Änderungen committet. Dieser Workflow – ändern, staggen und committen – ist der grundlegende Zyklus, den Sie bei der Arbeit mit Git wiederholt anwenden werden.

Den Commit-Verlauf mit git log überprüfen

In diesem letzten Schritt lernen Sie, wie Sie den Commit-Verlauf Ihres Repositorys überprüfen. Der Befehl git log ist ein mächtiges Werkzeug, mit dem Sie eine chronologische Liste aller vorgenommenen Commits anzeigen können. Dies ist unerlässlich, um zu verstehen, wie sich ein Projekt entwickelt hat.

Führen Sie vom Verzeichnis /home/labex/project aus den Befehl git log aus:

git log

Dieser Befehl zeigt eine detaillierte Liste der von Ihnen vorgenommenen Commits an, wobei der neueste Commit zuerst erscheint. Die Ausgabe wird in etwa wie folgt aussehen:

commit <commit_hash_2> (HEAD -> master)
Author: labex <[email protected]>
Date:   <commit_date_2>

    Added a new line to README.md

commit <commit_hash_1>
Author: labex <[email protected]>
Date:   <commit_date_1>

    Initial commit: Added README.md

Lassen Sie uns die Informationen für jeden Commit aufschlüsseln:

• commit: Ein eindeutiger 40-stelliger SHA-1-Hash, der als Identifikator für den Commit dient.
• Author: Der Name und die E-Mail-Adresse der Person, die den Commit vorgenommen hat, basierend auf Ihrer Git-Konfiguration.
• Date: Der Zeitstempel, der angibt, wann der Commit vorgenommen wurde.
• Commit-Nachricht: Der eingerückte Text ist die Nachricht, die Sie mit dem Flag -m bereitgestellt haben und die den Zweck des Commits erklärt.

Das Log wird in einem Pager-Programm (wie less) angezeigt. Sie können mit den Pfeiltasten nach oben und unten scrollen. Um die Log-Ansicht zu verlassen und zu Ihrer Terminal-Eingabeaufforderung zurückzukehren, drücken Sie einfach die Taste q.

Für eine kompaktere Ansicht des Commit-Verlaufs können Sie das Flag --oneline verwenden. Dies ist nützlich, um einen schnellen Überblick zu erhalten.

git log --oneline

Die Ausgabe wird viel kürzer sein und für jeden Commit nur den Commit-Hash und die Commit-Nachricht in einer einzigen Zeile anzeigen:

<short_hash_2> (HEAD -> master) Added a new line to README.md
<short_hash_1> Initial commit: Added README.md

Herzlichen Glückwunsch! Sie haben nun den grundlegenden Workflow des Initialisierens eines Git-Repositorys, des Hinzufügens und Commitens von Dateien sowie des Überprüfens der Projektgeschichte gelernt.

Zusammenfassung

In diesem Lab haben Sie die grundlegenden Schritte zur Verwaltung eines lokalen Git-Repositorys in einer Linux-Umgebung gelernt. Sie begannen mit der Initialisierung eines neuen Repositorys in einem Projektverzeichnis mit dem Befehl git init. Nach der Initialisierung haben Sie wichtige Benutzereinstellungen, insbesondere Ihren Benutzernamen und Ihre E-Mail-Adresse, mit dem Befehl git config --global konfiguriert, um sicherzustellen, dass alle zukünftigen Commits ordnungsgemäß zugeordnet werden. Der Kern-Workflow der Versionskontrolle wurde dann durch das Erstellen einer neuen Datei, das Staging für den nächsten Commit mit git add und das dauerhafte Speichern der Änderungen in der Repository-Historie mit git commit geübt.

Darüber hinaus haben Sie den iterativen Prozess des Erstellens und Verfolgens von Änderungen geübt. Dies beinhaltete das Ändern einer vorhandenen Datei und das anschließende Wiederholen des Staging- und Commit-Zyklus mit git add und git commit, um die neue Version zu speichern. Schließlich haben Sie gelernt, wie Sie den Projektverlauf mit dem Befehl git log überprüfen können, der eine chronologische Liste aller Commits anzeigt, einschließlich ihrer eindeutigen Identifikatoren, Autoren, Daten und Commit-Nachrichten. Dies bot einen klaren Überblick über die im Laufe der Zeit am Repository vorgenommenen Änderungen.