Forky

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

Visual Studio 2019 | Visual Studio 2022

Forky úložiště Git jsou užitečné, když uživatelé chtějí provádět experimentální, rizikové nebo důvěrné změny základu kódu, ale tyto změny je potřeba izolovat od základu kódu v původním úložišti. Nový fork je v podstatě klon původního úložiště vloženého do nového vzdáleného úložiště. Fork je nezávislý na původním úložišti a je úplná kopie, pokud nezadáte jednu větev.

Jako nezávislá kopie se změny provedené ve forku, například přidání potvrzení nebo větví, nesdílí s původním úložištěm. Pokud chcete sloučit změny základu kódu do původního úložiště, musíte vytvořit žádost o přijetí změn(PR), abyste mohli požádat o kontrolu a schválení těchto změn.

Proces forku nepřenese žádná oprávnění, zásady ani kanály buildu z původního úložiště do forku.

Tento článek se zabývá prací se forky v úložištích Git Azure Repos a obsahuje odkazy na obsah GitHubu, který popisuje, jak spravovat forky v úložištích GitHub.

V tomto článku získáte informace o těchto tématech:

  • Sdílení kódu mezi forky
  • Volba mezi větvemi a forky
  • Povolení forků úložiště
  • Vytvoření forku
  • Místní klonování forku
  • Nasdílení místních změn do forku
  • Vytvoření a dokončení žádosti o přijetí změn
  • Synchronizace forku

Požadavky pro přístup k Azure Repos

  • Úložiště musí být povolená v nastavení projektu Azure DevOps. Pokud se centrum Repos a přidružené stránky nezobrazují, přečtěte si téma Zapnutí nebo vypnutí služby Azure DevOps a opětovné povolení úložišť.

  • Pokud chcete zobrazit kód v soukromých projektech, musíte být členem projektu Azure DevOps s úrovní základního přístupu nebo vyšší. U veřejných projektů můžou kód zobrazit všichni.

  • Pokud chcete klonovat nebo přispívat do kódu pro soukromý projekt, musíte být členem skupiny zabezpečení Přispěvatelé nebo mít odpovídající sadu oprávnění. U veřejných projektů může každý klonovat a přispívat kódem. Další informace najdete v tématu Co je veřejný projekt?

    Poznámka:

    U veřejných projektů mají uživatelé udělený přístup účastníka k Azure Repos plný přístup.

  • Úložiště musí být povolená v nastavení projektu Azure DevOps. Pokud se centrum Repos a přidružené stránky nezobrazují, přečtěte si téma Zapnutí nebo vypnutí služby Azure DevOps a opětovné povolení úložišť.

  • Pokud chcete zobrazit kód, musíte být členem projektu Azure DevOps se základním přístupem nebo novějším. Pokud nejste členem projektu, budete přidáni.

  • Pokud chcete klonovat nebo přispívat do kódu, musíte být členem skupiny zabezpečení Přispěvatelé nebo mít odpovídající oprávnění v projektu, který chcete změnit.

Sdílení kódu mezi forky

Původní úložiště se často označuje jako upstreamové úložiště. Žádosti o přijetí změn můžete vytvořit tak, aby slučovaly změny v obou směrech: z forku do upstreamu nebo z upstreamu do forku. Nejběžnějším směrem je z forku do upstreamu. Oprávnění, zásady, sestavení a pracovní položky cílového úložiště se použijí pro žádost o přijetí změn.

Volba mezi větvemi a forky

U malého týmu 2 až 5 vývojářů nemusí být pracovní postup forku nutný, protože každý může pracovat ve větvích funkcí a zásadách větví, může chránit výchozí větev. Pokud ale váš tým toto uspořádání rozšíří a přerostne, může přejít na pracovní postup forku.

