Täglicher Entwicklerzyklus: Commit, Push und .gitignore

1. Loslegen: Projekt klonen

Fangen wir dort an, wo wir in der letzten Vorlesung aufgehört haben. Du hast ein Repository auf GitHub erstellt und jetzt musst du eine lokale Kopie auf deinem Rechner bekommen, um zu arbeiten. Dieser Vorgang heißt klonen.

Schritt 1. Starte deine IDE. Wenn ein Projekt geöffnet ist, schließe es über File -> Close Project. Im Startfenster wähle Clone Repository oder Get from VCS.

Schritt 2. Füge im sich öffnenden Fenster die URL deines Repositories ein. Diese Methode ist praktisch, wenn du jemandes Repository klonst. Die URL kannst du von der Seite des Repositories auf GitHub kopieren.

Wenn du dein eigenes Repository klonst (unser Fall), ist es am einfachsten, dich direkt aus der IDE bei GitHub anzumelden. Wähle dazu die Option Log in to GitHub. Deine IDE öffnet den Browser zur Authorisierung.

Auf der geöffneten Seite klickst du ruhig auf den grünen Button Authorize JetBrains. Danach kannst du deine Repositories direkt aus der Liste in der IDE auswählen. Wähle das gewünschte Projekt und klicke auf Clone.

Schritt 3. Deine IDE wird fragen, ob du diesem Projekt vertraust. Da es dein eigenes Repository ist, klicke auf Trust Project.

Schritt 4. Antivirus-Einstellungen (für Windows-Nutzer)

Der Windows-Antivirus kann melden, dass die IDE versucht, unbekannte Aktionen auszuführen. Da wir Programme erstellen und ausführen wollen, sollten wir der IDE erlauben, ohne Einschränkungen zu arbeiten. Klicke auf die Schaltfläche „Automatically“, damit die IDE die benötigten Ordner selbst zu den Ausnahmen hinzufügt.

2. Änderungen speichern: Commit

commit — das ist ein "Snapshot" oder der gespeicherte Zustand deines Projekts zu einem bestimmten Zeitpunkt. Denk daran wie an einen Speicherpunkt im Spiel: du kannst immer zurückkehren, falls etwas schiefgeht. Jeder Commit hat eine eindeutige ID und eine Nachricht, die die Änderungen beschreibt.

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

Die Commit-Historie. Jeder neue Commit baut auf dem vorherigen auf und erzeugt so eine Chronologie der Projektentwicklung.

Schritt 1. Nimm Änderungen vor.

Wenn du ein frisch erstelltes Repository geklont hast, enthält es wahrscheinlich nur eine Datei — README.md

Öffne die Datei README.md und füge eine Beschreibung deines Projekts hinzu. Sobald du anfängst, die Datei zu bearbeiten, markiert die IDE ihren Namen blau im Projektfenster. Das bedeutet, dass die Datei geändert wurde, die Änderungen aber noch nicht in Git gespeichert sind. Die IDE zeigt eine grüne Linie dort an, wo du Änderungen vorgenommen hast.

Schritt 2. Öffne das Commit-Fenster.

Links in der IDE gibt es das Tab Commit. Wenn du es öffnest, siehst du alle Änderungen, die zum Speichern bereit sind. Für den allerersten Commit braucht man in diesem Fenster besondere Aufmerksamkeit.

Schauen wir uns an, was wir sehen:

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

Vielleicht fragst du dich: Muss man all diese Hilfsdateien ins Repository aufnehmen?

Die gute Nachricht ist, dass wir beim Erstellen des Repositories auf GitHub eine Vorlage für .gitignore ausgewählt haben. Diese Datei enthält bereits Regeln, die Git sagen, welche Ordner oder Dateien ignoriert werden sollen. Mehr dazu besprechen wir am Ende der Vorlesung.

Für unseren ersten Commit ist die Aufgabe, alle wichtigen Projektdateien in die Historie aufzunehmen und eine Commit-Nachricht zu schreiben.

Schritt 3. Mach den Commit.

Klicke auf die Schaltfläche Commit. Fertig! Du hast einen Snapshot deines Projekts im lokalen Repository gespeichert. Die Datei bekommt wieder ihre normale Farbe.

3. Änderungen nach GitHub schicken: Push

Deine Commits liegen bisher nur auf deinem Rechner. Um sie mit dem Team zu teilen oder sicher zu speichern, musst du sie in das entfernte Repository auf GitHub senden.

        sequenceDiagram
        participant Lokales Repository (Dein Computer)
        participant Entferntes Repository (GitHub)

        note over Lokales Repository (Dein Computer): Du hast einen oder mehrere Commits gemacht.
Sie existieren nur hier.

        Lokales Repository (Dein Computer) ->> Entferntes Repository (GitHub): git push (Commits senden)

        note over Entferntes Repository (GitHub): Deine Commits sind kopiert
und sicher auf dem Server gespeichert.
    

Schritt 1. Klicke auf die Push-Schaltfläche.

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

Schritt 2. Prüfe und bestätige.

Es öffnet sich ein Fenster, in dem du alle Commits siehst, die zum Senden bereitstehen. Das ist deine letzte Chance, sicherzustellen, dass du genau das schickst, was du willst. Klicke auf Push.

