Kapitel 10: Unternehmenspraxis

10.1 Projektarchitektur & Branch-Planung

📖 Typische Unternehmens-Branch-Strategie

main (Produktion - stabil)
 ├── develop (Entwicklungs-Branch - aktuell)
 │    ├── feature/login (Feature-Branches)
 │    ├── feature/payment
 │    └── feature/profil
 ├── release/v1.0 (Release-Vorbereitung)
 └── hotfix/bug-123 (Schnelle Bugfixes für Produktion)

🔹 Branch-Typen im Unternehmen

Branch-Typ	Erstellt von	Wird gemergt in	Lebensdauer	Besonderheit
main	–	–	Permanent	Schutz aktivieren (Branch protection)
develop	main	main (via release)	Permanent	Integrations-Branch
feature/*	develop	develop	Kurzlebig	1 Feature = 1 Branch
release/*	develop	main + develop	Kurzlebig	Nur Bugfixes erlaubt
hotfix/*	main	main + develop	Kurzlebig	Kritische Fehler sofort beheben

🔹 Branch-Benennungskonventionen

feature/user-authentication
feature/payment-gateway
bugfix/header-alignment
hotfix/critical-security-fix
release/v1.2.0
docs/api-documentation-update

Regeln:

✅ Kleinbuchstaben mit Bindestrichen (-)
✅ Präfix verwenden (feature/, bugfix/, etc.)
✅ Beschreibend (nicht feature1)

10.2 Täglicher Entwicklungsablauf

📝 Typischer Arbeitsablauf (Daily Workflow)

1. Arbeitsbeginn:
   git checkout develop
   git pull origin develop

2. Neuen Feature-Branch erstellen:
   git checkout -b feature/mein-feature

3. Entwickeln:
   # ... Code schreiben ...
   git add .
   git commit -m "Feature: ..."
   # (Mehrere Commits über den Tag)

4. Mittagspause / Ende des Tages:
   git push origin feature/mein-feature

5. Nächster Tag:
   git checkout develop
   git pull origin develop
   git checkout feature/mein-feature
   git rebase develop  # (Optional: Historie bereinigen)

6. Fertigstellung:
   # Pull Request erstellen (GitHub/GitLab)
   # Code-Review abwarten
   # Nach Genehmigung: Merge in develop

🔹 Best Practices für tägliche Arbeit

Tipp	Erklärung
Häufig committen	Kleine, logische Einheiten (nicht riesige Commits)
Aussagekräftige Nachrichten	`Feature: Login hinzugefügt` statt `fix`
Häufig pullen	`git pull origin develop` (mindestens 1x täglich)
Vor dem Push testen	Lokalen Build/Tests ausführen
Pull Requests verwenden	Niemals direkt auf `develop` oder `main` pushen

10.3 Merge-Konflikte in der Praxis

📖 Wann treten Konflikte häufig auf?

Szenario	Warum?	Prävention
Langelebige Branches	Viele Änderungen in `develop`	✅ Häufig in `develop` rebasen/mergen
Gleiche Datei, gleiche Zeile	Zwei Entwickler ändern dieselbe Stelle	✅ Kommunikation im Team
Verschiedene Branches mergen	`feature/A` und `feature/B` ändern Gleiches	✅ Kleine, fokussierte Commits

🔹 Konfliktlösung: Schritt-für-Schritt (Praxis)

Szenario: Sie wollen feature/login in develop mergen, aber es gibt Konflikte.

Schritt 1: Vor dem Merge aktualisieren

bash

# Auf develop wechseln
git checkout develop

# Neueste Änderungen pullen
git pull origin develop

# Zurück zu Ihrem Feature-Branch
git checkout feature/login

# Develop in Ihren Branch mergen (Konflikte hier lösen!)
git merge develop

Schritt 2: Konfliktdateien prüfen

bash

# Welche Dateien haben Konflikte?
git status

# Ausgabe:
# both modified:   src/login.js

Schritt 3: Konflikt in Editor lösen

javascript

// Beispiel: src/login.js
<<<<<<< HEAD (develop)
function authenticate(user, pass) {
=======
function authenticate(username, password) {
>>>>>>> develop

Lösung (Datei bearbeiten):

javascript

function authenticate(username, password) {

Schritt 4: Nach der Lösung committen

bash

# Datei zur Staging Area hinzufügen
git add src/login.js

# Merge abschließen
git commit -m "Merge: develop in feature/login (Konflikt gelöst)"

# Pushen
git push origin feature/login

Schritt 5: Pull Request erstellen

Auf GitHub/GitLab: PR von feature/login → develop
Teammitglieder überprüfen den Code

🔹 Konfliktprävention: `git rebase` (Fortgeschrittene)

bash

# Anstatt `git merge develop`:
git checkout feature/login
git rebase develop

# Konflikte beheben (falls auftretend)
git add <datei>
git rebase --continue

# Nach Rebase: Force Push erforderlich!
git push --force-with-lease origin feature/login

Vorteile von Rebase:

✅ Saubere Historie (lineare Historie)
✅ Keine unnötigen Merge-Commits

Nachteile:

❌ Gefährlich für geteilte Branches (nicht auf main/develop verwenden!)
❌ Force Push erforderlich

10.4 Versionsveröffentlichung & Tag-Verwaltung (`git tag`)

📖 Was sind Tags?

Tags markieren wichtige Meilensteine (z.B. Version 1.0.0).

🔹 1. Tag erstellen

bash

# Leichtgewichts-Tag (Lightweight)
git tag v1.0.0

# Annotiertes Tag (Empfohlen - enthält Metadaten)
git tag -a v1.0.0 -m "Version 1.0.0 Release"

# Tag für einen bestimmten Commit erstellen
git tag -a v0.9.0 a1b2c3d -m "Beta-Release"

🔹 2. Tags anzeigen

bash

# Alle Tags anzeigen
git tag

# Tags mit Beschreibung anzeigen
git tag -l -n1

# Ausgabe-Beispiel:
# v1.0.0          Version 1.0.0 Release
# v0.9.0          Beta-Release

🔹 3. Tags pushen

bash

# Einen spezifischen Tag pushen
git push origin v1.0.0

# Alle Tags pushen
git push origin --tags

🔹 4. Release-Branch-Workflow (Best Practice)

1. Release-Branch erstellen:
   git checkout develop
   git checkout -b release/v1.0.0

2. Release vorbereiten (nur Bugfixes!):
   # ... kleine Korrekturen ...
   git commit -m "Release: v1.0.0 Vorbereitung"

3. Release-Branch in main mergen:
   git checkout main
   git merge --no-ff release/v1.0.0

4. Tag auf main erstellen:
   git tag -a v1.0.0 -m "Version 1.0.0"
   git push origin v1.0.0

5. Release-Branch zurück in develop mergen:
   git checkout develop
   git merge --no-ff release/v1.0.0

6. Release-Branch löschen:
   git branch -d release/v1.0.0
   git push origin --delete release/v1.0.0

10.5 Projekt-Backup & Wiederherstellung

🔹 1. Backup-Strategie

Warum Backups?

✅ Serverabsturz: GitHub/GitLab könnten (selten) ausfallen
✅ Menschliches Versagen: Accidental Deletion von Repositories
✅ Rechtliche Gründe: Code muss lokal vorhanden sein

🔹 2. Backup-Methoden

Methode 1: Bare Clone (Vollbackup)

bash

# Vollständiges Backup (alle Branches, Tags, Historie)
git clone --bare https://github.com/firma/projekt.git projekt-backup.git

Vorteile:

✅ Enthält alles (Branches, Tags, Historie)
✅ Kann als neues Remote genutzt werden

Methode 2: Bundle erstellen

bash

# Bundle-Datei erstellen (eine Datei, einfach zu speichern)
git bundle create projekt-backup.bundle --all

Wiederherstellen:

bash

# Aus Bundle klonen
git clone projekt-backup.bundle projekt-wiederhergestellt

Methode 3: Regelmäßige Klone (Einfach)

bash

# Tägliches Backup via Cron-Job (Linux/Mac)
0 2 * * * cd /backup && git clone --mirror https://github.com/firma/projekt.git

🔹 3. Wiederherstellungsszenarien

Szenario 1: GitHub-Repository gelöscht (Aber lokale Kopie vorhanden)

bash

# 1. Neues Repository auf GitHub erstellen
# 2. Alte URL entfernen
git remote remove origin

# 3. Neue URL hinzufügen
git remote add origin https://github.com/firma/projekt-neu.git

# 4. Alles pushen
git push -u origin --all
git push -u origin --tags

Szenario 2: Lokales Repository korrupt

bash

# 1. Backup klonen
git clone /pfad/zu/projekt-backup.git projekt-wiederhergestellt

# 2. Überprüfen, ob alles da ist
git log --oneline
git branch -a

Szenario 3: Accidental Force Push (Historie überschrieben)

bash

# 1. Reflog auf dem Server überprüfen (falls Zugriff)
git reflog

# 2. Alternativ: Kollegen fragen, ob sie eine aktuelle Kopie haben
# 3. Deren Kopie klonen und neu pushen

Prävention:

✅ Branch Protection aktivieren (kein Force Push auf main/develop)
✅ --force-with-lease verwenden (sicherer als --force)

📝 Zusammenfassung

In diesem Kapitel haben Sie gelernt:

✅ Unternehmens-Branch-Strategie (main/develop/feature/release/hotfix)
✅ Täglichen Entwicklungsablauf (Best Practices)
✅ Merge-Konflikte lösen (Schritt-für-Schritt)
✅ Tags für Releases verwenden (git tag)
✅ Backup & Wiederherstellung (Methoden & Szenarien)

Nächstes Kapitel: Wir werden Git- Fortgeschrittene-Themen behandeln (Aliase, Hooks, CI/CD).

Kapitel 10: Unternehmenspraxis ​

10.1 Projektarchitektur & Branch-Planung ​

📖 Typische Unternehmens-Branch-Strategie ​

🔹 Branch-Typen im Unternehmen ​

🔹 Branch-Benennungskonventionen ​

10.2 Täglicher Entwicklungsablauf ​

📝 Typischer Arbeitsablauf (Daily Workflow) ​

🔹 Best Practices für tägliche Arbeit ​

10.3 Merge-Konflikte in der Praxis ​

📖 Wann treten Konflikte häufig auf? ​

🔹 Konfliktlösung: Schritt-für-Schritt (Praxis) ​

🔹 Konfliktprävention: git rebase (Fortgeschrittene) ​

10.4 Versionsveröffentlichung & Tag-Verwaltung (git tag) ​

📖 Was sind Tags? ​

🔹 1. Tag erstellen ​

🔹 2. Tags anzeigen ​

🔹 3. Tags pushen ​

🔹 4. Release-Branch-Workflow (Best Practice) ​

10.5 Projekt-Backup & Wiederherstellung ​

🔹 1. Backup-Strategie ​

🔹 2. Backup-Methoden ​

Methode 1: Bare Clone (Vollbackup) ​

Methode 2: Bundle erstellen ​

Methode 3: Regelmäßige Klone (Einfach) ​

🔹 3. Wiederherstellungsszenarien ​

Szenario 1: GitHub-Repository gelöscht (Aber lokale Kopie vorhanden) ​

Szenario 2: Lokales Repository korrupt ​

Szenario 3: Accidental Force Push (Historie überschrieben) ​

📝 Zusammenfassung ​

🔗 Weiterführende Links ​

Kapitel 10: Unternehmenspraxis

10.1 Projektarchitektur & Branch-Planung

📖 Typische Unternehmens-Branch-Strategie

🔹 Branch-Typen im Unternehmen

🔹 Branch-Benennungskonventionen

10.2 Täglicher Entwicklungsablauf

📝 Typischer Arbeitsablauf (Daily Workflow)

🔹 Best Practices für tägliche Arbeit

10.3 Merge-Konflikte in der Praxis

📖 Wann treten Konflikte häufig auf?

🔹 Konfliktlösung: Schritt-für-Schritt (Praxis)

🔹 Konfliktprävention: `git rebase` (Fortgeschrittene)

10.4 Versionsveröffentlichung & Tag-Verwaltung (`git tag`)

📖 Was sind Tags?

🔹 1. Tag erstellen

🔹 2. Tags anzeigen

🔹 3. Tags pushen

🔹 4. Release-Branch-Workflow (Best Practice)

10.5 Projekt-Backup & Wiederherstellung

🔹 1. Backup-Strategie

🔹 2. Backup-Methoden

Methode 1: Bare Clone (Vollbackup)

Methode 2: Bundle erstellen

Methode 3: Regelmäßige Klone (Einfach)

🔹 3. Wiederherstellungsszenarien

Szenario 1: GitHub-Repository gelöscht (Aber lokale Kopie vorhanden)

Szenario 2: Lokales Repository korrupt

Szenario 3: Accidental Force Push (Historie überschrieben)

📝 Zusammenfassung

🔗 Weiterführende Links