Pokud má vaše úložiště velký počet příležitostných nebo občasných potvrzení, jako je open source projekt, doporučujeme pracovní postup forku. Oprávnění k přímému potvrzení do vašeho původního úložiště by obvykle měli mít jenom základní přispěvatelé vašeho projektu. Ostatní spolupracovníci by měli použít pracovní postup pro vytváření forku k izolaci navrhovaných změn, dokud nebudou mít základní přispěvatelé možnost zkontrolovat svou práci.

Povolení forků úložiště

Pokud chcete povolit forky pro úložiště Git v Azure Repos, přečtěte si téma Povolení forků.

Pokud chcete povolit forky pro úložiště GitHub, přečtěte si téma Správa zásad forku pro vaši organizaci.

Pracovní postup forku

Pracovní postup forku se skládá z pěti kroků popsaných v následujících částech.

  1. Vytvoření forku
  2. Místní klonování forku
  3. Nasdílení místních změn do forku
  4. Vytvoření a dokončení žádosti o přijetí změn
  5. Synchronizace forku

Vytvoření forku

Následující kroky popisují, jak vytvořit fork úložiště Git pro Azure Repos.

Poznámka:

Pokud chcete vytvořit fork úložiště v projektu Azure DevOps, musíte mít pro tento projekt oprávnění k vytvoření úložiště . Vlastníci úložiště by měli zvážit vytvoření vyhrazeného projektu forků a přiřazení oprávnění k vytvoření úložiště všem přispěvatelům. Další informace o nastavení oprávnění najdete v tématu Nastavení oprávnění úložiště Git.

  1. Ve webovém prohlížeči přejděte do úložiště Git Azure Repos, které chcete vytvořit fork. Vyberte Soubory úložiště > a potom v nabídce se třemi tečky zvolte Fork a otevřete tak dialogové okno Fork.

    Snímek obrazovky s položkou nabídky Fork v nabídce Další akce na stránce Soubory úložiště v Azure Repos

  2. V dialogovém okně Fork pojmenujte forkované úložiště, zvolte projekt, ve kterém chcete vytvořit fork, vyberte větve, které chcete zahrnout do forku, a pak zvolte Fork. Můžete určit, jestli fork bude obsahovat všechny větve, nebo jenom výchozí větev. Pokud úložiště obsahuje několik větví tématu, zvažte zahrnutí pouze výchozí větve do forku.

    Snímek obrazovky s dialogovým oknem Fork na stránce Soubory úložiště v Azure Repos

Informace o tom, jak vytvořit fork úložiště GitHub, najdete v tématu Vytvoření forku úložiště.

Místní klonování forku

Po vytvoření forku úložiště naklonujte svůj fork a vytvořte místní kopii ve složce na počítači. Můžete klonovat z příkazového řádku nebo pomocí integrovaného vývojového prostředí, jako je Visual Studio. Další informace o klonování úložiště najdete v tématu Klonování existujícího úložiště Git.

Při klonování vzdáleného úložiště git přiřadí alias origin jako zkratku pro adresu URL vzdáleného úložiště, které jste naklonovali. Pro usnadnění můžete přidat další alias pojmenovaný upstream pro úložiště, ze kterého jste rozvětvili, což se označuje jako nadřazené úložiště. Následující kroky popisují, jak přidat upstream alias.

Tip

Pro usnadnění přístupu můžete místo odpovídajících adres URL v příkazech Gitu používat origin tyto aliasy a upstream aliasy.

Pokud chcete přidat upstream alias v sadě Visual Studio, postupujte takto:

  1. V řádku nabídek zvolte Možnosti nástroje > a otevřete okno Možnosti. Vyberte úložiště Git správy zdrojového kódu > Nastavení > vzdálených zařízení a pak zvolte Přidat, aby se otevřelo dialogové okno Přidat vzdálené.

    Snímek obrazovky s tlačítkem Přidat v podokně Vzdálená úložiště Git Nastavení podnabídku nabídky Správa zdrojového kódu v sadě Visual Studio 2019

  2. V dialogovém okně Přidat vzdálený přidejte nový vzdálený název upstream a zadejte adresu URL klonu Gitu úložiště, které jste rozvětvili. Pak zvolte Uložit.

    Snímek obrazovky s dialogovým oknem Přidat vzdálený v sadě Visual Studio 2019

