Prozkoumání forku pracovního postupu
Pracovní postup forku se zásadně liší od jiných oblíbených pracovních postupů Gitu.
Místo použití jednoúčelového úložiště na straně serveru jako "centrálního" základu kódu poskytuje každému vývojáři úložiště na straně serveru.
To znamená, že každý přispěvatel má dvě úložiště Git:
- Soukromý místní.
- Veřejná serverová strana.
Pracovní postup forku se nejčastěji používá ve veřejných opensourcových projektech.
Hlavní výhodou pracovního postupu vytváření forků je to, že příspěvky je možné integrovat, aniž by museli všichni odesílat do jednoho centrálního úložiště.
Vývojáři nasdílí oznámení do úložišť na straně serveru a do oficiálního úložiště můžou odesílat jenom správci projektu.
Umožňuje správci přijmout potvrzení od libovolného vývojáře, aniž by jim dal písemný přístup k oficiálnímu základu kódu.
Pracovní postup pro vytváření forků bude obvykle určený ke sloučení do původního úložiště správce projektu.
Výsledkem je distribuovaný pracovní postup, který poskytuje flexibilní způsob, jak pro velké organické týmy (včetně nedůvěryhodných třetích stran) bezpečně spolupracovat.
Díky tomu je také ideální pracovní postup pro opensourcové projekty.
Jak to funguje
Stejně jako v ostatních pracovních postupech Gitu začíná pracovní postup vytváření forků oficiálním veřejným úložištěm uloženým na serveru.
Ale když chce nový vývojář začít pracovat na projektu, nenaklonuje přímo oficiální úložiště.
Místo toho vytvoří fork oficiálního úložiště a vytvoří jeho kopii na serveru.
Tato nová kopie slouží jako své osobní veřejné úložiště – do něj ostatní vývojáři nebudou moct odesílat změny, ale můžou z ní načíst změny (uvidíme, proč je to potřeba za chvíli).
Po vytvoření kopie na straně serveru vytvoří vývojář klon Gitu, který získá jeho kopii na místní počítač.
Slouží jako privátní vývojové prostředí stejně jako v ostatních pracovních postupech.
Až budou připravení publikovat místní potvrzení, nasdílí potvrzení do svého veřejného úložiště , ne do oficiálního.
Pak vytvoří žádost o přijetí změn s hlavním úložištěm, které správci projektu umožní zjistit, že je aktualizace připravená k integraci.
Žádost o přijetí změn slouží také jako praktické diskuzní vlákno, pokud dochází k problémům s kódem přispívání.
Následuje podrobný příklad tohoto pracovního postupu:
- Vývojář 'forks' oficiální úložiště na straně serveru. Vytvoří kopii na straně serveru.
- Nová kopie na straně serveru se naklonuje do místního systému.
- Do místního klonu se přidá vzdálená cesta Gitu pro oficiální úložiště.
- Vytvoří se nová místní větev funkcí.
- Vývojář provede změny v nové větvi.
- Pro změny se vytvoří nová potvrzení.
- Větev se odešle do kopie na straně serveru vývojáře.
- Vývojář otevře žádost o přijetí změn z nové větve do "oficiálního" úložiště.
- Žádost o přijetí změn se schválí ke sloučení a je sloučena do původního úložiště na straně serveru.
Integrace funkce do oficiálního základu kódu:
- Správce načte změny přispěvatele do místního úložiště.
- Zkontroluje, jestli projekt neruší.
- Sloučí ji do místní hlavní větve.
- Odešle hlavní větev do oficiálního úložiště na serveru.
Příspěvek je teď součástí projektu a ostatní vývojáři by si měli vyžádat z oficiálního úložiště synchronizaci místních úložišť.
Je nezbytné pochopit, že pojem "oficiálního" úložiště v pracovním postupu forku je pouze konvence.
Jediná věc, která dělá oficiální úložiště, takže oficiální je, že se jedná o úložiště správce projektu.
Vytváření forků vs. klonování
Je důležité si uvědomit, že "forked" úložiště a "forking" nejsou speciální operace.
Forked repositories are created using the standard git clone command. Forked repositories are generally "server-side clones" managed and host by a host by a git service provider such as Azure Repos.
Neexistuje žádný jedinečný příkaz Gitu k vytvoření forku úložišť.
Operace klonování je v podstatě kopií úložiště a jeho historie.