MB Dev .tech
Registrieren Login

Git · Workflow & Best Practices

← Zurück zu Git Grundlagen

Git kann man „irgendwie benutzen“ – oder man benutzt es so, dass ein Projekt langfristig sauber, nachvollziehbar und teamtauglich bleibt. Hier geht es um typische Workflows und kleine Regeln, die dir viel Ärger sparen.

Merke
Git ist Kommunikation – nicht nur Technik

Commits, Branch-Namen und Messages sind Infos für „dein Zukunfts-Ich“ und fürs Team.

1) Ein einfacher Workflow, der fast immer funktioniert

Für viele Projekte reicht ein sehr verständlicher Workflow:

  1. main bleibt stabil (nur getesteter Stand).
  2. Neue Arbeit kommt in einen Feature-Branch.
  3. Feature wird fertig gemacht, dann zurück in main gemerged.

Beispielhafte Branch-Namen:

  • feature/user-profile
  • bugfix/login-redirect
  • chore/update-deps
Tipp
Konsequent bleiben

Der beste Workflow ist der, der im Alltag wirklich genutzt wird. Lieber simpel und konsequent, als „perfekt“ und niemand hält sich dran.

2) Gute Commit-Messages (sehr unterschätzt)

Eine Commit-Message sollte erklären, was geändert wurde (und oft auch warum). Sie muss nicht lang sein, aber klar.

Merke
Schlechte Messages kosten später Zeit

„fix“ oder „update“ hilft niemandem, wenn du in 3 Monaten einen Fehler suchst.

Beispiele:

Beispiele für Messages

git commit -m "Add validation for registration form"
git commit -m "Fix redirect after logout"
git commit -m "Refactor invoice calculation into helper function"
Tipp
Ein Commit = eine klare Änderung

Wenn du in einem Commit „alles“ machst (Feature + Refactor + Bugfix), ist er schwer zu reviewen und schwer zurückzunehmen.

3) Häufige Fehler – und wie du sie vermeidest

3.1 „Ich committe alles immer mit git add .“

Das kann funktionieren, aber du verlierst Kontrolle. Besser: kurz prüfen, was genau in den Commit soll.

Kontrolle behalten

git status
git diff
git add file1.php
git add file2.php
git commit -m "..."

3.2 „Ich arbeite direkt auf main“

Wenn main dein stabiler Stand sein soll, ist das riskant. Besser: Branch pro Feature/Bugfix.

Achtung
main sollte nicht dein Experimentierplatz sein

Sonst mischst du halb fertige Sachen in den „stabilen“ Stand und kannst schwer nachvollziehen, wo etwas kaputt ging.

3.3 „Ich habe Konflikte – also ist Git kaputt“

Konflikte sind normal. Sie bedeuten: „Git braucht eine Entscheidung, weil zwei Änderungen kollidieren.“

4) „Pull before Push“ (wenn andere mitarbeiten)

Wenn mehrere Personen am Repo arbeiten, solltest du regelmäßig Änderungen vom Remote holen. Sonst versuchst du zu pushen und es kommt zu Konflikten oder einem abgelehnten Push.

Typisch im Alltag

git pull
# arbeiten, committen
git push
Merke
Konflikte lieber früh statt spät

Wenn du häufig pullst, löst du Konflikte in kleinen Portionen – das ist deutlich einfacher.

5) .gitignore: Was nicht ins Repo gehört

Manche Dateien willst du nicht versionieren: z.B. temporäre Dateien, Logs, lokale Konfigurationen oder Abhängigkeiten. Dafür gibt es .gitignore.

Beispiel .gitignore

# Logs
*.log

# OS / IDE
.DS_Store
.vscode/
.idea/

# Abhängigkeiten (Beispiel)
vendor/
node_modules/
Achtung
Secrets gehören nie ins Repo

API-Keys, Passwörter, Tokens oder Zugangsdaten gehören nicht in Commits. Wenn so etwas versehentlich drin ist, ist es oft schwer, das wieder „ungeschehen“ zu machen.

Kleine Aufgaben (zum Mitdenken)

Aufgabe: Gute vs. schlechte Commit-Message

Welche Message ist hilfreicher – und warum?
"fix" oder "Fix validation for email field in signup form"

Lösung einblenden
Lösung
Die zweite ist klarer und nachvollziehbar

Sie sagt was gefixt wurde und wo. Das hilft bei Reviews, bei der Suche nach Bugs und beim Verstehen der Historie.