Nasdílení místních změn do forku

Při vytváření forku vytvoříte osobní a nezávislou kopii vzdáleného úložiště. Takže vám nic nebrání v práci přímo ve main větvi místního klonu a následnému nasdílení této práce do main větve vašeho forku. Obecně je ale lepší používat větve funkcí pro vaši práci. Pomocí větví funkcí:

  • Současně můžete udržovat více nezávislých pracovníchstreamů.

  • Ostatním usnadníte pochopení práce, kterou sdílíte, protože tato práce je uspořádaná do různých pracovních proudů podle větví.

Typický pracovní postup Gitu zahrnuje tyto kroky:

  1. Vytvořte místní funkci nebo větev pro opravu chyb.

  2. Proveďte změny v nové větvi a potvrďte svou práci. Lidé obvykle při práci na funkci nebo opravě chyb dělají několik potvrzení.

  3. Nasdílejte větev pro opravu chyb nebo funkci do forku. Váš fork má alias origin.

Informace o tom, jak nasdílit změny, najdete v tématu Sdílení kódu s nabízenými oznámeními.

Vytvoření a dokončení žádosti o přijetí změn

Pokud chcete v Azure Repos sloučit do původního úložiště změny, které jste odeslali do forku, můžete:

  1. Vytvořte žádost o přijetí změn a požádejte o revizi a schválení změn. Když otevřete žádost o přijetí změn, nastavte zdrojovou větev žádosti o přijetí změn na funkci nebo větev oprava chyby ve forku. Cílová větev žádosti o přijetí změn je obvykle main větev úložiště, které jste rozvětvili. Toto úložiště se označuje jako upstreamové úložiště a má alias upstream.

    Následující snímek obrazovky ukazuje zdrojové úložiště a větev a cílové úložiště a větev žádosti o přijetí změn vytvořené v Azure Repos.

    Snímek obrazovky s možnostmi zdroje žádosti o přijetí změn a cílové větve v Azure Repos

    Další informace o tom, jak vytvořit žádost o přijetí změn pomocí prohlížeče, sady Visual Studio nebo Azure DevOps CLI, najdete v tématu Vytvoření žádosti o přijetí změn.

    Důležité

    Žádost o přijetí změn může otevřít kdokoli s oprávněním ke čtení v upstreamovém úložišti. Pokud má upstreamové úložiště kanál sestavení žádosti o přijetí změn, který je nakonfigurovaný tak, aby běžel při vytváření žádosti o přijetí změn, sestavení se spustí na změnách zavedených vaší žádostí o přijetí změn.

  2. Aby se vaše žádost o přijetí změn dokončila, musí všichni povinní kontroloři schválit změny žádosti o přijetí změn a musí být splněny všechny zásady cílové větve. Při schválení a dokončení žádosti o přijetí změn se změny ve zdrojové větvi žádosti o přijetí změn sloučí do cílové větve žádosti o přijetí změn.

Informace o tom, jak vytvořit a dokončit žádost o přijetí změn v GitHubu, najdete v tématu Vytvoření žádosti o přijetí změn a sloučení žádosti o přijetí změn.

Synchronizace forku

Po sloučení změn z vašeho forku do cílové větve upstreamového úložiště můžete vyžádat z cílové větve upstreamového úložiště, abyste aktualizovali odpovídající místní větev s vašimi změnami i všemi změnami provedenými jinými přispěvateli. Pak jste připraveni:

  • Vytvořte novou funkci nebo větev pro opravu chyb z aktualizované místní větve.

  • Aktualizujte fork nasdílením z aktualizované místní větve do origin.

Cílová větev upstreamového úložiště je mainobvykle . Pokud přímo neupravujete místní main větev (pracujete ve větvích funkcí), pak stažení z nadřazené větve aktualizuje vaši místní main větev upstream/main bez konfliktů při slučování.

Další kroky