GUIDE Grundlagen Git

Letztes Update: 04. Februar 2026

Überblick

Dieses Dokument dient als Einstieg für Git-Anfänger im Projekt HisQu.
Es erklärt Schritt für Schritt alle grundlegenden Arbeitsabläufe und Best Practices für den Umgang mit Git und GitHub im Projektkontext.

Der Guide behandelt folgende Themen:

1. Repositorium in GitHub erstellen & lokal einrichten
2. Editable Installs & pyproject.toml
3. Neue Features oder Bugfixes entwickeln
4. Merge Requests, Pull Requests, Issues & Commit Messages
5. Branching-Strategie
6. Contribution Guide (Contributing.md)
7. Eine .gitignore Datei benutzen
8. Repositorium-Vorlagen
9. Fehlerbehebung (Troubleshooting)
10. HisQu-spezifische Git-Themen (separater Guide)

Wenn Sie bereits mit Git vertraut sind, empfiehlt es sich, direkt mit der Branching-Strategie zu beginnen.

---

Maximen für alle mit git unerfahrenen Entwickler

• Halten Sie Ihr Repositorium sauber. Dazu gehört eine gute Projektstruktur, aber auch das Überdenken, welche Dateien und Ordner auf das Repositorium committet werden. Kompilierte Dateien etwa, werden nicht mit hochgeladen.
• Verwenden Sie sogenannte sprechende Commit-Struktur (siehe Abschnitt 4), damit einerseits die Repositoriumsgeschichte nachvollziehbarer ist, andererseits etwa Ihr Commit als Nachricht zu einem dazugehörigen Issue referenziert wird.
• Jedes Projekt braucht eine README.md, die das Aufsetzen und die Nutzung durch den Benutzer instruiert.
• Niemals API-Schlüssel oder Passwörter committen → Hierzu .env verwenden!
• Committe oft, aber logisch: kleine, abgeschlossene Änderungen sind besser nachvollziehbar.

---

1. Repositorium in GitHub erstellen & auf dem lokalen Gerät einrichten

1.1 Neues Repositorium erstellen

Ziel ist es hier, online auf der Plattform Github ein Repositorium, also sozusagen ein neues Projekt zu erstellen. Nach der Anleitung 1.1 ist das Repositorium nun online gespeichert.

Öffnen Sie die GitHub-Neues-Repositorium-Webseite, um ein neues Repositorium zu erstellen. Achtung: Damit die zu HisQu gehörigen Repositorien möglichst einheitlich und standardisiert sind, sollten beim Erstellen das offizielle HisQu-Template-Repository als Vorlage benutzt werden.

Schaue dir für eine Schritt-für-Schritt-Anleitung dazu diesen Videoausschnitt an.

1.2 Repositorium klonen

Damit auf ihrem lokalen Gerät an dem Repositorium weiterentwickelt werden kann, müssen Sie sich zuerst eine Kopie auf ihren Rechner speichern.

Variante: ohne git-Befehle Öffnen Sie das Repositorium und klicken Sie auf Code. Wenn Sie sich nur einmalig den Code ziehen möchten, können sich den Code als .zip herunterladen. Wenn Sie allerdings an dem Projekt partizipieren möchten, Code nicht nur ausführen, sondern auch Änderungen teilen möchten, sollten Sie sich Git auf ihrem PC installieren.

Variante: mit git-Befehle

Installieren Sie, falls nicht schon geschehen, Git auf ihrem lokalen Gerät. Öffnen Sie dazu das Terminal und führen Folgendes aus auf ...

... Windows:

winget install --id Git.Git -e --source winget

...Linux (Ubuntu):[^1]

sudo apt update
sudo apt install git -y

...MacOS:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install git

Sobald Sie Git auf ihrem Rechner installiert haben, führen Sie Folgendes in dem Terminal aus (wobei Sie repository-url durch die URL des zu klonenden Repositoriums ersetzen und projektverzeichnis durch den Namen des für das geklonte Repositorium erzeugten Ordners):

Für alle Betriebssysteme:

git clone <repository-url>
cd <projektverzeichnis>

Kopiert das Projekt auf deinen lokalen Rechner und wechselt in den Projektordner.

---

2. Editable Installs & pyproject.toml

Im HisQu-Umfeld nutzen wir keine Submodules mehr, sondern editable installs (PEP 660). Damit bleiben Abhängigkeiten im lokalen Workspace editierbar, und Änderungen wirken sofort.

2.1 Kurz erklärt

