Täglicher Entwickler-Workflow: Commit, Push und .gitignore

1. Erste Schritte: Projekt klonen

Fangen wir dort an, wo wir in der letzten Vorlesung aufgehört haben. Sie haben ein Repository auf GitHub erstellt und müssen nun eine lokale Kopie auf Ihren Computer holen, um mit der Arbeit zu beginnen. Dieser Vorgang heißt Klonen.

Schritt 1. Starten Sie Ihre IDE. Wenn ein Projekt geöffnet ist, schließen Sie es über File -> Close Project. Im Startfenster wählen Sie Clone Repository oder Get from VCS.

Schritt 2. Fügen Sie im geöffneten Fenster die URL Ihres Repositories ein. Diese Methode ist nützlich, wenn Sie jemandes Repository klonen. Die URL können Sie auf der Repository-Seite auf GitHub kopieren.

Wenn Sie Ihr eigenes Repository klonen (unser Fall), ist es am einfachsten, sich direkt aus der IDE bei GitHub anzumelden. Wählen Sie dazu die Option Log in to GitHub. Ihre IDE öffnet den Browser zur Autorisierung.

Auf der geöffneten Seite klicken Sie beruhigt auf die grüne Schaltfläche Authorize JetBrains. Danach können Sie Ihre Repositories direkt aus der Liste in der IDE auswählen. Wählen Sie das gewünschte Projekt und klicken Sie auf Clone.

Schritt 3. Ihre IDE fragt, ob Sie diesem Projekt vertrauen. Da es Ihr eigenes Repository ist, klicken Sie auf Trust Project.

Schritt 4. Antivirus-Einrichtung (für Windows-Benutzer)

Die Antivirus-Software Windows kann warnen, dass die IDE versucht, unbekannte Aktionen auszuführen. Da wir Programme erstellen und ausführen werden, müssen wir der IDE uneingeschränkten Zugriff erlauben. Klicken Sie auf die Schaltfläche „Automatically“, damit die IDE die benötigten Ordner selbst zu den Ausnahmen des Antivirus hinzufügt.

2. Änderungen speichern: Commit

commit — das ist ein „Schnappschuss“ bzw. der gespeicherte Zustand Ihres Projekts zu einem bestimmten Zeitpunkt. Denken Sie daran wie an einen Spielstand: Sie können jederzeit darauf zurückspringen, wenn etwas schiefgeht. Jeder Commit hat eine eindeutige Kennung und eine Nachricht, die die vorgenommenen Änderungen beschreibt.

        gitGraph
        commit id: "Initial commit"
        commit id: "Add user authentication"
        commit id: "Fix login button bug"
        commit id: "Refactor database connection"
    

Commit-Verlauf. Jeder neue Commit baut auf dem vorherigen auf und erzeugt so eine chronologische Entwicklung des Projekts.

Schritt 1. Nehmen Sie Änderungen vor.

Wenn Sie ein frisch erstelltes Repository geklont haben, enthält es nur eine Datei — README.md

Öffnen Sie die Datei README.md und fügen Sie eine Beschreibung Ihres Projekts hinzu. Sobald Sie die Datei bearbeiten, hebt die IDE ihren Namen auf der Projektleiste in blau hervor. Das bedeutet, dass die Datei geändert wurde, die Änderungen aber noch nicht in Git gespeichert sind. Die IDE fügt dort, wo Sie Änderungen vorgenommen haben, eine grüne Linie hinzu.

Schritt 2. Öffnen Sie das Commit-Fenster.

Links in der IDE gibt es den Tab Commit. Wenn Sie ihn öffnen, sehen Sie alle Änderungen, die zum Speichern bereit sind. Für den allerersten Commit verdient dieses Fenster besondere Aufmerksamkeit.

Schauen wir uns an, was wir sehen:

• Changes: hier befinden sich Dateien, die bereits in Git verfolgt werden, aber geändert wurden. In unserem Fall ist das README.md, in das wir den Projektplan hinzugefügt haben.
• Unversioned Files: das sind neue Dateien, die Git im Projektordner sieht, aber noch nicht verfolgt.

