Co jsou konflikty při sloučení?
Tady probereme, jak řešení konfliktů při sloučení pomáhá vývojářům dosáhnout nejlepšího výsledku ze dvou překrývajících se zdrojů.
Pracovní postup GitHubu
Kromě platformy pro společný vývoj softwaru nabízí GitHub také předepsaný pracovní postup, který je navržený pro optimální využití všech jeho různých funkcí. I když tato lekce konkrétně popisuje konflikty při slučování, doporučujeme, abyste si nejprve prostudovali principy toku GitHubu.
Slučování větví
Představte si scénář, ve kterém vývojář vytvoří větev, kterou pojmenuje feature-branch, založí ji na větvi main a vytvoří dvě potvrzení. Během této práce někdo jiný sloučí do větve main nesouvisející žádost o přijetí změn. Co se stane, když se vývojář pokusí sloučit větev feature-branch zpět do větve main?
Odpověď zní: záleží na okolnostech.
I když feature-branch byl vytvořen z main, nebyl založen na samotné větvi. Ve skutečnosti byla založena spíše na potvrzení HEAD větve main v daném okamžiku. Není si vědom všech potvrzení, na která se od té doby použila main . Potvrzení, která aktuálně sleduje, se nemusí nutně skládat do aktuálního stavu větve bez přepsání nedávných změn.
Pokud se zjistí, že feature-branch se potvrzení nepřekrývají s paralelními potvrzeními provedenými main od vytvoření větve, pak se žádné problémy nedají. Je možné přidat nové soubory. Nedotčené soubory je možné odstranit. Řádky kódu, které byly změněny ve větvi main, můžou být změněny i ve větvi feature-branch, pokud je nezměnily souběžné práce od vytvoření větve feature-branch.
Co když obě sady potvrzení obsahují změny stejných řádků kódu? Takový pokus o sloučení by nebyl úspěšný kvůli konfliktu sloučení.
Co jsou konflikty při sloučení?
Konflikty při slučování vznikají, když se vývojář pokusí sloučit změny, které by omylem přepsaly souběžně prováděné změny. Nezáleží na tom, jako jsou tyto další změny sloučeny do základní větve. Git automaticky nepřepíše jednu sadu změn ve prospěch jiné. Místo toho je odkazuje na osobu, která se pokouší sloučit, aby je mohl vyřešit ve své porovnávací větvi, než se pokusí znovu sloučit.
Řešení konfliktů při sloučení
Aby vám pomohl vyřešit konflikty při slučování, GitHub vygeneruje dočasný hybridní soubor, který zahrnuje rozdíly mezi jednotlivými větvemi. Text ze srovnávací větve, který je oddělený řadou rovnítek (=======), se obvykle zobrazí nad základní větví.
Pokud jde o drobné změny, můžete soubor upravit přímo v tomto zobrazení. Pokud se rozhodnete zachovat, konečný výsledek se potvrdí do porovnávané větve. Pokud je sloučení více zapojené, můžete na něm raději pracovat pomocí jiných vývojových nástrojů. V každém případě před potvrzením nezapomeňte z kódu odebrat všechny značky větví. Pokud při potvrzení řešení konfliktů zapomenete tyto značky odebrat, zůstanou v souboru a nejsou zakomentované.
Poznámka:
Tato lekce se zabývá řešením konfliktů při sloučení v kontextu prohlížeče. Existují ale také jiné vývojové platformy, třeba Visual Studio, které nabízejí integrované prostředí pro řešení konfliktů při sloučení.
Po vyřešení všech konfliktů při slučování ve vaší větvi můžete sloučení zopakovat.
Jak předcházet konfliktům při slučování
Některé konflikty při slučování jsou nevyhnutelné. Při každém sloučení můžou vzniknout konflikty s jinými žádostmi o přijetí změn, které čekají na schválení. Jeden z účinných způsobů, jak zmenšit složitost konfliktů při slučování, spočívá v častém přijímání změn do vaší větve.
Včasné a časté přijímání změn
Příkaz git pull stáhne všechny potvrzení základní větve, které ještě nejsou použity pro vaši aktuální větev. Koncepčně se podobá příkazu Získat nejnovější verzi, který mnoho systémů pro správu verzí používá, abyste mohli aktualizovat místní kód na nejnovější verzi. Když stáhnete aktualizace pro svoji větev, sloučíte všechny změny, ke kterým došlo od vytvoření větve (nebo posledního načtení).
Stažení aktualizací do větve může vést ke konfliktům při slučování, ale to je v pořádku. Získáte je později a tím, že je získáte dříve, jsou často jednodušší řešit.
Přijetí aktualizací – kromě snížení dopadu konfliktů při sloučení – také umožňuje během vaší práce integrovat potvrzené změny do vaší větve. Tento postup umožňuje dříve se vyhnout možným problémům. V jiných souborech může například dojít ke změnám definice třídy, které způsobí, že se váš kód už nebude kompilovat. Tato změna by při pozdějším sloučení nezpůsobila konflikt při sloučení, ale při prvním testování by se sestavení přerušilo. Proto se jako osvědčený postup doporučuje často přijímat aktualizace, aby byla vaše větev co nejpodobnější základní větvi.
Úklid historie příkazem git rebase
Příkaz git rebase (nebo git pull --rebase) přepíše historii větve, abyste jako její základ mohli použít aktuální potvrzení HEAD základní větve. Jinými slovy, vaše větev se aktualizuje tak, aby se chovala tak, jako by byla větvena pouze z aktuálního stavu základní větve. Tato změna základu znamená, že všechny změny se porovnávají s nejnovějším stavem základní větve, a ne s původním potvrzením, ze kterého jste původně větveli. Opětovné použití může usnadnit sledování historie po konečném sloučení, protože potvrzení budou následovat po předchozích paralelních potvrzeních lineárním způsobem. Jako vhodný postup se doporučuje přenést změny do své větve těsně před upstreamovým sloučením.
Přečtěte si další informace o příkazu Git rebase a o řešení konfliktů při sloučení po příkazu Git rebase.