Konflikty při sloučení větví nejsou známkou toho, že tým neumí pracovat s Gitem. Většinou vznikají proto, že se dlouho vyvíjené větve rozejdou příliš daleko a nikdo neřeší integraci průběžně. Pokud se release blíží a najednou se hromadí desítky konfliktů, tým ztrácí hodiny ručním sléváním a odhadem, co vlastně patří do výsledné verze. Řešení není v heroickém úsilí před deadlinem, ale v nastavení pravidel, která konfliktům předcházejí.

Základem je krátkodobé větvení. Feature branch by neměla žít déle než několik dní, maximálně týden. Čím déle větev existuje, tím větší je pravděpodobnost, že se změní soubory, na kterých pracuje někdo jiný. Pomáhá i časté rebasování na hlavní větev nebo merge z mainu do feature branch. Tím se konflikty objevují po jednom a v kontextu, který vývojář ještě pamatuje. Pokud tým používá trunk-based development s malými commity, je situace výrazně klidnější. Praktické postupy pro takové uspořádání najdete v článku o Git workflow pro týmovou spolupráci, kde jsou popsané i strategie pro code review a ochranu hlavní větve.

Před releasem je klíčové zavést freeze na hlavní větvi a vytvořit release branch. Do ní se slévají jen opravy, ne nové funkce. Konflikty se tak řeší v izolovaném prostředí a hlavní vývoj pokračuje dál. Zároveň je dobré mít automatické testy, které po každém merge ověří, že se nic nerozbilo. Ruční kontrola diffů u velkých konfliktů je nespolehlivá a často vede k tomu, že se do kódu vrátí už opravená chyba. Automatizace odhalí problém dřív, než se dostane do produkce.

Nezablokovat tým znamená i to, že se konflikty neřeší na poslední chvíli a že se o nich mluví dopředu. Denní synchronizace, kde každý řekne, na čem pracuje a co plánuje sloučit, snižuje riziko překvapení. Pokud se přesto objeví velký konflikt, je lepší sejít se nad ním ve dvou než ho řešit asynchronně přes komentáře. Release pak proběhne v klidu a tým nemusí zůstávat přesčas.