Es stellt sich die Frage: Muss man all diese Hilfsdateien dem Repository hinzufügen?

Die gute Nachricht: Als wir das Repository auf GitHub erstellt haben, haben wir eine .gitignore-Vorlage gewählt. Diese Datei enthält bereits Regeln, die Git anweisen, unnötige Ordner oder Dateien zu ignorieren. Doch darüber sprechen wir am Ende der Vorlesung ausführlicher.

Für den Moment besteht unsere Aufgabe beim ersten Commit darin, alle wesentlichen Projektdateien zur Historie hinzuzufügen und die Commit-Nachricht zu schreiben.

Schritt 3. Führen Sie den Commit aus.

Klicken Sie auf die Schaltfläche Commit. Fertig! Sie haben einen „Schnappschuss“ Ihres Projekts im lokalen Repository gespeichert. Die Datei wird wieder in der normalen Farbe angezeigt.

3. Änderungen nach GitHub senden: Push

Ihre Commits liegen bislang nur auf Ihrem Computer. Um sie mit dem Team zu teilen oder sicher aufzubewahren, müssen Sie sie in das entfernte Repository auf GitHub senden.

        sequenceDiagram
        participant Lokales Repository (Ihr Computer)
        participant Remote-Repository (GitHub)

        note over Lokales Repository (Ihr Computer): Sie haben einen oder mehrere Commits erstellt.
Sie existieren nur hier.

        Lokales Repository (Ihr Computer) ->> Remote-Repository (GitHub): git push (Commits senden)

        note over Remote-Repository (GitHub): Ihre Commits wurden kopiert
und sicher auf dem Server gespeichert.
    

Schritt 1. Klicken Sie auf die Schaltfläche Push.

Oben rechts in der IDE gibt es einen grünen Pfeil nach oben — das ist die Schaltfläche Push. Klicken Sie darauf.

Schritt 2. Prüfen und bestätigen.

Es öffnet sich ein Fenster, in dem Sie alle Commits sehen, die zum Senden bereit sind. Das ist Ihre letzte Chance sicherzugehen, dass genau das gesendet wird, was Sie möchten. Klicken Sie auf Push.

Wenn alles erfolgreich war, sehen Sie Meldungen: Pushed commits to origin/main. Create pull request

Schritt 3. Prüfen Sie das Ergebnis auf GitHub.

Nach dem erfolgreichen Senden öffnen Sie die Seite Ihres Repositories auf GitHub. Sie werden sehen, dass Ihre Änderungen dort angekommen sind.

4. Git-Steuerzentrale

Ihre IDE hat ein spezielles Menü Git, das Sie in der oberen Leiste finden. Das ist Ihre Schaltzentrale für die Versionsverwaltung. Schauen wir uns die wichtigsten Punkte kurz an.

• Commit: öffnet das bereits bekannte Fenster, um Änderungen zu speichern.
• Push: öffnet das Fenster zum Senden Ihrer Commits an GitHub.
• Update Project: eine sehr wichtige Funktion. Sie lädt die neuesten Änderungen anderer Teammitglieder herunter (führt git pull aus). Drücken Sie sie jeden Morgen vor Arbeitsbeginn!
• Branches: öffnet das Fenster zur Verwaltung der Branches. Damit beschäftigen wir uns ausführlich in der nächsten Vorlesung.
• Show Git Log: zeigt die gesamte Commit-Historie Ihres Projekts. Ihre persönliche Zeitmaschine.

5. Verwendung von .gitignore-Dateien

Wenn Sie in Ihrem Projekt einige Hilfsdateien hinzugefügt haben und nicht möchten, dass sie versehentlich ins Repository gelangen, können Sie sie von der Verfolgung ausschließen. Dafür gibt es eine Datei namens .gitignore. Das ist sehr praktisch, wenn es im Projekt Dateien gibt, die nicht im Versionskontrollsystem gespeichert werden sollen (z. B. temporäre Dateien, Logs, Passwörter).