• Die zentrale Datei ist pyproject.toml (Abhängigkeiten, Metadaten, Build-Setup).
• Für die Entwicklung installierst du das Projekt im Editable-Mode.

pip install -e .
# mit dev-Abhängigkeiten:
pip install -e ".[dev]"

So bleibt der Code direkt bearbeitbar, ohne nach jeder Änderung neu zu installieren.

Referenzen:

• TEMPLATE-Reposiries
• GUIDE-Best-Coding-Practices – siehe PEP 660

---

3. Neues Feature oder Bugfix entwickeln

Features und Bugfixes ermöglichen es, neue Funktionen zu entwickeln oder bestehende Fehler gezielt zu beheben, ohne den Hauptcode zu beeinträchtigen. Durch eigene Branches bleiben Änderungen klar getrennt, nachvollziehbar und können kontrolliert in den Hauptzweig integriert werden.

3.1 Feature-Branch erstellen

Ein Feature ist eine neue Funktion oder Erweiterung im Code. Dafür legst du einen eigenen Branch an, z. B. feature/login-system.

git checkout main     # oder dev
git pull origin main  # oder dev
git checkout -b feature/<feature-name>

Erstellt einen neuen Branch für dein Feature, basierend auf dem aktuellen Entwicklungsstand. Warum main oder dev? Siehe Branching-Strategie.

3.2 Änderungen committen & pushen

Haben Sie eine Lösung gefunden, die das Projekt voran bringt, sollten Sie diese neue Version in das Repositorium "hochladen".

git add .
git commit -m "feat: <beschreibung>"
git push -u origin feature/<feature-name>

git add . staged alle Änderungen – außer Dateien aus der .gitignore (siehe Abschnitt 7). commit speichert sie lokal, push lädt sie auf GitHub hoch.

3.3 Bugfix-Branch erstellen

Ein Bugfix dient dazu, bestehende Fehler oder unerwartetes Verhalten im Code zu beheben, ohne neue Funktionen hinzuzufügen. Dafür wird ein eigener Branch erstellt, z. B. bugfix/fix-login-error.

git checkout main     # oder dev
git pull origin main  # oder dev
git checkout -b bugfix/<bug-name>

Erstellt einen neuen Branch zur gezielten Fehlerbehebung auf Basis des aktuellen Entwicklungsstands. Warum main oder dev? Siehe Branching-Strategie.

Nachdem der Fehler behoben wurde, können die Änderungen wie gewohnt committet und gepusht werden:

git add .
git commit -m "fix: <kurze Fehlerbeschreibung>"
git push -u origin bugfix/<bug-name>

git add . staged alle Änderungen – außer Dateien aus der .gitignore (siehe Abschnitt 7). So bleibt jede Korrektur sauber dokumentiert und kann über einen Pull Request in den Hauptzweig integriert werden.

---

4. Merge Requests (Pull Requests), Issues & Commit Messages

4.1 Merge Request

Ein Merge Request dient dazu, Änderungen aus einem Branch kontrolliert in den Hauptzweig zu integrieren. Dadurch können andere Teammitglieder den Code prüfen, Feedback geben und Konflikte vermeiden.

# Branch pushen
git push -u origin feature/<feature-name>

Lädt deinen Branch auf GitHub hoch, sodass daraus ein Merge Request erstellt werden kann. Auf der GitHub-Webseite wird daraus automatisch in dem Repositorium ein Pull-Request vorgeschlagen.

4.2 Pull Request

Vorgehen auf der GitHub-Webseite:

1. Branch pushen
2. GitHub → Compare & pull request
3. Beschreibung hinzufügen
4. Reviewer auswählen, Review abwarten und bei konstruktivem Review den Code anpassen. Dann starte wieder beim Branch-Push.

Ein Pull Request ermöglicht sauberes Team-Review und hält den Code stabil.

4.3 Issues

Ein Issue dient als zentrale Stelle, um Aufgaben, Fehler, Ideen oder Verbesserungsvorschläge festzuhalten. Es hilft dabei, den Entwicklungsprozess übersichtlich zu gestalten und Diskussionen zu einzelnen Themen zu bündeln. Entwickler können Issues nutzen, um Probleme zu melden, neue Features vorzuschlagen oder Fortschritte zu dokumentieren.

Vorgehen:

1. GitHub → Issues → New Issue
2. Problem oder Feature klar beschreiben
3. Screenshots oder Beispiele hinzufügen

