Prozkoumání modelu větve Gitu pro průběžné doručování

Dokončeno

Účelem psaní kódu je dodat vylepšení softwaru.

Model větvení, který zavádí příliš mnoho režijních nákladů na procesy, nepomáhá zvýšit rychlost získávání změn zákazníkům – vývoj modelu větvení vám dává dostatek odsazení, aby se neposílaly změny nízké kvality. Zároveň ale nezavádí příliš mnoho procesů, které by vás zpomalily.

Internet je plný strategií větvení pro Git; i když není žádná správná nebo špatná, ideální strategie větvení funguje pro váš tým!

Naučíte se vždy používat kombinaci větví funkcí a žádostí o přijetí změn, abyste měli hlavní větev připravenou k odeslání.

Příprava

Probereme principy toho, co navrhujeme:

• Hlavní větev:

  • Hlavní větev je jediným způsobem, jak uvolnit cokoli do produkčního prostředí.
  • Hlavní větev by měla být vždy ve stavu připraveno k vydání.
  • Chraňte hlavní větev pomocí zásad větví.
  • Všechny změny v hlavní větvi procházejí jenom žádostmi o přijetí změn.
  • Označte všechny verze v hlavní větvi značkami Gitu.

• Větev funkce:

  • Větve funkcí používejte pro všechny nové funkce a opravy chyb.
  • Pomocí příznaků funkcí můžete spravovat větve dlouhotrvajících funkcí.
  • Změny z větví funkcí na hlavní tok pouze prostřednictvím žádostí o přijetí změn.
  • Pojmenujte funkci tak, aby odrážela její účel.

• Větev vydané verze:

  • Vytvořte vyhrazenou větev vydané verze ze stabilní větve funkcí pro přípravu na nasazení.
  • Ujistěte se, že větev vydané verze prochází důkladným testováním a stabilizací.
  • Před nasazením použijte opravy chyb a potřebné změny ve větvi vydané verze.
  • Označte vydané verze ve větvi vydané verze, abyste označili významné milníky.

  Seznam větví:

  bugfix/description
  features/feature-name
  features/feature-area/feature-name
  hotfix/description
  users/username/description
  users/username/workitem
  

• Žádosti o přijetí změn:

  • Zkontrolujte a sloučíte kód s žádostmi o přijetí změn.
  • Automatizujte, co kontrolujete a ověřujete jako součást žádostí o přijetí změn.
  • Sleduje dobu trvání dokončení žádosti o přijetí změn a nastaví cíle, aby se zkrátila doba trvání.

MyWebApp vytvořený v předchozích cvičeních použijeme. Viz Popis práce s Gitem místně.

V tomto receptu budeme používat tři trendy rozšíření z marketplace:

• Azure CLI: je rozhraní příkazového řádku pro Azure.
• Azure DevOps CLI: Jedná se o rozšíření Azure CLI pro práci s Azure DevOps a Azure DevOps Serverem navrženým tak, aby se bezproblémově integroval s Gitem, kanály CI a agilními nástroji. Pomocí Azure DevOps CLI můžete přispívat do svých projektů bez opuštění příkazového řádku. Rozhraní příkazového řádku běží ve Windows, Linuxu a Macu.
• Konflikt sloučení žádostí o přijetí změn Git: Toto opensourcové rozšíření vytvořené Microsoft DevLabs umožňuje zkontrolovat a vyřešit konflikty při sloučení žádostí o přijetí změn na webu. Všechny konflikty s cílovou větví je potřeba vyřešit, než se žádost o přijetí změn Git dokončí. S tímto rozšířením můžete tyto konflikty na webu vyřešit jako součást sloučení žádostí o přijetí změn místo toho, abyste prováděli sloučení a vyřešili konflikty v místním klonu.

Azure DevOps CLI podporuje vrácení výsledků dotazu ve formátu JSON, JSONC, YAML, YAMLC, tabulce, TSV a žádné. Předvolby můžete nakonfigurovat pomocí příkazu configure.

Jak to udělat

Důležité

Musíte mít projekt vytvořený v prvním studijním programu: Popište práci s Gitem místně.