Wenn alles erfolgreich war, siehst du Meldungen wie: Pushed commits to origin/main. Create pull request

Schritt 3. Prüfe das Ergebnis auf GitHub.

Nach erfolgreichem Push öffne die Seite deines Repositories auf GitHub. Du solltest dort deine Änderungen sehen.

4. Git-Steuerungspanel

In deiner IDE gibt es ein spezielles Menü Git, das du in der oberen Leiste findest. Das ist dein Kontrollzentrum für Versionsverwaltung. Lass uns kurz die wichtigsten Punkte anschauen.

• Commit: öffnet das bekannte Fenster zum Speichern von Änderungen.
• Push: öffnet das Fenster zum Senden deiner Commits nach GitHub.
• Update Project: eine sehr wichtige Funktion. Sie lädt frische Änderungen von anderen Teammitgliedern herunter (führt git pull aus). Nutze sie jeden Morgen vor Arbeitsbeginn!
• Branches: öffnet das Fenster zur Verwaltung von Branches. Dazu gehen wir in der nächsten Vorlesung detailliert ein.
• Show Git Log: zeigt die gesamte Commit-Historie deines Projekts. Deine persönliche Zeitmaschine.

5. Verwendung von .gitignore-Dateien

Wenn du Hilfsdateien ins Projekt eingefügt hast, die nicht versehentlich ins Repository gelangen sollen, kannst du sie in die Ausnahmen aufnehmen. Dafür gibt es die Datei .gitignore. Das ist praktisch, wenn dein Projekt Dateien enthält, die nicht in der Versionskontrolle gespeichert werden sollen (z. B. temporäre Dateien, Logs, Passwörter).

Schritt 1. Erstelle zunächst die Datei im Projektverzeichnis, die du ignorieren möchtest. Zum Beispiel notes.txt. Nach dem Erstellen der Datei klicke auf Cancel, falls die IDE anbietet, sie zu Git hinzuzufügen.

Schritt 2. Rechtsklicke auf die erstellte Datei im "Project"-Fenster. Gehe zu Git --> Add to .gitignore --> Add to .gitignore. Diese Option fügt die ausgewählte Datei zur Datei .gitignore im Projektstamm hinzu.

Wenn du noch keine Datei .gitignore hattest, wird die IDE vorschlagen, sie zu erstellen. Stimme dem zu.

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

Nachdem die Datei in .gitignore aufgenommen wurde, werden ignorierte Dateien grau oder braun angezeigt. Beim Versuch zu committen werden diese Dateien ignoriert. Den Ordner .idea kann man zum Ignorieren hinzufügen.

Vergiss nicht, die Datei .gitignore selbst zu committen und die Änderungen zu GitHub zu pushen, damit alle Beteiligten die gleichen Regeln für das Ignorieren von Dateien verwenden.

Lokale Ausnahmen: .git/info/exclude

Neben der Datei .gitignore, die für alle Projektmitglieder gilt, bietet Git die Möglichkeit, lokale Ignorier-Regeln in der Datei .git/info/exclude zu erstellen. Diese werden nicht ins Repository committed und gelten nur für deine lokale Kopie des Projekts.

Das ist nützlich, z. B. um IDE-erstellte Dateien zu ignorieren, die nicht in die Versionskontrolle gehören, aber nur für dich relevant sind.

Wichtig! Lokale Ignorier-Regeln gelten nur für deine lokale Kopie des Repositories.

Und was, wenn ich die Datei schon committed habe?

.gitignore ignoriert nur neue, noch nicht verfolgte Dateien. Wenn du eine Datei bereits committed hast, ist sie in der Historie und Git wird sie weiter verfolgen, auch wenn du sie zu .gitignore hinzufügst. Für solche Fälle gibt es einen Terminal-Befehl: git rm --cached <file>. Dazu solltest du aber separat lesen.

Regeln für .gitignore

In der Datei .gitignore stehen Muster für Dateinamen und Ordner, die Git ignorieren soll.

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

Muster:

• * — ersetzt beliebig viele beliebige Zeichen. Zum Beispiel ignoriert *.log alle Dateien mit der Endung .log.
• / — am Ende eines Musters bedeutet Verzeichnis. Zum Beispiel ignoriert logs/ den gesamten Inhalt des Ordners logs.
• ! — am Zeilenanfang invertiert die Regel. Wenn du z. B. *.log hast, aber important.log verfolgen willst, füge !important.log hinzu.
• ** — entspricht beliebig vielen verschachtelten Ordnern. Zum Beispiel ignoriert **/temp Ordner temp auf jeder Ebene.

Beispiel für eine .gitignore-Datei

# Kompilierter Code
/bin/
/obj/

# Temporäre Dateien
*.tmp
*.swp

# Logs
*.log

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

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

Fertige Vorlagen

Du musst diese Dateien nicht von Grund auf neu schreiben. Es gibt geprüfte, community-basierte Vorlagen:

1. Die Sammlung von .gitignore von GitHub für verschiedene Sprachen und Frameworks: https://github.com/github/gitignore.
2. gitignore.io — ein nützlicher Webdienst, der eine .gitignore nach deinen Technologien generiert.