Git-Grundlagen: Einführung in die Versionskontrolle und praktische Anwendung

1. Einführung und Motivation

Beim Programmieren oder bei der Arbeit an einem Projekt ist es entscheidend, Änderungen nachzuverfolgen und bei Bedarf zu einer früheren Version zurückzukehren. Genau dafür gibt es Git!

2. Was ist Git und warum nutzen wir es?

• Rückgängig machen: Eine Änderung war ein Fehler? Mit Git stellst du frühere Zustände einfach wieder her.
• Teamarbeit: Mehrere Personen können am selben Projekt arbeiten, ohne sich gegenseitig in die Quere zu kommen.
• Ausprobieren und Sicherheit: Du kannst ein neues Feature testen, ohne die Hauptcodebasis zu zerstören.

3. Git installieren und erste Einrichtung

• Git herunterladen und für dein Betriebssystem installieren.
• Prüfe die Installation anschließend mit git --version im Terminal.
• Lege deinen Benutzernamen und deine E-Mail-Adresse fest:

  Bash

  git config --global user.name "Adınız Soyadınız"
  git config --global user.email "[email protected]"

4. Grundbegriffe: Commit, Branch, Staging, HEAD, DAG

• Staging Area (Index): Der Bereich, in dem du deine Änderungen vorbereitest, bevor du sie committest.
• Commit: Eine Aufzeichnung des Projektzustands zu einem bestimmten Zeitpunkt.
• Branch: Ermöglicht dir, verschiedene Entwicklungslinien zu eröffnen. Der Hauptbranch heißt meist main oder master.
• HEAD: Zeigt auf den Branch, an dem du gerade arbeitest.
• DAG (Directed Acyclic Graph): Commits sind in einer gerichteten, zyklenfreien Graphstruktur miteinander verknüpft.

5. Grundlegende Git-Befehle: die ersten Schritte

Ein neues Git-Repository erstellen

git init

Verwandelt deinen aktuellen Ordner in ein Git-Projekt.

Änderungen verfolgen

git status

Zeigt geänderte Dateien in deinem Arbeitsverzeichnis und bereits gestagte Dateien an.

Dateien hinzufügen (Staging)

git add dosya.txt

Fügt eine bestimmte Datei hinzu. Für alle Dateien:

git add .

Änderungen speichern (Commit)

git commit -m "Açıklama yazın"

Hält deine Änderungen dauerhaft fest.

Historie ansehen

git log

Listet die komplette Commit-Historie auf.

6. Branches und Branching-Strategien

• Hauptbranch (main/master): Immer produktionsreifer, stabiler Code.
• Feature Branch: Wird für neue Features erstellt und nach Fertigstellung in den Hauptbranch gemergt.
• Hotfix-/Release-Branch: Für dringende Bugfixes oder die Release-Vorbereitung.

Beliebte Branching-Strategien

• Git Flow: Nutzt die Branches main, develop, feature, release und hotfix für komplexe Projekte.
• GitHub Flow: Ein einfacher Workflow rund um den main-Branch und kurzlebige Feature Branches.

7. Mit Remote-Repositories und GitHub arbeiten

• Remote-Repository (Remote): Eine Kopie, die auf Plattformen wie GitHub oder GitLab liegt.
• Ein Remote-Repository hinzufügen:

  Bash

  git remote add origin <repo-adresi>
  git push -u origin main

• Die neuesten Änderungen aus einem Remote-Repository holen:

  Bash

  git pull

• Ein bestehendes Projekt auf deinen Rechner klonen:

  Bash

  git clone <repo-adresi>

8. Weitere häufig genutzte Befehle

• git branch: Listet die vorhandenen Branches auf.
• git checkout -b yeni-ozellik: Erstellt einen neuen Branch und wechselt zu ihm.
• git merge <dal>: Merged den angegebenen Branch in den aktuellen Branch.

9. Merge vs. Rebase, Konflikte und Lösungen

Wie entsteht ein Merge-Konflikt? (Szenario und Beispiel)

Szenario: Zwei Personen ändern dieselbe Zeile einer Datei auf unterschiedliche Weise.

1. Auf dem main-Branch existiert eine Datei:

   txt

   mesaj.txt:
   Merhaba dünya!

2. Auf dem Branch feature-a wird diese Zeile geändert:

   txt

   mesaj.txt:
   Merhaba Copilot!

3. Auf dem Branch feature-b wird dieselbe Zeile anders geändert:

   txt

   mesaj.txt:
   Merhaba insan!

4. Zuerst wird feature-a in den main-Branch gemergt. Dann wird versucht, feature-b in main zu mergen. Da es zwei widersprüchliche Änderungen in derselben Zeile gibt, löst Git einen Merge-Konflikt aus.

Merge-/Rebase-Befehle und Konflikte lösen

Merge

git merge feature-branch

Führt zwei Branches zusammen. Die vollständige Commit-Historie bleibt erhalten.

