Git bildet das technische Fundament jeder GitOps-Implementierung. Ein korrektes Verständnis der Git-Konzepte ist entscheidend für erfolgreiche GitOps-Workflows. Diese Schulung vermittelt die notwendigen Grundlagen und deren praktische Anwendung.
Ein Git-Repository ist ein Verzeichnis mit einer .git/
Subdirectory, die die gesamte Versionsgeschichte enthält. Anders als
zentrale Versionskontrollsysteme speichert Git die komplette Historie
lokal.
Ein Commit ist eine unveränderliche Momentaufnahme des Repository-Zustands. Jeder Commit hat:
# Repository initialisieren
git init mein-projekt
cd mein-projekt
# Ersten Commit erstellen
echo "Initial setup" > README.md
git add README.md
git commit -m "Initial commit"
# Commit-Historie anzeigen
git log --oneline --graphCommits bilden einen gerichteten azyklischen Graphen (DAG). Jeder Commit verweist auf seinen Parent-Commit, wodurch eine unveränderliche Kette entsteht.
Kritisches Konzept: Ein Git Branch ist KEIN separater Entwicklungsstrang oder eine “Lane”. Ein Branch ist lediglich ein beweglicher Pointer auf einen bestimmten Commit.
Diese Darstellung zeigt ein klassisches Missverständnis: Einen Branch als ein Zweig im Git Baum. Intuitiv, aber falsch
Dann müssten alle Commits eines Pfades zu diesem Branch gehören
Tatsächlich ist ein Branch nichts weiter als ein Label an EINEM commit
Mit der Eigenschaft das sie jederzeit an einen anderen commit versetzt, oder gar entfernt werden können.
# Branch erstellen - erstellt nur einen neuen Pointer
git branch feature-xyz
# Zeigt jetzt auf denselben Commit wie der aktuelle Branch
# Branch wechseln - bewegt HEAD zu diesem Pointer
git checkout feature-xyz
# oder mit neuerer Syntax:
git switch feature-xyzPraktische Demonstration des Pointer-Konzepts:
# Aktueller Zustand anzeigen
git log --oneline --all --graph
# Neuen Commit auf feature-xyz machen
echo "Feature implementation" > feature.txt
git add feature.txt
git commit -m "Add feature implementation"
# Der Branch-Pointer hat sich automatisch vorwärts bewegt
git log --oneline --all --graph
# Branch-Pointer manuell verschieben (fortgeschritten)
git branch -f feature-xyz HEAD~1 # Pointer um einen Commit zurücksetzenWarum ist das wichtig für GitOps?
Git bietet verschiedene Merge-Strategien, die den Commit-Graphen unterschiedlich beeinflussen:
Fast-Forward Merge Wenn der Zielbranch keine neuen Commits hat, wird der Branch-Pointer einfach vorwärts bewegt:
git checkout main
git merge feature-xyz # Fast-forward möglich
# Kein Merge-Commit nötig, nur Pointer-BewegungThree-Way Merge Wenn beide Branches neue Commits haben, erstellt Git einen Merge-Commit mit zwei Parents:
git checkout main
echo "Main development" > main.txt
git add main.txt && git commit -m "Main branch work"
git merge feature-xyz # Erstellt Merge-CommitMerge-Konflikte Entstehen bei gleichzeitigen Änderungen derselben Dateiregion:
# Konflikt-Markierung in Kubernetes-Manifest
apiVersion: apps/v1
kind: Deployment
spec:
<<<<<<< HEAD
replicas: 3 # Main branch
=======
replicas: 5 # Feature branch
>>>>>>> feature-xyzKonfliktauflösung erfordert manuelle Entscheidung und anschließenden Commit:
# Konflikt lösen, dann:
git add .
git commit -m "Resolve merge conflict: set replicas to 4"Eine klare Repository-Struktur ist fundamental für GitOps-Erfolg:
gitops-repo/
├── clusters/ # Cluster-spezifische Konfigurationen
│ ├── development/
│ ├── staging/
│ └── production/
├── applications/ # Anwendungsdefinitionen
│ ├── web-app/
│ ├── api-service/
│ └── database/
├── infrastructure/ # Infrastruktur-Komponenten
│ ├── ingress-nginx/
│ ├── cert-manager/
│ └── monitoring/
└── base/ # Gemeinsame Basis-Konfigurationen
├── namespaces/
└── rbac/
Wichtige Prinzipien:
Environment-based Branching Jede Umgebung hat einen eigenen Branch:
main # Production
├── staging # Staging-Umgebung
└── develop # Development-UmgebungFeature-Branch Workflow Neue Funktionen werden in separaten Branches entwickelt:
# Feature-Branch erstellen
git checkout -b feature/new-monitoring
# Entwicklung durchführen
git commit -m "Add Prometheus configuration"
# Zurück mergen
git checkout develop
git merge feature/new-monitoringRelease-Branch Workflow Für koordinierte Releases mehrerer Komponenten:
git checkout -b release/v1.2.0
# Sammelt mehrere Features
git merge feature/monitoring
git merge feature/security-updates
# Testing und Bugfixes
git commit -m "Fix configuration issue"
# Release abschließen
git checkout main
git merge release/v1.2.0
git tag v1.2.0Hotfix-Workflow Für kritische Produktions-Fixes:
git checkout -b hotfix/security-patch main
# Schnelle Korrektur
git commit -m "security: patch CVE-2024-001"
# In alle relevanten Branches mergen
git checkout main && git merge hotfix/security-patch
git checkout develop && git merge hotfix/security-patchStrukturierte Commit-Nachrichten für GitOps-Repositories:
# Format: <type>(<scope>): <description>
# Beispiele:
feat(apps): add Redis cache for session storage
fix(infra): correct ingress TLS configuration
config(monitoring): increase Prometheus retention to 30d
security(rbac): implement namespace isolation
docs(readme): update deployment instructions
revert(apps): rollback nginx to v1.20 due to compatibility issuesCommit-Typen für GitOps:
feat: Neue Anwendungen oder Featuresfix: Fehlerkorrekturenconfig: Konfigurationsänderungensecurity: Sicherheits-relevante Änderungeninfra: Infrastruktur-Komponentendocs: Dokumentationrevert: RollbacksPull Requests sind in GitOps-Umgebungen kritische Kontrollpunkte, da Änderungen direkten Einfluss auf die Infrastruktur haben.
Pull Request Template für GitOps:
## Änderungsbeschreibung
**Was:** Erhöhe Replica-Count von 3 auf 5 für web-app
**Warum:** Monitoring zeigt CPU-Bottlenecks bei Spitzenlasten
**Wo:** production/web-app/deployment.yaml
## Auswirkungsanalyse
- **Betroffene Umgebung:** Production
- **Geschätzte Downtime:** Keine (Rolling Update)
- **Resource-Auswirkung:** +67% Pod-Count, +40% CPU-Requests
## Testing
- [x] Lokale Validierung mit kubeval
- [x] Staging-Deployment erfolgreich
- [x] Load-Tests bestanden
## Rollback-Plan
1. git revert dieses Commits
2. ArgoCD sync (~30 Sekunden)
3. Monitoring auf Service-Health prüfenReview-Aspekte für GitOps:
Branch Protection Rules:
# Konzeptionelle Darstellung der GitHub Branch Protection
main:
required_reviews: 2
dismiss_stale_reviews: true
require_code_owner_review: true
required_status_checks:
- "validate-kubernetes-manifests"
- "security-scan"
restrictions:
teams: ["platform-team", "sre-leads"]
staging:
required_reviews: 1
required_status_checks:
- "validate-kubernetes-manifests"
restrictions:
teams: ["developers", "platform-team"]CODEOWNERS für automatische Reviews:
# .github/CODEOWNERS
# Global fallback
* @platform-team
# Production-Änderungen brauchen erweiterte Reviews
/clusters/production/ @platform-team @sre-team
# Security-relevante Änderungen
/infrastructure/security/ @security-team
**/rbac/ @security-team
# Monitoring-Konfigurationen
**/monitoring/ @sre-teamZugriffsmatrix:
| Team | Development | Staging | Production | Infrastruktur |
|---|---|---|---|---|
| Developers | Read/Write | Read | Read | Read |
| Platform Team | Read/Write | Read/Write | Read/Write | Read/Write |
| SRE Team | Read/Write | Read/Write | Read/Write | Read/Write |
| Security Team | Read | Read | Read | Read/Write (Security) |
GitHub Actions transformieren Git-Repositories von passiven Speichern zu aktiven, intelligenten Systemen.
Basis-Workflow für Manifest-Validierung:
# .github/workflows/validate.yml
name: Validate Kubernetes Manifests
on:
pull_request:
paths: ['**/*.yaml', '**/*.yml']
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup kubectl
uses: azure/setup-kubectl@v3
- name: Validate YAML syntax
run: |
find . -name "*.yaml" -o -name "*.yml" | while read file; do
echo "Validating $file"
kubectl apply --dry-run=client --validate=true -f "$file"
done
- name: Check resource limits
run: |
python scripts/validate-resources.py --strictAutomatische Konfigurationsgenerierung:
# .github/workflows/generate-configs.yml
name: Generate Environment Configs
on:
push:
branches: [main]
paths: ['templates/**']
jobs:
generate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
- name: Install Kustomize
run: |
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
- name: Generate manifests
run: |
for env in development staging production; do
kustomize build overlays/$env > clusters/$env/generated.yaml
done
- name: Commit generated files
run: |
git config --local user.email "action@github.com"
git config --local user.name "GitHub Action"
git add clusters/*/generated.yaml
git diff --staged --quiet || \
git commit -m "auto: regenerate environment configs" && \
git pushAutomatisierte Sicherheitsprüfungen:
# .github/workflows/security.yml
name: Security Scan
on: [pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Polaris
uses: FairwindsOps/polaris/.github/actions/polaris@master
with:
config-path: .polaris.yml
- name: Run Trivy
uses: aquasecurity/trivy-action@master
with:
scan-type: 'config'
scan-ref: '.'Deployment-Notification:
# .github/workflows/deployment-notification.yml
name: Deployment Notification
on:
push:
branches: [main]
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Notify deployment
run: |
curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
-H 'Content-type: application/json' \
--data "{
\"text\": \"🚀 Production deployment initiated\",
\"blocks\": [{
\"type\": \"section\",
\"text\": {
\"type\": \"mrkdwn\",
\"text\": \"Commit: \`${{ github.sha }}\`\nAuthor: ${{ github.actor }}\nMessage: ${{ github.event.head_commit.message }}\"
}
}]
}"Audit Logging:
# .github/workflows/audit.yml
name: Audit Changes
on:
push:
branches: [main, staging, production]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- name: Log to audit system
run: |
curl -X POST https://audit.company.com/api/gitops-changes \
-H "Authorization: Bearer ${{ secrets.AUDIT_TOKEN }}" \
-H "Content-Type: application/json" \
-d '{
"repository": "${{ github.repository }}",
"branch": "${{ github.ref_name }}",
"commit": "${{ github.sha }}",
"author": "${{ github.actor }}",
"message": "${{ github.event.head_commit.message }}",
"timestamp": "${{ github.event.head_commit.timestamp }}"
}'Diese Automation stellt sicher, dass GitOps-Repositories nicht nur als Konfigurationsspeicher fungieren, sondern als intelligente Systeme, die Qualität, Sicherheit und Compliance automatisch durchsetzen.