Wie führt Ihr Unternehmen das Zusammenführen (Merge) oder das Umschreiben der Historie (Rebase) im Versionskontrollsystem durch?

In unserem Team folgen wir einem auf Git basierenden Workflow. Um Änderungen zu integrieren, verwenden wir zwei Hauptansätze: merge und rebase, je nach Situation und Branch-Typ.

Merge:

• Wird in der Regel verwendet, um langlebige Branches zusammenzuführen, z.B. dev in main, oder um Feature-Branches in dev zu integrieren.
• Erstellt einen Merge-Commit, der deutlich zeigt, wann die Änderungen aus anderen Branches zusammengeführt wurden.
• Bewahrt die vollständige Commit-Historie, einschließlich aller Verzweigungen.

git checkout dev  // Wechseln zum Ziel-Branch
git merge feature/neue-funktion  // Führen Sie den Feature-Branch zusammen

Rebase:

• Wird verwendet, um eine saubere und lineare Commit-Historie in Feature-Branches bis zu ihrer Integration (normalerweise in dev) zu bewahren.
• Überträgt die Commits des aktuellen Branches auf die Spitze des Ziel-Branches (dev), was die Geschichte effektiv "umschreibt".
• Vereinfacht die Historie, indem Merge-Commits für jede kleine Funktion oder Fix vermieden werden.
• Wichtig: Führen Sie niemals rebase auf öffentlichen Branches durch, an denen andere Entwickler arbeiten, da dies Konflikte beim Pullen von Änderungen verursachen kann.

git checkout feature/neue-funktion  // Wechseln zum Feature-Branch
git rebase dev  // Übertragen der Commits des Feature-Branches auf die Spitze von dev
// Bei Bedarf Konflikte lösen
git push --force-with-lease  // Verwenden Sie --force-with-lease für einen sicheren Push nach rebase

Unser Standard-Workflow:

1. Eine neue Funktion oder Korrektur wird in einem separaten Branch (feature/..., fix/...) entwickelt.
2. Der Feature-Branch wird regelmäßig (vor einem Pull-Request oder zur Synchronisation mit dev) auf die aktuelle dev-Version rebaset. Dies hilft, Konflikte frühzeitig zu lösen.
3. Nach Abschluss der Entwicklung und Code-Review wird der Feature-Branch mit no-ff (nicht fast-forward) in dev gemerged, um die Merge-Informationen zu erhalten. Oder seltener wird er vor dem Merge in dev in einem einzelnen Commit zusammengefasst (squash), besonders bei sehr kleinen Features oder Fixes.
4. Von dev aus werden regelmäßig Releases in main (Produktions-Branch) gemacht, immer durch merge.

Auf diese Weise balancieren wir die Erhaltung der Commit-Historie (merge) mit der Pflege eines sauberen Entwicklungszweigs (rebase der Feature-Branches).