Rebase

git rebase main

Verschiebt deinen Branch an die Spitze des main-Branches und sorgt so für eine sauberere, lineare Historie.

Merge-/Rebase-Konflikte

• Bei einem Konflikt erscheinen in der Datei die Markierungen <<<<<<<, ======= und >>>>>>>.
• Löse die betroffenen Zeilen manuell und führe dann aus:

  Bash

  git add <dosya>
  git commit

• Einen Commit kannst du erst abschließen, wenn die Konflikte gelöst sind.

10. Häufige Fehler und wie du sie behebst (im Detail)

1. Auf dem falschen Branch committet

Szenario: Du dachtest, du arbeitest auf einem Feature Branch, hast aber direkt auf main committet (oder umgekehrt).

Lösung:

1. Den Hash des Commits finden:

   Bash

   git log --oneline

2. Zum Ziel-Branch wechseln:

   Bash

   git checkout main

3. Den Commit auf den main-Branch anwenden:

   Bash

   git cherry-pick <commit-hash>

4. Den Commit vom falschen Branch entfernen:

   Bash

   git checkout feature
   git reset --hard HEAD~1

2. Versehentlich einen Commit gelöscht

Szenario: Bei einem git reset --hard oder einem Rebase ist ein Commit verloren gegangen.

Lösung:

1. Den Commit-Hash finden:

   Bash

   git reflog

2. Den verlorenen Commit in einem neuen Branch wiederherstellen:

   Bash

   git checkout -b kurtarma <commit-hash>

3. Fehlender Commit nach Merge oder Rebase

Szenario: Nach einem Merge oder Rebase sind einige Commits verschwunden.

Lösung:

1. Finde den Commit-Hash mit git reflog.
2. Stelle den Commit wieder her, indem du einen neuen Branch erstellst:

   Bash

   git branch kayip-commit <commit-hash>

3. Bei Bedarf kannst du ihn anschließend in deinen Ziel-Branch mergen oder per Cherry-pick übernehmen.

4. Versehentlich eine Datei gelöscht

Szenario: Du hast eine Datei gelöscht und willst sie vor dem Commit wiederherstellen.

Lösung:

• Um sie auf den Stand des letzten Commits zurückzusetzen:

  Bash

  git checkout HEAD -- dosya.txt

• Um sie aus einem älteren Commit wiederherzustellen:

  Bash

  git checkout <commit-hash> -- dosya.txt

5. Merge-Konflikt lässt sich nicht lösen

Szenario: Du hast versehentlich Konfliktmarkierungen (<<<<<<<, =======, >>>>>>>) gelöscht und die Datei beschädigt.

Lösung:

• Um die Datei zurückzusetzen und den Konflikt von vorn zu lösen:

  Bash

  git checkout --ours dosya.txt   # Keeps your changes
  git checkout --theirs dosya.txt # Keeps incoming changes

• Danach kannst du den Merge-Vorgang erneut durchführen.

Häufige Fehler und Wiederherstellung (Übersichtstabelle)

11. Praxisszenarien und Zusammenarbeit im Team

• Fork und PR: Das Projekt eines anderen forken und deine Änderungen als Pull Request einreichen.
• Upstream-Sync: Aktualisierungen aus dem Original-Repository holen, um deinen Fork aktuell zu halten.
• Code Review: Codeänderungen vor dem Merge über PRs prüfen.

12. Fortgeschrittene Themen

Squash

Szenario: Du hast auf einem Feature Branch 5 kleine Commits gemacht, willst sie aber als einen einzigen Commit in den Hauptbranch mergen.

Ausführliches Beispiel:

1. Der Branch feature/login enthält die folgenden Commits:
   • feat: kullanıcı adı inputu eklendi
   • fix: input typo düzeltildi
   • feat: şifre inputu eklendi
   • fix: şifre inputu typo düzeltildi
   • style: inputlara margin eklendi
2. Vor dem Merge in main willst du sie zu einem Commit zusammenfassen:

   Bash

   git checkout feature/login
   git rebase -i HEAD~5

3. Setze im interaktiven Editor den ersten Commit auf pick und alle übrigen auf squash. Bearbeite die Commit-Nachricht und speichere.
4. Ergebnis: Alle Änderungen sind in einem einzigen Commit zusammengefasst. Jetzt kannst du in main mergen.

Cherry-pick

Szenario: Du willst einen bestimmten Commit aus einem anderen Branch herauspicken und auf deinen aktuellen Branch anwenden.

Ausführliches Beispiel:

1. Auf hotfix/bugfix wurde ein dringender Fix committet:
   • fix: login bug düzeltildi (Commit-Hash: a1b2c3d)
2. Du arbeitest auf feature/profile und willst diesen Fix übernehmen:

   Bash

   git checkout feature/profile
   git cherry-pick a1b2c3d

3. Ergebnis: Nur dieser eine Commit wird auf deinen aktuellen Branch angewendet. Dein Code ist aktualisiert.

