Sloučení strategií a squash merge
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Po dokončení žádosti o přijetí změn sloučíte větev tématu do výchozí větve, obvykle main. Toto sloučení přidá potvrzení větve tématu do hlavní větve a vytvoří potvrzení sloučení, které sloučí všechny konflikty mezi výchozí a větví tématu. Komentáře a diskuze v žádosti o přijetí změn poskytují další kontext pro změny provedené ve větvi tématu.
Historie potvrzení ve vaší main větvi (nebo jiné výchozí větvi) se neřídí přímým řádkem, protože související historie větví tématu. S tím, jak se projekt zvětšuje, roste počet větví témat, na které současně pracovalo, což ztěžuje sledování historie výchozích větví.
Výchozí větev představuje přesnou reprezentaci historie jednotlivých větví témat, ale je obtížné zodpovědět širší otázky týkající se vývoje projektu.
Squash merge
Sloučení squash je možnost sloučení, která umožňuje zhuštět historii gitu větví témat při dokončení žádosti o přijetí změn. Místo každého potvrzení větve tématu, které se přidává do historie výchozí větve, přidá sloučení squash všechny změny souboru do jediného nového potvrzení ve výchozí větvi. Potvrzení squash merge nemá odkaz na větev tématu, vytvoří nové potvrzení , které obsahuje všechny změny z větve tématu. Kromě toho doporučujeme odstranit větev tématu, aby nedošlo k nejasnostem.
Jednoduchý způsob, jak si to představit, je, že squash merge vám poskytne jen změny souboru a pravidelné sloučení vám poskytne změny souboru a historii potvrzení.
Jak je squash slučování užitečné?
Squash slučování udržuje výchozí historie větví přehledné a snadno sledovatelné, aniž by se vyžadovaly změny pracovního postupu ve vašem týmu. Přispěvatelé do větve tématu fungují tak, jak chtějí, a výchozí větve udržují lineární historii pomocí sloučení squashů. Historie main potvrzení větve aktualizované pomocí squash merges má jedno potvrzení pro každou sloučenou větev. Tuto historii můžete procházet a zjistit přesně, kdy byla práce hotová.
Důležité informace při slučování squashů
Sloučení squashe zkondenzuje historii změn ve vaší výchozí větvi, takže je důležité spolupracovat s týmem, abyste se rozhodli, kdy byste měli sloučení squashů nebo kdy chcete zachovat úplnou historii potvrzení větve tématu. Při slučování squashů je vhodné odstranit zdrojovou větev. Odstranění zdrojové větve zabraňuje nejasnostem, protože samotná větev tématu neobsahuje sloučení do výchozí větve.
Dokončení žádostí o přijetí změn pomocí squash merge
Při dokončování žádosti o přijetí změn v Azure Repos se můžete rozhodnout hromadnou korespondenci.
V dialogovém okně Dokončit žádost o přijetí změn zvolte squash commit v části Typ sloučení, aby se větev tématu sloučila.
Více základů sloučení
Karta Soubory v žádosti o přijetí změn detekuje rozdíly porovnáním na třech stranách. Algoritmus bere v úvahu poslední potvrzení v cílové větvi, poslední potvrzení ve zdrojové větvi a jejich společný základ sloučení (tj. nejlepší společný nadřazený prvek). Algoritmus je rychlá, nákladově efektivní a spolehlivá metoda detekce změn. V některých případech je bohužel více než jedna skutečná základna. Ve většině úložišť je tato situace vzácná, ale ve velkých úložištích s mnoha aktivními uživateli může být běžné. Pokud existuje více základů sloučení mezi větvemi, můžete zkontrolovat ručně. Provedete to spuštěním git merge-base --all feature master příkazu. Azure DevOps detekuje existenci více základů sloučení pro každou žádost o přijetí změn. Po zjištění se v Azure DevOps zobrazí zpráva "Zjistilo se několik základů sloučení. Zobrazený seznam potvrzení může být neúplný pro žádost o přijetí změn. Zatímco Azure DevOps spouští detekci více základen sloučení, nekontroluje, jestli se potenciální základ sloučení už sloučil nebo ne. Taková kontrola je provedena git merge-base. To je důvod, proč Azure DevOps může zprávu zobrazit i v případě, že git merge-base sestavuje jenom jednu základnu sloučení.
Poznámka:
Pokud jste během kontroly žádosti o přijetí změn ztratili změny, ujistěte se, že hlavní příčinou není více základů sloučení.
Azure DevOps detekuje následující scénáře jako několik základen (základy sloučení jsou označené číslem 1 a 2):
- Křížové sloučení (označované také jako křížové křížky) mezi různými větvemi (hlášenými Azure DevOps a také
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Sloučení jedné větve s dalšími dvěma (hlášenými Azure DevOps, ale ne
git merge-baseodstraněním základu sloučení 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Zpracování aftermaths of main branch reverts, např. změna potvrzení sloučení
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- Aktivní opakované použití větví funkcí
- Jiné neintuitivní a konvolutované manipulace s reverty, třešněmi a slučovacími funkcemi
Detekce více základu sloučení je součástí povědomí o zabezpečení. Pokud existuje více základů sloučení, algoritmus rozdílu souborů pro uživatelské rozhraní nemusí správně rozpoznat změny souborů v závislosti na tom, kterou základ sloučení zvolí. Pokud soubory v žádosti o přijetí změn mají různé verze mezi základy sloučení, dojde k upozornění na více základních sloučení.
Další podrobnosti najdete v oficiální dokumentaci gitu.
Potenciální bezpečnostní rizika při slučování z více základen
- Uživatel se zlými úmysly může zneužít algoritmus uživatelského rozhraní k potvrzení škodlivých změn, které nejsou v žádosti o přijetí změn.
- Pokud se změny navržené v žádosti o přijetí změn už nacházejí v cílové větvi, zobrazí se na kartě Soubory , ale nemusí aktivovat zásady větve, které jsou namapované na změny složky.
- V žádosti o přijetí změn nemusí existovat dvě sady změn stejných souborů z více základen sloučení. V takovém případě by mohly vzniknout zrádné logické mezery.
Řešení problému s více základy sloučení
Více základen sloučení nemusí být nutně špatné, ale měli byste pečlivě zkontrolovat, jestli je všechno v pořádku. Pokud se chcete zbavit více základen sloučení, spojte větve s jedním společným nadřazeným objektem tak, že větev znovu zbavíte podle cíle nebo sloučíte cíl do větve. Tyto akce se zbaví upozornění a pomohou vám zkontrolovat, jestli jsou skutečné změny v pořádku.
Jedním z přístupů je obnovitelné resetování a uložení průběhu před opětovnou úpravou nebo sloučením. Pak můžete vytvořit novou větev nebo znovu vytvořit prázdnou větev a použít změny z jasného bodu. Tento proces může vyžadovat vynucené nasdílení změn do vzdáleného umístění, pokud už tam jsou vaše změny.
Jak se vyhnout problému s více základy sloučení
Tady jsou obecné tipy, jak se vyhnout problému s více základními funkcemi sloučení:
- Při přípravě žádosti o přijetí změn vytvořte větve funkcí z nejnovějších verzí hlavní nebo vydané větve.
- Vyhněte se vytváření větví, které nepocházejí přímo ze stabilních větví úložiště, pokud není potřeba.
Co dělat, když se znovu zobrazí problém s více základy sloučení
Ve velkých úložišťch s mnoha aktivními přispěvateli může být tento problém obzvláště nevhodný. I když se pomocí sloučení zbavíte více základen, situace se může znovu objevit. Pokud někdo zavře dlouhou žádost o přijetí změn, může situaci vytvořit znovu. I když jsou spuštěné zásady sestavení a testy, nemáte žádné prostředky k dokončení žádosti o přijetí změn. Může vám pomoct resetování a spuštění nové větve. Pokud se nic nezmění, vaše změny budou pravděpodobně jasné, i když se situace opakuje.