fristy/GIT_WORKFLOW.md

424 lines
7.3 KiB
Markdown

# Git Workflow Guide
## Branch-Strategie
### Main Branches
```
main (production)
└── develop (development)
```
- **main**: Produktions-Branch, immer stabil und deploybar
- **develop**: Entwicklungs-Branch, Integration aller Features
### Supporting Branches
#### Feature Branches
```
feature/feature-name
```
Von: `develop`
Merge zu: `develop`
**Beispiele:**
- `feature/user-authentication`
- `feature/contract-crud`
- `feature/dashboard-stats`
#### Release Branches
```
release/v1.0.0
```
Von: `develop`
Merge zu: `main` und `develop`
**Verwendung:**
- Vorbereitung eines neuen Releases
- Bug-Fixes für das Release
- Version-Bumps
- CHANGELOG aktualisieren
#### Hotfix Branches
```
hotfix/critical-bug-name
```
Von: `main`
Merge zu: `main` und `develop`
**Verwendung:**
- Kritische Bugs in Production
- Schnelle Fixes ohne auf Release zu warten
## Workflow-Prozess
### 1. Neues Feature entwickeln
```bash
# Von develop starten
git checkout develop
git pull origin develop
# Feature-Branch erstellen
git checkout -b feature/mein-feature
# Entwickeln...
git add .
git commit -m "feat(module): beschreibung"
# Push zum Remote
git push origin feature/mein-feature
# Pull Request erstellen auf GitHub/GitLab
# Nach Review: Merge zu develop
```
### 2. Release vorbereiten
```bash
# Release-Branch erstellen
git checkout develop
git checkout -b release/v0.2.0
# Version bumpen
npm run release:minor
# Oder manuell:
# - package.json version aktualisieren
# - CHANGELOG.md aktualisieren
# - iOS/Android Versions aktualisieren
git push origin release/v0.2.0
# Nach Tests: Merge zu main und develop
git checkout main
git merge release/v0.2.0
git tag -a v0.2.0 -m "Release v0.2.0"
git push origin main --tags
git checkout develop
git merge release/v0.2.0
git push origin develop
# Release-Branch löschen
git branch -d release/v0.2.0
```
### 3. Hotfix durchführen
```bash
# Hotfix-Branch erstellen
git checkout main
git checkout -b hotfix/critical-login-bug
# Fix implementieren
git add .
git commit -m "fix(auth): resolve critical login issue"
# Version bumpen (PATCH)
npm run release:patch
# Push
git push origin hotfix/critical-login-bug
# Merge zu main
git checkout main
git merge hotfix/critical-login-bug
git tag -a v0.2.1 -m "Hotfix v0.2.1"
git push origin main --tags
# Merge zu develop
git checkout develop
git merge hotfix/critical-login-bug
git push origin develop
# Hotfix-Branch löschen
git branch -d hotfix/critical-login-bug
```
## Commit-Guidelines
### Format
```
type(scope): subject
[optional body]
[optional footer]
```
### Types
- **feat**: Neues Feature
- **fix**: Bugfix
- **docs**: Dokumentation
- **style**: Code-Formatierung
- **refactor**: Code-Refactoring
- **perf**: Performance-Optimierung
- **test**: Tests
- **build**: Build-System
- **ci**: CI/CD
- **chore**: Sonstiges (Dependencies, etc.)
- **revert**: Revert eines Commits
### Scope
Module/Bereich des Projekts:
- `auth`
- `contracts`
- `dashboard`
- `notifications`
- `profile`
- `ui`
- `api`
- `store`
### Subject
- Imperativ, präsens: "add" nicht "added" oder "adds"
- Kein Punkt am Ende
- Kleinbuchstaben
- Max. 50 Zeichen
### Beispiele
```bash
# Gute Commits
git commit -m "feat(auth): add login screen with email validation"
git commit -m "fix(contracts): resolve date parsing error"
git commit -m "docs(readme): update installation instructions"
git commit -m "refactor(store): simplify contract selectors"
git commit -m "perf(dashboard): optimize contract list rendering"
# Breaking Change
git commit -m "feat(api)!: change authentication flow
BREAKING CHANGE: New auth flow requires token refresh"
# Mit Body
git commit -m "fix(auth): prevent duplicate login requests
Added debouncing to login button to prevent
multiple simultaneous requests"
```
## Pull Request Process
### 1. PR erstellen
```markdown
## Beschreibung
Kurze Beschreibung der Änderungen
## Typ der Änderung
- [ ] Bugfix
- [ ] Neues Feature
- [ ] Breaking Change
- [ ] Dokumentation
## Checklist
- [ ] Code folgt Projekt-Style-Guide
- [ ] Tests hinzugefügt/aktualisiert
- [ ] Dokumentation aktualisiert
- [ ] CHANGELOG.md aktualisiert
- [ ] Keine Merge-Konflikte
```
### 2. Review-Prozess
1. CI/CD-Pipeline muss grün sein
2. Code-Review von mindestens 1 Entwickler
3. Alle Kommentare müssen aufgelöst sein
4. Keine Breaking Changes ohne Diskussion
### 3. Merge-Strategie
**Feature → Develop:**
- Squash & Merge (alle Commits zu einem zusammenfassen)
**Release/Hotfix → Main:**
- Merge Commit (History beibehalten)
## Tagging
### Format
```
v{MAJOR}.{MINOR}.{PATCH}[-{PRE-RELEASE}]
```
### Beispiele
```bash
# Production Releases
git tag -a v1.0.0 -m "Release v1.0.0"
git tag -a v1.1.0 -m "Release v1.1.0 - Added export feature"
git tag -a v1.1.1 -m "Hotfix v1.1.1 - Fixed critical bug"
# Pre-Releases
git tag -a v1.0.0-alpha.1 -m "Alpha Release 1"
git tag -a v1.0.0-beta.1 -m "Beta Release 1"
git tag -a v1.0.0-rc.1 -m "Release Candidate 1"
# Push tags
git push origin --tags
```
## Nützliche Git-Befehle
### Branch-Management
```bash
# Alle Branches anzeigen
git branch -a
# Remote-Branches aktualisieren
git fetch --prune
# Branch löschen
git branch -d branch-name
git push origin --delete branch-name
# Zu anderem Branch wechseln
git checkout branch-name
git switch branch-name # neuer Befehl
```
### Änderungen verwalten
```bash
# Status anzeigen
git status
# Änderungen stagen
git add .
git add file.txt
# Commit erstellen
git commit -m "message"
# Letzten Commit ändern
git commit --amend
# Änderungen verwerfen
git restore file.txt
git restore .
```
### History
```bash
# Log anzeigen
git log
git log --oneline
git log --graph --oneline --all
# Unterschiede anzeigen
git diff
git diff branch1 branch2
```
### Rebase (vorsichtig verwenden!)
```bash
# Feature-Branch mit develop synchronisieren
git checkout feature/mein-feature
git rebase develop
# Interaktives Rebase (Commits aufräumen)
git rebase -i HEAD~3
```
## Best Practices
### ✅ DO
- Regelmäßig commits machen
- Aussagekräftige Commit-Messages
- Feature-Branches aktuell halten (regelmäßig von develop pullen)
- Pull Requests klein halten (< 400 Zeilen)
- Tests vor dem Push ausführen
- Code-Reviews ernst nehmen
### ❌ DON'T
- Direkt auf main/develop pushen
- Force-Push auf shared branches
- Große Binary-Dateien committen
- Secrets/API-Keys committen
- Merge-Konflikte ignorieren
- WIP-Commits ohne aufräumen
## Automatisierung
### Husky Hooks
**Pre-Commit:**
- Linting
- Formatierung
- Tests
**Commit-Msg:**
- Commit-Message-Validierung
**Pre-Push:**
- Tests
- Build
### GitHub Actions
**CI (Pull Requests):**
- Linting
- Type-Checking
- Tests
- Build
**Release (main branch):**
- Automatisches Versioning
- CHANGELOG generieren
- GitHub Release erstellen
- NPM Publish (optional)
## Troubleshooting
### Merge-Konflikte
```bash
# Konflikt anzeigen
git status
# Datei manuell editieren und Konflikt-Marker entfernen
# <<<<<<<, =======, >>>>>>>
# Nach dem Lösen
git add conflicted-file.txt
git commit
```
### Commit rückgängig machen
```bash
# Letzten Commit rückgängig (Änderungen behalten)
git reset --soft HEAD~1
# Letzten Commit rückgängig (Änderungen verwerfen)
git reset --hard HEAD~1
# Commit revert (neuer Commit)
git revert HEAD
```
### Branch wiederherstellen
```bash
# Gelöschten Branch finden
git reflog
# Branch wiederherstellen
git checkout -b recovered-branch <commit-hash>
```