1. Po naklonování hlavní větve do místního úložiště vytvořte novou větev funkcí myFeature-1:

   myWebApp

   git checkout -b feature/myFeature-1
   

   Výstup:

   Přepnul se na novou větev feature/myFeature-1.

2. Spuštěním příkazu Git branch zobrazte všechny větve. Větev, která se zobrazuje s hvězdičkou, je aktuálně rezervovaná větev:

   myWebApp

   git branch
   

   Výstup:

   feature/myFeature-1

   main

3. Proveďte změnu souboru Program.cs ve větvi feature/myFeature-1:

   myWebApp

   notepad Program.cs
   

4. Připravte změny a potvrďte místně a pak publikujte větev do vzdáleného umístění:

   myWebApp

   git status
   

   Výstup:

   Ve větvi feature /myFeature-1 Změny nejsou fázované pro potvrzení: (použijte příkaz "git add <file>..." k aktualizaci toho, co se potvrdí) (použijte "git checkout -- <file>..." zahození změn v pracovním adresáři) změněno: Program.cs.

   myWebApp

   git add .
   git commit -m "Feature 1 added to Program.cs"
   

   Výstup:

   [feature/myFeature-1 70f67b2] funkce 1 přidaná do program.cs 1 souboru, 1 vložení(+).

   myWebApp

   git push -u origin feature/myFeature-1
   

   Výstup:

   Rozdílová komprese s využitím až 8 vláken Komprimace objektů: 100 % (3/3), hotovo. Zápis objektů: 100 % (3/3), 348 bajtů | 348.00 KiB/s, hotovo. Celkem 3 (delta 2), znovu použité vzdálené 0 (delta 0): Analýza objektů... (3/3) (10 ms) remote: Ukládání souboru packfile... done (44 ms) remote: Ukládání indexu... done (62 ms) To https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

   Vzdálené zobrazení historie změn:

   

5. Nakonfigurujte Rozhraní příkazového řádku Azure DevOps pro vaši organizaci a projekt. Nahraďte název organizace a projektu:

   az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
   

6. Vytvořte novou žádost o přijetí změn (pomocí Azure DevOps CLI) a zkontrolujte změny ve větvi feature-1:

   az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
   --description "#Merge feature-1 to main" `
   --source-branch feature/myFeature-1 --target-branch main `
   --repository myWebApp --open
   

   Při vyvolání žádosti o přijetí změn ji otevřete ve webovém prohlížeči po vytvoření přepínače --open. Přepínač --deletesource-branch lze použít k odstranění větve po dokončení žádosti o přijetí změn. Zvažte také použití příkazu --auto-complete k automatickému dokončení, když byly splněny všechny zásady, a zdrojovou větev je možné sloučit do cílové větve.

   Poznámka:

   Další informace o příkazu az repos pr create parameter naleznete v tématu Vytvoření žádosti o přijetí změn ke kontrole a sloučení kódu.

   Tým společně zkontroluje změny kódu a schválí žádost o přijetí změn:

   

   Hlavní je připravená k vydání. Tým označí hlavní větev číslem verze:

   

7. Začněte pracovat na funkci 2. Vytvořte větev na dálku z hlavní větve a proveďte rezervaci místně:

   myWebApp

   git push origin main:refs/heads/feature/myFeature-2
   

   Výstup:

   Celkem 0 (delta 0), znovu použito 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

   myWebApp

   git checkout feature/myFeature-2
   

   Výstup:

   Přepnuli jsme na novou větev feature/myFeature-2 Branch feature/myFeature-2 nastavenou tak, aby sledovala funkci vzdálené větve /myFeature-2 z původu.