Optional kannst du beim Commit oder Pull Request auf ein Issue verweisen:

git commit -m "fix: corrected login bug (Closes #12)"

Damit wird das Issue automatisch geschlossen, sobald der Pull Request gemergt wird.

Alternativ können Sie ein Issue referenzieren, um eine Verbindung zwischen deinem Commit oder Pull Request und einem bestehenden Issue herzustellen:

related to #13241

Damit wird das entsprechende Issue automatisch verlinkt und eine Nachricht im Issue selbst hinterlassen. So sehen alle Beteiligten sofort, dass dein Commit oder Pull Request im Zusammenhang mit diesem Issue steht, ohne es dabei zu schließen. Das sorgt für bessere Nachvollziehbarkeit und hält den Projektkontext transparent.

Commit Messages

Commit Messages dokumentieren welche Änderung vorgenommen wurde und warum. Sie sollten kurz, prägnant und im Imperativ formuliert sein.

  git commit -m "feat: add user login feature"

Beispiel:

  feat: add support for user login
  Closes #17

„feat“ signalisiert ein neues Feature, „fix“ eine Fehlerbehebung usw.

---

5. Branching-Strategie

5.1 Branching-Typen

Branches lassen sich gut wie die Äste eines Baumes vorstellen: Der Hauptzweig (main) bildet den stabilen Stamm, von dem sich kleinere Entwicklungsäste (dev, feature/..., fix/...) abzweigen. Jeder Branch steht für einen bestimmten Zweck. Diese Struktur hilft dabei, Änderungen sauber zu trennen, parallel zu entwickeln und jederzeit einen stabilen Hauptcode beizubehalten.

Branch-Typ	Zweck	Basis	Beispiel
main	Stabiler Release-Branch	—	—
dev	Aktueller Entwicklungsstand	main	dev
feature/...	Neue Funktionen	dev	feature/data-import
fix/...	Fehlerbehebungen	dev/main	fix/auth-error

Wenn Sie mit einer neuen Funktion oder einer Fehlerbehebung beginnen, erstellen Sie dafür einen eigenen Branch mit einem passenden Namen. So bleiben Ihre Änderungen klar vom restlichen Entwicklungsstand getrennt.

Einen neuen Branch legen Sie mit folgendem Befehl an (Die Flag -c gibt an, dass ein neuer Branch erstellt wird):

git switch -c feature/name-der-funktion

bzw. für Fehlerbehebungen:

git switch -c fix/kurze-fehlerbeschreibung

Der neue Branch basiert immer auf dem Branch, auf dem Sie sich aktuell befinden (in der Regel auf dev). Stellen Sie daher sicher, dass Sie sich zuvor auf dem richtigen Ausgangs-Branch befinden.

5.2 Branch-Verhalten

Workflow: feature → Pull Request → dev → Merge → (Tests) → Merge nach main für Release.

Wenn Sie an einem neuen Feature oder Bugfix arbeiten, beginnen Sie in einem eigenen Branch, wie etwa feature/... oder fix/.... Dort können Sie Änderungen entwickeln und testen, ohne den aktuellen Entwicklungsstand anderer zu beeinflussen. Sobald Ihre Arbeit abgeschlossen und erfolgreich getestet ist, erstellen Sie einen Pull Request in den dev-Branch. In diesem Branch werden alle laufenden Entwicklungen zusammengeführt und überprüft. Nach erfolgreichem Review und bestandenen Tests wird Ihr Code in dev gemergt. Wenn der Entwicklungsstand stabil und freigegeben ist, erfolgt anschließend der Merge von dev nach main – dieser Branch stellt den offiziellen Release-Stand dar.

Wie sollten die Branches nicht aussehen? (Anti-Patterns)

• Zu große / langlebige Feature-Branches (3000 Zeilen), die keiner überblickt und unmöglich zu mergen sind.
• Branches nicht aufgeräumt: feature/foo_old, feature/foo2, foo2-rebase, foo2-final-final.
• Keine konsistenten Regeln: Wann branchen? Wann mergen? Wann rebase?

Wie sollten die Branches stattedessen aussehen? (Best Practices)

1. Immer von main (oder dev) aus branchen.
2. Kurze Branches: max. 1-3 Tage
   • Zu große merges (3000 Zeilen) sind unmöglich zu mergen.
   • Merge (unvollständige) features die dev nicht brechen:

     branch 1 (1–2 days): add API endpoint skeleton
     branch 2 (1 day): wire UI to mocked data
     branch 3 (1–2 days): hook up real data + validation

