Sdílet prostřednictvím


Použití změn pomocí přenesení změn

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git automaticky udržuje historii vývoje ve větvi propojením každého nového potvrzení s jeho předchůdcem. Když jednu větev sloučíte do druhé, historie se může stát méně jednoduchá. Například sloučení typu no-fast-forward kombinuje rozdílové čáry vývoje vytvořením potvrzení sloučení s několika předchůdci. Naopak rebase Gitu kombinuje rozdílové řádky vývoje bez vytvoření potvrzení sloučení, což vede k jednodušší historii potvrzení, ale ztratí informace o sloučení. Volba typu sloučení je pravděpodobně ovlivněna tím, jestli chcete zachovat záznam sloučení nebo zjednodušit historii potvrzení.

Tento článek popisuje, kdy použít rebase místo hromadného sloučení bez rychlého přeposlání a poskytuje postupy pro následující úlohy:

  • Změna základu místní větve
  • Vynucení nasdílení místní větve po opětovném vytvoření základu
  • Interaktivní rebase pro místní potvrzení squash

Přehled pracovního postupu Gitu najdete v kurzu Gitu pro Azure Repos.

Změna základu místní větve

Rebase Gitu integruje potvrzení ze zdrojové větve do aktuální místní větve (cílová větev). Zdrojová větev zůstane beze změny. Pro porovnání se v následujícím diagramu zobrazuje rebase Gitu a další typy sloučení.

Diagram znázorňující před a po potvrzení při použití rebase Gitu

Git znovu naváže historii potvrzení cílové větve tak, aby obsahoval všechna potvrzení zdrojové větve následované všemi potvrzeními cílové větve od posledního společného potvrzení. Dalším způsobem, jak ji zobrazit, je, že rebase přehrává změny v cílové větvi nad historií zdrojové větve. Git rebase zejména mění sekvenci existujících potvrzení cílové větve, což není případ ostatních strategií sloučení. V předchozím diagramu obsahuje potvrzení K stejné změny jako K, ale má nové ID potvrzení, protože odkazuje zpět na potvrzení E místo jazyka C.

Pokud při změně základu dojde ke konfliktu změny zdrojové větve s cílovou větví, Git vás vyzve k vyřešení konfliktu při sloučení. Konflikty při sloučení můžete vyřešit stejným způsobem jako při slučování při slučování.

Změna základu vs. bez rychlého sloučení

Opětovné sloučení Gitu vede k jednodušší, ale méně přesné historii potvrzení než sloučení bez rychlého přeposlání , jinak označované jako trojcestné nebo skutečné sloučení. Pokud chcete záznam sloučení v historii potvrzení použít bez rychlého sloučení.

Pokud jste jedinou osobou, která pracuje na nějaké funkci nebo větvi opravy chyb, zvažte použití základu, abyste do ní pravidelně integrovali práci s poslední main větví. Tato strategie pomáhá zajistit, abyste měli přehled o nedávné práci ostatních a rychle vyřešili případné konflikty při slučování, které vzniknou. Opětovným obnovením implementujete novou funkci nad nejnovější main práci větve, která pomáhá udržovat historii lineárních potvrzení.

Další informace o opětovném použití Gitu a jejich použití najdete v tématu Rebase vs.

Změna základu a pokynů pro vynucené nabízení

Pokud znovu nasdílíte místní větev, kterou jste nasdíleli, a pak znovu spustíte výchozí příkaz Git Push, nabízení se nezdaří. Výchozí příkaz push gitu použije rychlé sloučení pro integraci místní větve do vzdálené větve. Tento příkaz selže po obnovení základu, protože rebase změní posloupnost existujících potvrzení ve vaší místní cílové větvi, takže už neodpovídá historii jeho vzdáleného protějšku. V tomto scénáři bude vynucené nasdílení změn úspěšné – přepsáním vzdálené větve.

Git rebase a force push jsou výkonné nástroje, ale při rozhodování, jestli je použít, mějte na paměti tyto pokyny:

  • Neodesílejte místní větev, která se nasdílí a sdílí s ostatními, pokud si nejste jistí, že sdílenou větev nepoužívá nikdo. Po obnovení nebude vaše místní větev odpovídat historii jeho vzdáleného protějšku.
  • Vynucujte vložení do vzdálené větve, kterou používají jiní uživatelé, protože jejich místní verze vzdálené větve už nebude odpovídat aktualizované historii vzdálených větví.
  • Váš tým by se měl shodnout na scénářích použití pro obnovení a vynucení nabízení změn.

Tip