8. Upravte Program.cs změnou stejného řádku komentáře v kódu změněným v funkci 1.

   public class Program
   {
       // Editing the same line (file from feature-2 branch)
       public static void Main(string[] args)
       {
           BuildWebHost(args).Run();
       }
   
       public static IWebHost BuildWebHost(string[] args) =>
           WebHost.CreateDefaultBuilder(args)
               .UseStartup<Startup>()
               .Build();
   

9. Potvrďte změny místně, nasdílejte je do vzdáleného úložiště a potom vytvořte žádost o přijetí změn pro sloučení změn z funkce /myFeature-2 do hlavní větve:

   az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
   --description "#Merge feature-2 to main" `
   --source-branch feature/myFeature-2 --target-branch main `
   --repository myWebApp --open
   

   V produkčním prostředí se v produkčním prostředí hlásí kritická chyba s žádostí o přijetí změn ve verzi feature-1. Pokud chcete problém prošetřit, musíte ladit verzi kódu, která je aktuálně nasazená v produkčním prostředí. Pokud chcete problém prošetřit, vytvořte novou fof větev pomocí značky release_feature1:

   myWebApp

   git checkout -b fof/bug-1 release_feature1
   

   Výstup:

   Přepnul se na novou větev fof/bug-1.

10. Upravte Program.cs změnou stejného řádku kódu, který byl změněn ve verzi feature-1:

    public class Program
    {
        // Editing the same line (file from feature-FOF branch)
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }
    
        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    

11. Připravte a potvrďte změny místně a pak nasdílejte změny do vzdáleného úložiště:

    myWebApp

    git add .
    git commit -m "Adding FOF changes."
    git push -u origin fof/bug-1
    

    Výstup:

    To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.

12. Okamžitě po zavedení změn do produkčního prostředí označte větev fof\bug-1 značkou release_bug-1 a pak vytvořte žádost o přijetí změn pro sloučení změn z fof/bug-1 zpět do hlavní větve:

    az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
    --description "#Merge Bug-1 to main" `
    --source-branch fof/Bug-1 --target-branch main `
    --repository myWebApp --open
    

    V rámci žádosti o přijetí změn se větev odstraní. Pomocí značky ale můžete stále odkazovat na celou historii.

    S řešením kritické chyby se podíváme na žádost o přijetí změn typu feature-2.

    Na stránce větví je zřejmé, že větev feature/myFeature-2 je jedna změna před hlavní větví a dvě změny za hlavní větví:

    

    Pokud jste se pokusili žádost o přijetí změn schválit, zobrazí se chybová zpráva s informací o konfliktu při sloučení:

    

13. Rozšíření řešení konfliktů při sloučení žádostí o přijetí změn Git umožňuje vyřešit konflikty při sloučení přímo v prohlížeči. Přejděte na kartu konflikty a kliknutím na Program.cs konflikty sloučení vyřešíte:

    

    Uživatelské rozhraní umožňuje převzít zdroj, cíl, přidat vlastní změny, zkontrolovat a odeslat sloučení. Při sloučení změn se žádost o přijetí změn dokončí.

V tuto chvíli můžete vytvořit větev vydané verze na základě kritické opravy chyb implementované ve větvi fof/bug-1 a sloučit do hlavní větve. Pomocí příkazu git checkout vytvořte z hlavní větve vyhrazenou větev vydané verze.

git checkout -b release/v1.1 main

Tento příkaz vytvoří novou větev s názvem release/v1.1 na základě hlavní větve.

S dosažením významných milníků během procesu vydávání verzí značky ve větvi vydané verze pomocí značek Git. Značky slouží jako značky označující konkrétní verze softwaru.

git tag -a v1.1 -m "Release version 1.1"

Tento příkaz vytvoří značku s názvem v1.1 pro označení verze 1.1 ve větvi vydané verze.

Jak to funguje

Dozvěděli jsme se, jak model větvení Gitu umožňuje pracovat na funkcích paralelně vytvořením větve pro každou funkci.

Pracovní postup žádosti o přijetí změn umožňuje kontrolovat změny kódu pomocí zásad větve.

Značky Gitu představují skvělý způsob, jak zaznamenávat milníky, jako je verze vydaného kódu; Značky umožňují vytvářet větve ze značek.

Vytvořili jsme větev z předchozí značky vydané verze, abychom opravili kritickou chybu v produkčním prostředí.

Zobrazení větví na webovém portálu usnadňuje identifikaci větví před hlavním serverem. Vynutí také konflikt při slučování, pokud se některé probíhající žádosti o přijetí změn pokusí sloučit na hlavní, aniž by se vyřešily konflikty sloučení.

Model štíhlé větvení umožňuje vytvářet krátkodobé větve a rychleji odesílat změny kvality do produkčního prostředí.