Git-arbetsflöden som minskar merge-konflikter

Snabbguide: trunk-based development

Små, täta commits mot huvudgrenen med feature flags i stället för långlivade grenar minskar konflikterna dramatiskt. Nyckeln är automatiserade tester som vågar säga nej, och en kultur där trasig main åtgärdas före allt annat.

Börja med att korta ner era pull requests – under 400 rader ändrad kod granskas bevisligen bättre. Kombinera med dagliga integrationer så försvinner de flesta merge-mardrömmarna av sig själva.

Feature flags är mönstrets bärande bjälke och förtjänar egen disciplin. Ofärdig kod kan mergas till main bakom en avstängd flagga, vilket skiljer driftsättning från lansering – koden åker ut kontinuerligt, funktionen slås på när den är redo. Men flaggor åldras dåligt: sätt ett utgångsdatum på varje flagga och städa regelbundet, annars byter ni merge-konflikter mot ett träsk av döda kodvägar.

För den som inte kan gå hela vägen till trunk-based finns mellanlägen. Korta feature-grenar – max några dagar – med påtvingad rebase mot main varje morgon fångar konflikterna medan de fortfarande är små. Konflikten som upptäcks efter tre timmar är en irritation; samma konflikt efter tre veckor är en förhandling.

Verktygen kan också bära en del av bördan: merge queues kör om testerna på exakt det som ska landa och eliminerar “grön PR som knäcker main”-fenomenet, medan git rerere låter Git komma ihåg hur du löste en konflikt sist och återanvända lösningen.

Den djupare sanningen är dock organisatorisk: täta konflikter i samma filer är en signal om att teamgränser och modulgränser inte matchar. Ibland är den bästa merge-strategin en arkitektur där två team inte behöver röra samma kod.