6 Git und GitHub – Die Basis für GitOps

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.

6.1 Git-Grundlagen

6.1.1 Repositories und Commits

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 --graph

Commits bilden einen gerichteten azyklischen Graphen (DAG). Jeder Commit verweist auf seinen Parent-Commit, wodurch eine unveränderliche Kette entsteht.

6.1.2 Branches als Pointer, nicht als Lane

Kritisches Konzept: Ein Git Branch ist KEIN separater Entwicklungsstrang oder eine “Lane”. Ein Branch ist lediglich ein beweglicher Pointer auf einen bestimmten Commit.

6.1.2.1 Branches sind keine Lanes

Ungünstige Darstellung

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-xyz

Praktische 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ücksetzen

Warum ist das wichtig für GitOps?

6.1.3 Merge-Strategien und Konfliktlösung

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-Bewegung

Three-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-Commit

Merge-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-xyz

Konfliktauflösung erfordert manuelle Entscheidung und anschließenden Commit:

# Konflikt lösen, dann:
git add .
git commit -m "Resolve merge conflict: set replicas to 4"

6.2 Git-Workflows im Kontext von GitOps

6.2.1 Repository-Struktur

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:

6.2.2 Branching-Strategien

Environment-based Branching Jede Umgebung hat einen eigenen Branch:

main         # Production
├── staging  # Staging-Umgebung
└── develop  # Development-Umgebung

Feature-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-monitoring

Release-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.0

Hotfix-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-patch

6.2.3 Commit-Conventions

Strukturierte 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 issues

Commit-Typen für GitOps:

6.3 Zusammenarbeit und Kollaboration

6.3.1 Pull Requests und Code Reviews

Pull 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üfen

Review-Aspekte für GitOps:

6.3.2 Repository-Management und Zugriffsrechte

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-team

Zugriffsmatrix:

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)

6.4 Automatisierung mit GitHub

6.4.1 GitHub Actions Grundlagen

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 --strict

Automatische 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 push

6.4.2 Integration in GitOps-Prozesse

Automatisierte 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.