Lieber Entwickler, ich verstehe Dich voll und ganz. Nach tagelangem Entwickeln, Build wieder in Gang bringen und Unit-Tests nachziehen reparieren will man nur noch abgeben und auf Main oder den Release-Branch mergen. Doch Halt! Das durch die sauberen Checkins gewonnene Glücksgefühl wird leicht aufs Spiel gesetzt wenn der Merge nicht nach gewissen Regeln abläuft…
…denn was wäre schlimmer als Änderungen beim Merge unbemerkt zu verlieren? Den korrekten Merge-Workflow zu befolgen ist daher mindestens genauso wichtig wie die Branching-Struktur selbst.
Forward Integration – also von einem Branch auf den mehrere andere Branches gemergt werden:
- Ziel-Branch im Workspace mappen und mit Get Latest den letzten Stand abrufen, da Merges in TFS lokale Operationen sind, die dann eingecheckt werden müssen.
- Check-In Lock auf dem Ziel-Branch setzen, um Änderungen von anderen Benutzern in der Zwischenzeit zu vermeiden.
- Label auf dem Quell-Branch identifizieren, welches gemergt werden soll – also zum Beispiel das Label des letzten erfolgreichen Builds. Im Zweifel ein Label auf die lokale Version setzen, wenn kein zentraler Build existiert und die Prüfungen lokal erfolgreich durchgeführt worden sind.
- Merge vom Quell-Branch aufrufen, Ziel-Branch und Quell-Label angeben.
- Etwaige Konflikte lösen.
- Einchecken (siehe Blog-Post Richtig Einchecken) und dabei den Check-In-Lock entfernen.
- Merge im Team bekanntgeben.
Reverse Integration – also von einem Branch der neue Änderungen evtl. aus weiteren Kinder-Branches enthält:
- Im Falle eines Ziel-Branches wie Main – auf den weitere Branches mergen – sollte vorab eine Forward Integration stattfinden.
- Workflow wie bei Forward Integration Schritte 1.-7.
- Im Falle des Gated Check-In überprüfen, ob der Build erfolgreich war und der Check-In-Lock entfernt wurde.
Es ist sinnvoll, diese Merges regelmäßig, mehrfach innerhalb einer Iteration durchzuführen, um nicht am Ende größere Überraschungen bei der Integration zu erleben. Entweder wird jeder erfolgreiche CI-Build gemergt oder man legt sich auch ein festes Zeitintervall fest – zum Beispiel wird alle 2 Tage der letzte erfolgreiche CI-Build gemergt. Ziel dieser Strategie ist es, die Branches nicht zu lange auseinanderdriften zu lassen. Je größer die Differenz im Sinne der Changesets zwischen zwei Branches, desto komplizierter und aufwändiger der Merge.
Happy Merging!