Pokud chcete zkontrolovat spolupráci, použijte žádost o přijetí změn ke sloučení nové práce do výchozí větve vzdáleného úložiště.

Postup opětovného vytvoření základu

Visual Studio 2022 poskytuje prostředí pro správu verzí Git pomocí nabídky Git, změn Gitu a kontextových nabídek v Průzkumník řešení. Visual Studio 2019 verze 16.8 také nabízí uživatelské rozhraní Git Team Exploreru. Další informace najdete na kartě Visual Studio 2019 – Team Explorer .

  1. Zvolte Git Manage Branches (Spravovat větve Gitu > ) a otevřete okno úložiště Git.

    Snímek obrazovky s možností Spravovat větve v nabídce Git v sadě Visual Studio

  2. V okně Úložiště Git klikněte pravým tlačítkem na cílovou větev a vyberte Rezervovat.

    Snímek obrazovky s možností Rezervovat v místní nabídce větve v okně úložiště Git v sadě Visual Studio

  3. Klikněte pravým tlačítkem myši na zdrojovou větev a vyberte Znovu naskladněnou <cílovou větev> na <zdrojovou větev>.

    Snímek obrazovky s možností Rebase v místní nabídce větve v okně úložiště Git v sadě Visual Studio

  4. Visual Studio zobrazí potvrzovací zprávu po úspěšném obnovení základu.

    Snímek obrazovky s potvrzovací zprávou o obnovení základu v okně úložiště Git v sadě Visual Studio

    Pokud dojde k zastavení opětovného základu kvůli konfliktům při slučování, Sada Visual Studio vás upozorní. Konflikty můžete vyřešit nebo zrušit základ a vrátit se do stavu předběžného základu.

    Snímek obrazovky se zprávou o konfliktu opětovného základu v okně úložiště Git v sadě Visual Studio

Vynucení nasdílení místní větve po opětovném vytvoření základu

Pokud znovu nasdílíte místní větev, kterou jste nasdíleli dříve, další výchozí nasdílení změn Gitu se nezdaří. Místo toho můžete vynutit nasdílení místní větve, aby přepsala jeho vzdálený protějšek, aby se jejich historie potvrzení shodovala.

Upozorňující

Nikdy nenuťte nasdílení větve, na které pracují ostatní. Další informace naleznete v tématu Změna základu a vynucení pokynů pro nabízení změn.

Pokud chcete vynucené nabízení v sadě Visual Studio vynutit, musíte nejprve povolit možnost vynucení nabízení:

  1. Přejděte na Globální Nastavení Gitu možnosti správy>zdrojového kódu>nástroje.>

  2. Vyberte možnost Povolit nabízení --force-with-zapůjčení.

Příznak nabízeného oznámení --force-with-lease Gitu je bezpečnější než --force příznak, protože nepřepíše vzdálenou větev, která obsahuje potvrzení, která nejsou integrovaná v místní větvi, kterou vynucujete nasdílení změn.

  1. V okně Změny Gitu vyberte tlačítko Push a nasdílejte potvrzení.

    Snímek obrazovky s tlačítkem pro stisknutí šipky nahoru v okně Změny Gitu v sadě Visual Studio

    Nebo můžete v nabídce Git vybrat Možnost Push (Nasdílení změn).

    Snímek obrazovky s možností Nasdílení změn z nabídky Git v sadě Visual Studio

  2. Pokud se výchozí operace vložení z Gitu nezdaří , Visual Studio spustí dialogové okno Git-Push, které selhalo . Zvolte Vynucené nasdílení.

    Snímek obrazovky s dialogovým oknem Git-Push, které selhalo v sadě Visual Studio

  3. Visual Studio zobrazí potvrzovací zprávu po úspěšném nasdílení změn.

    Snímek obrazovky se zprávou potvrzení nabízeného oznámení v sadě Visual Studio

Interaktivní rebase pro místní potvrzení squash

Při práci na nové funkci v místní větvi funkcí obvykle vytvoříte několik potvrzení. Až budete připraveni publikovat novou funkci, můžete tato potvrzení sloučit do jediného potvrzení, aby se zjednodušila historie potvrzení. Interaktivní rebase můžete použít k rozmačkování více potvrzení do jednoho potvrzení.

Visual Studio 2022 nepodporuje interaktivní přebasování. Místo toho použijte příkazový řádek Gitu.

Poznámka:

Uživatelé Azure DevOps můžou sloučením zúžením kondenzovat historii potvrzení větve tématu během žádosti o přijetí změn.

Další kroky