Revert

Szenario: Du hast auf dem main-Branch einen fehlerhaften Commit erstellt, willst aber die Historie nicht umschreiben.

Ausführliches Beispiel:

1. Auf main wurde versehentlich eine Datei gelöscht:
   • commit hash: d4e5f6g
2. Um diesen Commit rückgängig zu machen:

   Bash

   git checkout main
   git revert d4e5f6g

3. Ergebnis: Die gelöschte Datei ist wiederhergestellt, und ein neuer Revert-Commit wird erstellt.

Reset

Szenario: Du hast 3 unnötige Commits gemacht und willst sie komplett entfernen.

Ausführliches Beispiel:

1. Letzte Commits:
   • fix: typo
   • test: test kodu
   • debug: console.log eklendi
2. Um die letzten 3 Commits zu löschen:

   Bash

   git reset --hard HEAD~3

3. Ergebnis: Das Repository springt auf den Stand von vor 3 Commits zurück. Diese Commits und Änderungen werden vollständig verworfen.

Reflog

Szenario: Du hast versehentlich einen Branch oder Commit gelöscht und willst ihn wiederherstellen.

Ausführliches Beispiel:

1. Nach einem git reset --hard ist ein Commit verschwunden.
2. So findest du den fehlenden Commit:

   Bash

   git reflog
   # Find the old commit hash in the output (e.g. 9z8y7x6)
   git checkout -b kurtarma 9z8y7x6

3. Ergebnis: Der verlorene Commit ist in einem neuen Branch wiederhergestellt.

Stash

Szenario: Du musst mitten in der Arbeit dringend den Branch wechseln, willst aber unfertige Arbeit nicht committen.

Ausführliches Beispiel:

1. Du bist auf feature/search und hast uncommittete Änderungen.
2. Du musst zum main-Branch wechseln:

   Bash

   git stash
   git checkout main
   # Once done, switch back to your feature branch
   git checkout feature/search
   git stash pop

3. Ergebnis: Deine Änderungen werden sicher wiederhergestellt, ohne dass Arbeit verloren geht.

.gitignore und .gitattributes

Szenario: Dein Projekt enthält Dateien, die nicht verfolgt werden sollen, etwa Build-Ausgaben oder geheime Schlüssel.

Ausführliches Beispiel:

1. Du hast Ordner/Dateien wie node_modules/, .env oder dist/.
2. Trage sie in deine .gitignore-Datei ein:

   txt

   node_modules/
   .env
   dist/

3. Ergebnis: Git ignoriert diese Dateien.
4. Nutze .gitattributes für Zeilenende-Konfigurationen, zum Beispiel:

   txt

   * text=auto

Hooks

Szenario: Du willst vor jedem Commit automatisierte Tests ausführen.

Ausführliches Beispiel:

1. Öffne oder erstelle .git/hooks/pre-commit.
2. Füge das folgende Skript ein:

   Bash

   #!/bin/sh
   npm test

3. Mach die Datei ausführbar:

   Bash

   chmod +x .git/hooks/pre-commit

4. Ergebnis: Vor jedem Commit laufen die automatisierten Tests; schlagen sie fehl, wird der Commit abgebrochen.

Submodules

Szenario: Du willst ein anderes Git-Repository (z. B. eine gemeinsame Bibliothek) als Submodule in dein Projekt einbinden.

Ausführliches Beispiel:

1. So fügst du eine gemeinsame Bibliothek hinzu:

   Bash

   git submodule add https://github.com/ornek/ortak-kutuphane.git libs/ortak-kutuphane

2. So aktualisierst du das Submodule:

   Bash

   git submodule update --remote

3. Ergebnis: Das Submodule ist in dein Projekt eingebettet und bleibt aktuell.

Shallow Clone & LFS

Szenario 1: Ein Repository ist sehr groß, und du willst nur schnell den neuesten Snapshot herunterladen.

Ausführliches Beispiel:

1. So klonst du nur den neuesten Commit:

   Bash

   git clone --depth=1 https://github.com/ornek/buyuk-repo.git

2. Ergebnis: Es wird nur die neueste Revision heruntergeladen statt der gesamten Historie.

Szenario 2: Dein Repository enthält große Dateien (z. B. Videos, Datensätze), die Git ausbremsen.

Ausführliches Beispiel:

1. Git LFS einrichten:

   Bash

   git lfs install
   git lfs track "*.mp4"
   git add .gitattributes
   git add video.mp4
   git commit -m "LFS ile video eklendi"

2. Ergebnis: Große Dateien werden von LFS verwaltet, und dein Haupt-Repository bleibt schnell.

13. FAQ und Ressourcen

Häufig gestellte Fragen

Ressourcen und weiterführende Literatur

• Pro Git Book
• Atlassian Git Tutorials
• Oh Shit, Git!?!
• GitHub Learning Lab
• Git Branching