Git Commits¶

Git Best Practices¶

1. Goldene Regeln¶

1. main bleibt immer deploybar. Was dort landet, ist geprüft und bereit für den nächsten Release.
2. Jedes Feature bekommt einen eigenen Branch von main. (feat/webtool-tourenplan-rework)
3. Test-Branches sind kurzlebig. Sie dienen dazu mehr als ein Feature zum Testen anzubieten. (test-feature1-feature2)
4. Sammel-Branches bleiben die Ausnahme. Für eng zusammenhängende Hotfixes oder Releases sind sie erlaubt aber zeitlich begrenzt.
5. Feature-Branches werden nach dem Go-live zeitnah gelöscht.

Beispiele:

• feature/new-login-page
• bugfix/fix-login-error
• refactor/admin-user-handling

2. Kleine, häufige Commits¶

• Ein Commit sollte möglichst eine kleine, abgeschlossene Einheit sein.
• Jeder Commit sollte einen klar definierten Zweck erfüllen.

3. Aussagekräftige Commit-Messages¶

• Beschreiben was geändert wurde.
• Beschreibung kurz, konkret und im Präsens.

---

Commit-Naming-Convention¶

Die Commit-Messages orientieren sich an Conventional Commits.

Allgemeiner Aufbau¶

<type>(<scope>): <description>

Aufbau¶

Teil	Beschreibung	Beispiel
type	Art der Änderung	feat, fix, refactor
scope	Betroffener Bereich der Anwendung	login, admin, cart, ci
description	Kurze Beschreibung der Änderung	add password reset link

Beispiele¶

feat(login): add password reset link
fix(admin): fix user permission check
refactor(cart): simplify price calculation
style(login): adjust form spacing
docs(readme): update setup guide
deploy(ci): add live environment variable
test(api): add order endpoint tests
cleanup(assets): remove unused graphics

---

Commit-Typen¶

Typ	Beschreibung
feat	Neues Feature
fix	Bugfix
refactor	Code-Refaktorierung ohne Funktionsänderung
style	Änderungen an Formatierung, Whitespace, CSS oder Darstellung
docs	Änderungen an Dokumentation
deploy	Änderungen an Deployment-Logik oder CI/CD
test	Hinzufügen oder Ändern von Tests
cleanup	Wartung/Aufräumen ohne Funktionsänderung

---

Scope¶

Der scope beschreibt den betroffenen Bereich der Anwendung.

Gute Scopes¶

login
register
admin
search
api
database
assets
readme

Beispiele¶

feat(login): add remember-me checkbox
fix(register): fix email validation
style(search): adjust button spacing
docs(readme): update installation steps
deploy(ci): add production deploy variable
test(api): add tests for order endpoint
cleanup(assets): remove unused icons

---

Beschreibung¶

Die Beschreibung sollte kurz und konkret sein.

Gut¶

fix(login): prevent session timeout
feat(admin): add user search filter
refactor(cart): simplify discount calculation

Schlecht¶

fix bug
changes
update stuff
login fixes

---

Breaking Changes¶

Wenn eine Änderung nicht rückwärtskompatibel ist, kann ein ! verwendet werden.

feat(auth)!: replace legacy password hashing
refactor(api)!: remove old order endpoint

---

Commit-Habits¶

• Vor dem Commit den Staging-Bereich prüfen.
• Nur zusammengehörige Änderungen in einen Commit packen.
• Kleine Zwischencommits bei Bedarf später per Squash zusammenfassen.