3. Schütze dev und main:
   • Nur über Pull Requests mergen.
   • Mindestens 1 Reviewer erforderlich.
   • Automatisierte Tests (CI) müssen bestehen.
4. Das Vernwenden von Feature Toogles.

Feature Toogles / Flags: Die hier angegebenen Informationen folgenden martinfowler.com. Für eine ausführliche Einführung in das Thema, oder eine Kategorisierung der Toogles checken Sie gerne den Artikel aus. Nachfolgend werden die Kerngedanken angeführt:

Feature Toogles (oder auch Feature Flags) sind eine Programmiertechnik, die es ermöglicht Code höchstdynamisch zur Laufzeit entscheiden zulassen, welche Version vom Programm selbst genutzt werden soll.

Das Grundprinzip lässt sich anhand des folgenden hard coded Programms erklären: Für jede Version des Code würde in einem eigen Branch der Code folgendermaßen aussehen.

function reticulateSplines(){
    // current implementation lives here
  }

Es wäre also jedes Teammitglied von dem Fortschritt des anderen abhängig. Anderwaltig könnten Merge-Konflikt folgen. Hierzu bestimmt nun die Variable useNewAlgorithm, ob der modifizierte Code bereits verwendet werden soll. So können etwa Änderungen an dem neuem Algorithmus vorgenommen werden, ohne das es den Durchlauf des Programmes beeinflusst:

  function reticulateSplines(){
    var useNewAlgorithm = false;
    // useNewAlgorithm = true; // UNCOMMENT IF YOU ARE WORKING ON THE NEW SR ALGORITHM
  
    if( useNewAlgorithm ){
      return enhancedSplineReticulation();
    }else{
      return oldFashionedSplineReticulation();
    }
  }
  
  function oldFashionedSplineReticulation(){
    // current implementation lives here
  }
  
  function enhancedSplineReticulation(){
    // TODO: implement better SR algorithm
  }

Hard coded ist die Technik eingeschränkt mächtig. Sinnvoll ist es daher, die Technik etwa über Parametrisierung zu dynamisieren.

// Examapel für ein parametrisiertes Feature-Ausrollen
function example(isEnabled){
 isEnabled ? oldImplementation() : newImplementation();
}
function oldImplementation(){ ... }
function newImplementation(){ ... }

Mit Parametern sind also nun mehrere Versionen ausrollbar. Schlanker und Eleganter hingegen ist es, beim Aufruf des Programmes Flags zu setzen und diese bei dem Programmdurchlauf auszulesen und auszuwerten:

//Annahme: example.js soll mit Node.js ausgeführt werden: node example.js --old
//dann wird hier geprüft, ob die Flag gesetzt wurde (wenn alt, dann true, sonst false)
const isEnabeld = process.argv.includes('--old');
function run(){
  if (isEnabeld) {
    oldImplementation();
  } else {
    newImplementation();
  }
}
run();

Weitere Möglichkeiten, die Programmentscheidung zur Laufzeit umzuschalten, könnten sein:

• eine Datendatei (z.B.: .dat-, .ini-, ... Dateien)
• über eine existierende Datenbank die Versionierung zu steuern
• in einem Cluster Knotenpunkte für den Datenfluss Entscheidungen treffen lassen
• Überschreiben von Konfigurationen (z.B.: auf wenn auf mehreren Layern gearbeitet wird)

---

6. Contribution Guide

Code of Conduct

Der Contribution Guide (Contributing.md) beschreibt, wie Sie aktiv zum Projekt beitragen können (durch neue Features, Bugfixes oder Verbesserungen). Er dient als Orientierung, um eine einheitliche Arbeitsweise sicherzustellen und die Zusammenarbeit im Team effizient zu gestalten. Durch klar definierte Schritte und Standards wird gewährleistet, dass alle Beiträge nachvollziehbar, testbar und konsistent mit dem bestehenden Code umgesetzt werden.

6.1 Wie beitragen

• Bugs: Issue mit reproduzierbaren Schritten erstellen.
• Features: Vorab im Issue diskutieren.
• Pull Requests:
  • Fork erstellen
  • Branch anlegen
  • Standards einhalten (Coding Practices)
  • PR mit sinnvoller Beschreibung einreichen

6.2 Entwicklungsumgebung

1. Virtuelle Umgebung (.venv)
2. Dependencies installieren
3. .env einrichten

6.3 Commit-Konventionen

