Git & GitLab für die Diplomarbeit
Git ist ein Versionskontrollsystem, das euch ermöglicht, Änderungen an eurer Arbeit zu verfolgen, rückgängig zu machen und im Team parallel zu arbeiten. Für die Diplomarbeit ist es unverzichtbar.
Warum Git für LaTeX?
Versionskontrolle
Jede Änderung wird gespeichert. Ihr könnt jederzeit zu einer früheren Version zurückkehren.
Paralleles Arbeiten
Jeder arbeitet an seinem Kapitel. Git führt die Änderungen zusammen – ohne USB-Stick-Chaos.
Backup
Euer Repository auf GitLab (gitlab.htlwrn.ac.at) ist ein automatisches Backup. Laptop kaputt? Kein Problem.
Nachvollziehbarkeit
Wer hat wann was geändert? Git dokumentiert das automatisch – wichtig für die Bewertung.
Repository einrichten
Schritt 1: GitLab-Repository erstellen
- Ein Teammitglied erstellt auf gitlab.htlwrn.ac.at ein neues Projekt (Repository)
- Name: z.B. diplomarbeit-2025-teamname
- Sichtbarkeit: Private (eure Arbeit ist nicht öffentlich)
- „Initialize repository with a README“ anhaken, damit ihr sofort klonen könnt
Schritt 2: Teammitglieder hinzufügen
- Projekt → Manage → Members
- Alle Teammitglieder mit ihrem Schul-Account (GitLab-Benutzername) hinzufügen
- Rolle: Developer (Schreibrechte)
Schritt 3: Repository klonen
# Repository klonen (jeder macht das einmal):
git clone https://gitlab.htlwrn.ac.at/username/diplomarbeit-2025.git
# In den Ordner wechseln:
cd diplomarbeit-2025Die .gitignore für LaTeX
Diese Datei sagt Git, welche Dateien ignoriert werden sollen (temporäre LaTeX-Dateien, etc.):
# LaTeX temporäre Dateien
*.aux
*.bbl
*.bcf
*.blg
*.fdb_latexmk
*.fls
*.log
*.out
*.run.xml
*.synctex.gz
*.toc
*.lof
*.lot
*.idx
*.ilg
*.ind
*.glo
*.gls
*.glg
*.acn
*.acr
*.alg
# Kompiliertes PDF (optional - manche committen das PDF)
# *.pdf
# Editor-spezifisch
*.swp
*.bak
*~
.vscode/
.idea/
# OS-spezifisch
.DS_Store
Thumbs.dbPDF committen?
Empfehlung: Das kompilierte PDF nicht committen (in .gitignore aufnehmen). PDFs sind binär und erzeugen grosse Diffs. Stattdessen: Jeder kompiliert lokal, oder ihr nutzt GitLab CI/CD für automatisches Kompilieren.
Projektstruktur
So sollte euer Repository aufgebaut sein:
diplomarbeit-2025/
├── .gitignore
├── README.md
├── main.tex # Hauptdatei
├── literatur.bib # Exportiert von Zotero
├── settings.tex # Paket-Einstellungen
│
├── kapitel/
│ ├── einleitung.tex # Gemeinsam
│ ├── grundlagen.tex # Gemeinsam oder aufgeteilt
│ ├── max-backend.tex # Kapitel von Max
│ ├── lisa-frontend.tex # Kapitel von Lisa
│ ├── tom-datenbank.tex # Kapitel von Tom
│ └── fazit.tex # Gemeinsam
│
├── images/
│ ├── max/ # Bilder von Max
│ ├── lisa/ # Bilder von Lisa
│ └── tom/ # Bilder von Tom
│
├── code/ # Quellcode-Listings
│ ├── max/
│ ├── lisa/
│ └── tom/
│
└── anhang/
├── anhang-a.tex
└── anhang-b.texWichtig
Jedes Teammitglied arbeitet in eigenen Dateien. Max bearbeitet max-backend.tex, Lisa bearbeitet lisa-frontend.tex. So gibt es kaum Merge-Konflikte!
Täglicher Git-Workflow
Der einfache Workflow (für den Anfang)
# 1. Vor dem Arbeiten: Neueste Änderungen holen
git pull
# 2. Arbeiten: Kapitel schreiben, Bilder hinzufügen, etc.
# ... (in eurem Editor)
# 3. Änderungen ansehen:
git status
git diff
# 4. Änderungen zum Commit vormerken:
git add kapitel/max-backend.tex
git add images/max/architektur.png
# 5. Commit mit aussagekräftiger Nachricht:
git commit -m "Kapitel 3.2: REST-API Implementierung beschrieben"
# 6. Auf GitLab hochladen:
git pushGute Commit-Nachrichten
| Schlecht | Gut |
|---|---|
| update | Kapitel 3.1: Anforderungsanalyse fertig |
| fix | Tippfehler in Einleitung korrigiert |
| asdf | Abbildung 4.2: Datenbankschema hinzugefügt |
| stuff | Literaturverzeichnis: 5 neue Quellen hinzugefügt |
Branch-Strategie
Einfache Strategie: Nur main
Für die meisten Diplomarbeits-Teams reicht ein einziger Branch. Funktioniert gut, wenn:
- Jeder in eigenen Dateien arbeitet
- Ihr regelmäßig git pull macht
- Ihr kleine, häufige Commits macht
Feature-Branch-Strategie (fortgeschritten)
Für Teams, die sich besser absichern wollen:
# Neuen Branch für ein Feature erstellen:
git checkout -b feature/lisa-kapitel-4
# Darin arbeiten und committen:
git add .
git commit -m "Kapitel 4: Erster Entwurf Frontend-Design"
# Auf GitLab pushen:
git push -u origin feature/lisa-kapitel-4
# Merge Request auf GitLab erstellen
# → Teammitglieder reviewen den Code
# → Nach Approval: Merge in mainMerge-Konflikte lösen
Wenn zwei Personen die gleiche Datei bearbeitet haben, gibt es einen Merge-Konflikt:
# Beim git pull erscheint:
# CONFLICT (content): Merge conflict in kapitel/einleitung.tex
# Die Datei enthält dann:
<<<<<<< HEAD
Die Anwendung wurde mit React entwickelt.
=======
Die Anwendung basiert auf dem React-Framework.
>>>>>>> origin/main
# Lösung: Die richtige Version behalten,
# die Markierungen löschen:
Die Anwendung basiert auf dem React-Framework.
# Dann:
git add kapitel/einleitung.tex
git commit -m "Merge-Konflikt in Einleitung gelöst"Konflikte vermeiden
- Arbeitet in eigenen Dateien – der wichtigste Tipp!
- Macht häufig git pull (mindestens vor jeder Arbeitssession)
- Macht kleine Commits statt grosse Batches
- Kommuniziert im Team: „Ich arbeite gerade an der Einleitung“
GitLab CI/CD: Automatisch kompilieren
Ihr könnt GitLab CI/CD einrichten, um euer LaTeX-Dokument bei jedem Push automatisch zu kompilieren. Dazu legt ihr eine Datei .gitlab-ci.yml im Projekt-Hauptverzeichnis an:
# .gitlab-ci.yml
compile:
image: texlive/texlive:latest
script:
- latexmk -pdf main.tex
artifacts:
paths:
- main.pdf
expire_in: 4 weeks
rules:
- if: '$CI_COMMIT_BRANCH == "main"'Vorteil
Bei jedem Push wird das PDF automatisch kompiliert und steht als Artefakt zum Download bereit. So kann der Betreuer jederzeit die aktuelle Version herunterladen, ohne LaTeX installiert zu haben.
Checkliste Git-Setup
- GitLab-Repository erstellt (Private)
- Alle Teammitglieder als Members hinzugefügt
- .gitignore für LaTeX eingerichtet
- Projektstruktur mit eigenen Dateien pro Person
- Jeder hat das Repo geklont
- Erster Commit: Vorlage + leere Kapitel-Dateien
- Vereinbarung: Wie oft committen? Wer bearbeitet welche Dateien?