Schritt 1. Legen Sie zunächst im Projektverzeichnis eine Datei an, die Sie ignorieren möchten. Zum Beispiel notes.txt. Klicken Sie nach dem Erstellen auf Cancel, falls die IDE anbietet, sie zu Git hinzuzufügen.

Schritt 2. Klicken Sie im Fenster „Project“ mit der rechten Maustaste auf die erstellte Datei. Gehen Sie zu Git --> Add to .gitignore --> Add to .gitignore. Diese Option fügt die ausgewählte Datei der Datei .gitignore im Wurzelverzeichnis Ihres Projekts hinzu.

Falls Sie noch keine Datei .gitignore haben, schlägt die IDE vor, sie anzulegen. Stimmen Sie zu.

Schritt 3. Ihre IDE fügt den Dateinamen automatisch in .gitignore ein.

Nach dem Hinzufügen zu .gitignore werden ignorierte Dateien in Grau oder Braun angezeigt. Beim Versuch zu committen werden diese Dateien ignoriert. Den Ordner .idea kann man in die Ignore-Liste aufnehmen.

Vergessen Sie nicht, die Datei .gitignore ins Repository zu committen und die Änderungen auf GitHub zu pushen, damit alle Projektteilnehmer dieselben Regeln zum Ignorieren von Dateien verwenden.

Lokale Dateien ausschließen: .git/info/exclude

Zusätzlich zur Datei .gitignore, die verwendet wird, um Dateien für alle Benutzer des Projekts auszuschließen, bietet Git die Möglichkeit, lokale Ignore-Regeln in der Datei .git/info/exclude zu erstellen. Diese werden nicht im Repository committed und gelten nur für Ihre lokale Kopie des Projekts.

Das kann beispielsweise nützlich sein, um Dateien zu ignorieren, die von Ihrer IDE erstellt werden, nicht in die Versionskontrolle gehören und nur für Sie spezifisch sind.

Wichtig! Lokale Ignore-Regeln gelten nur für Ihre lokale Kopie des Repositories.

Was, wenn ich bereits committed habe?

.gitignore ignoriert nur neue, noch nicht verfolgte Dateien. Wenn Sie eine Datei bereits committed haben, befindet sie sich in der Repository-Historie, und Git wird sie weiter verfolgen, selbst wenn Sie sie in .gitignore aufnehmen. Für solche Situationen gibt es den Terminal-Befehl: git rm --cached <file>. Dazu sollten Sie separat nachlesen.

Regeln für .gitignore

In der Datei .gitignore werden Muster für Datei- und Ordnernamen angegeben, die Git ignorieren soll.

Leere Zeilen werden ignoriert. Um einen Kommentar hinzuzufügen, beginnen Sie die Zeile mit dem Zeichen #.

Muster:

• * — ersetzt eine beliebige Anzahl beliebiger Zeichen. Beispiel: *.log ignoriert alle Dateien mit der Endung .log.
• / — am Ende des Musters bedeutet ein Verzeichnis. Beispiel: logs/ ignoriert den gesamten Inhalt des Ordners logs.
• ! — am Zeilenanfang kehrt eine Regel um. Beispiel: Wenn Sie die Regel *.log haben, aber important.log verfolgen möchten, fügen Sie die Zeile !important.log hinzu.
• ** — entspricht einer beliebigen Anzahl verschachtelter Ordner. Beispiel: **/temp ignoriert Ordner temp auf jeder Verschachtelungsebene.

Beispiel für eine .gitignore-Datei

# Kompilierter Code
/bin/
/obj/

# Temporäre Dateien
*.tmp
*.swp

# Logs
*.log

# Von der IDE erzeugte Ordner
.idea/
*.user
*.suo

# Virtuelle Umgebungen und Abhängigkeiten
/venv/
/node_modules/

Fertige Vorlagen

Sie müssen diese Dateien nicht von Grund auf schreiben. Es gibt fertige, von der Community erprobte Vorlagen:

1. Die .gitignore-Sammlung von GitHub für verschiedene Sprachen und Frameworks: https://github.com/github/gitignore.
2. gitignore.io — ein praktischer Webdienst, der eine Datei .gitignore für Ihre Technologien generiert.