feat: add new API endpoint
fix: correct bug in auth middleware
docs: update README
test: add unit tests for parser

---

7. .gitignore benutzen

Die Datei .gitignore legt fest, welche Dateien Git nicht versionieren soll. Sie verhindert, dass unnötige oder sensible Daten in das Repository gelangen, etwa kompilierte Dateien, temporäre Logs oder private Konfigurationsdaten. Gerade bei sensiblen Informationen wie API-Schlüsseln oder Zugangsdaten in einer .env-Datei ist Vorsicht geboten: Werden solche Dateien versehentlich hochgeladen, können sie über Commit-Hashes oder den Git-Verlauf rekonstruiert und missbräuchlich verwendet werden. Ebenso schützen Sie Ihr Repository davor, mit großen oder automatisch generierten Dateien (z. B. aus Build- oder Cache-Verzeichnissen) „zugemüllt“ zu werden, die keinen Mehrwert für die Versionskontrolle haben.

Für weiterführende Informationen prüfen Sie die offizielle Dokumentation.

Syntax:

Ausdruck	Bedeutung
*	alles in dem Ordner wird ignoriert
*.class	Alle .class-Dateien in dem Ordner werden ignoriert. Selbes Prinzip gilt fül alle möglichen Dateiendungen
ordnername/	Der gesamte Order ordnername wird ignoriert
ordnername/*	Alle Dateien im Ordner ordnername werden irgnoriert
~$*	Beispel für temporäre Dateitypen: Word etwa erzeugt temporäre Dateien der Form ~$[Dateiname].docx. Der Ausdruck verhindert also in einem etwaigem Repo, dass temporäre Word Dateien committed werden. Selbiges ist sinnvoll für weitere temporäre OS-Dateien, oder kompilierte Dateiformate

WICHTIG: Git wendet das Ignorieren auch rekursiv auf Unterordner an.

Beispiel:

.env
__pycache__/
.vscode/
dist/
build/
*.log

Flut an unnötigen Dateien: Bedenken Sie, dass nicht nur Sie als Benutzer des Gerätes Dateien anlegen. Auch das Betriebssystem (OS), oder die von ihnen benutztne Programme (egal ob Word, oder ihre IDE) legen automatisiert Dateien an. Je nach Komplexität fallen dabei pro Betriebssystem, oder benutzter Software eine Vielzahl an verschiedenen Dateien an. Wenn Sie dabei im Laufe des Prozesses die .gitignore erweitern, kann es passieren, dass Sie dabei erstellte Software vergessen einzutragen. Nutzen Sie daher von Repo-Erstellung an das Template-Repositorium. Darin enthalten sind die gängigsten OS-abhängigen versteckten Dateiformate, IDE-spezifische Konfigurationsordner, sowie die gängigsten Temporär- und Postkompilationsdateiformate.

Beste Praxis:

• .gitignore immer gleich beim Start des Projekts anlegen.
• Vor jedem Commit prüfen: git status zeigt dir, was ignoriert oder getrackt wird.
• Bei Änderungen: .gitignore aktualisieren und committen.

Nutzen Sie das Template-Repositorium. Darin enthalten ist automatisch die .gitignore. Wenn Sie manuell die Datei manuell nutzen möchten, dann klicken Sie hier.

Trick:

Gerade wenn Sie zu Beginn eines neuen Repositoriums unentschlossen sind, welche Dateien bei einem commit veröffentlicht werden sollen, empflicht es sich, erst einmal alle Dateien in dem Projektroot, oder einem Unterordner (z.B. einem Ordner mit Daten, oder kompilierten Dateien) zu ignorieren. Legen Sie dazu eine Datei .gitignore in dem Projekt-root-Verzeichnis, oder dem gewünschten Unterordner an und fügen folgenden Inhalt ein:

*

---

8. Template Repositories

Ein Template Repository dient als vorgefertigte Projektvorlage, die eine konsistente Struktur und bewährte Standards für neue Repositories bereitstellt. Dadurch sparen Sie Zeit beim Setup, vermeiden wiederkehrende Fehler und stellen sicher, dass alle Projekte auf derselben technischen Basis aufbauen. Templates enthalten häufig bereits eine sinnvolle Ordnerstruktur, eine passende .gitignore, vorkonfigurierte Linter- und CI-Workflows sowie Vorlagen für Dateien wie README, LICENSE oder .env. So müssen Sie nicht bei jedem neuen Projekt bei null beginnen, sondern können direkt mit der eigentlichen Entwicklung starten – einheitlich, effizient und fehlerresistent.

8.1 Verwendung

1. Template auswählen → „Use this template“
2. Neues Repository erstellen
3. Projekt anpassen (README, .env, Pipelines)

8.2 Best Practices

• Immer das offizielle HisQu-Template verwenden.
• Nach Erstellung prüfen:
  • .gitignore enthält projektspezifische Regeln
  • LICENSE, README, CONTRIBUTING angepasst
  • GitHub Actions richtig konfiguriert

---

---

9. Fehlerbehebung (Troubleshooting)

Warum überhaupt zurücksetzen?

Manchmal verschlimmbessert man etwas: ein fehlerhafter Merge, ein missglücktes Refactoring, versehentlich eingecheckte Dateien/Secrets oder ein Experiment, das den Build zerlegt. In solchen Fällen hilft es, den Branch auf einen bekannten guten Zustand zurückzusetzen oder einzelne frühere Commits gezielt wiederherzustellen. Ziel: schnell wieder arbeits- und releasefähig werden – ohne langfristig Chaos zu hinterlassen.

Die drei Operationen:

• git reset schreibt die lokale Historie um (gefährlich bei geteilten Branches).
• git revert erstellt einen neuen Commit, der Änderungen rückgängig macht (historienfreundlich).
• git reflog zeigt dir, wo HEAD zuletzt war.

Wann sollte man was nutzen?

• Kleiner Fehler im geteilten Branch (main/dev) → git revert
• Lokaler Feature-Branch verschlimmbessert und noch nicht geteilt → git reset --hard <good-hash>
• Remote ist korrekt, lokale Kopie kaputt → git reset --hard origin/<branch>
• Nur einzelne Dateien defekt → git restore --source=<hash> -- <file>
• Panik → git reflog ansehen

9.1 Branch auf Remote-Zustand zurücksetzen

Hierbei wird der Fortschritt im Branch verworfen und auf den Remotestand zurückgesetzt.

git fetch origin
git reset --hard origin/<branch>

*Setzt den lokalen <branch> exakt auf den Zustand von origin/<branch> zurück. Damit

9.2 Vorherigen Commit ansehen

Oft findet sich noch die git checkout <commit-hash> Operation. Empfehlenswert ist allerdings, git switch zu verwenden.

# auf einen Arbeitsstand mittels Hash-Wert zu wechseln:
git switch --detach <commit-hash>

# zurück zu einem Branch:
git switch <branch>

In der offiziellen Dokumentation finden sich weiterführende Informationen.

9.3 Branch hart auf alten Commit zurücksetzen

1. Backup-Branch anlegen

git branch backup/<branch>-pre-reset

2. Hard Reset durchführen:

git reset --hard <commit-hash>
git push --force origin <branch>   # nur nach Absprache in Team-Branches!

Setzt den Branch auf <commit-hash> zurück. Mit --force überschreibst du den Remote-Verlauf. Dies sollte mit dem Team zuvor abgesprochen werden.

9.4 Änderungen rückgängig machen, ohne Historie umzuschreiben

git revert <commit-hash>
# mehrere:
git revert <hash1> <hash2> <hash3>

Erzeugt einen neuen Commit, der die Änderungen rückgängig macht. Sicher für main/dev.

9.5 Einzelne Dateien aus früherem Commit wiederherstellen

# Datei wie in <commit-hash> wiederherstellen:
git checkout <commit-hash> -- path/to/file

# alternativ:
git restore --source=<commit-hash> -- path/to/file

git commit -m "revert(file): restore path/to/file from <commit-hash>"

Praktisch, wenn nur 1–2 Dateien „kaputt“ sind, nicht der ganze Branch.

9.6 Alle verschlimmbessert? Dann ein Rollback zu einem früheren Hash

git reflog
# gewünschten früheren HEAD wählen und zurückspringen:
git reset --hard <reflog-hash>

---

10. HisQu-spezifische Git-Themen (separater Guide)

HisQu-spezifische Git-Themen sind in einem eigenen Guide beschrieben:
HisQu-Spezifischer-GitGuide

[^1]: Der Befehl kann sich je nach Distribution unterscheiden. Nachfolgend die Git-Installationsbefehle für die gängisten Distributionen: Ubuntu / Debian / Linux Mint: sudo apt install git -y Fedora: sudo dnf install git -y Arch/ Manjaro: sudo pacman -S git openSUSE: sudo zypper install git