Git-vertakkingsmodel verkennen voor continue levering

  • 3 minuten

Het doel van het schrijven van code is het verzenden van verbeteringen aan uw software.

Een vertakkingsmodel dat te veel procesoverhead introduceert, helpt niet om de snelheid van het ophalen van wijzigingen aan klanten te verhogen. Het ontwikkelen van een vertakkingsmodel biedt u voldoende opvulling om wijzigingen van slechte kwaliteit niet te verzenden. Maar tegelijkertijd introduceert niet te veel processen om u te vertragen.

Internet zit vol met vertakkingsstrategieën voor Git; Hoewel er geen goed of verkeerd is, werkt een perfecte vertakkingsstrategie voor uw team!

U leert altijd hoe u de combinatie van functievertakkingen en pull-aanvragen gebruikt om een kant-en-klare hoofdvertakking te hebben.

Voorbereiding

Laten we de principes bespreken van wat we voorstellen:

  • De hoofdbranch:

    • De hoofdbranch is de enige manier om iets vrij te geven aan productie.
    • De hoofdvertakking moet altijd de status Gereed voor release hebben.
    • Beveilig de hoofdbranch met vertakkingsbeleid.
    • Wijzigingen in de hoofdbranchstroom alleen via pull-aanvragen.
    • Tag alle releases in de hoofdbranch met Git-tags.

  • De functiebranch:

    • Functievertakkingen gebruiken voor alle nieuwe functies en oplossingen voor fouten.
    • Functievlagmen gebruiken om langlopende functievertakkingen te beheren.
    • Wijzigingen van functietakken naar de belangrijkste stroom alleen door pull-aanvragen.
    • Geef uw functie een naam om het doel ervan weer te geven.

  • De releasebranch:

    • Maak een toegewezen releasebranch van een stabiele functiebranch om de implementatie voor te bereiden.
    • Zorg ervoor dat de releasebranch grondig wordt getest en stabiliseren.
    • Pas bugfixes en de benodigde wijzigingen toe aan de releasevertakking vóór de implementatie.
    • Tagreleases in de releasebranch om belangrijke mijlpalen te markeren.

    Lijst met vertakkingen:

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

  • Pull-aanvragen:

    • Code controleren en samenvoegen met pull-aanvragen.
    • Automatiseer wat u inspecteert en valideert als onderdeel van pull-aanvragen.
    • Houdt de voltooiingsduur van de pull-aanvraag bij en stelt doelen in om de tijd te verminderen die nodig is.

We gebruiken de myWebApp die in de vorige oefeningen is gemaakt. Zie Beschrijven hoe u lokaal met Git werkt.

In dit recept gebruiken we drie trendy extensies uit de marketplace:

  • Azure CLI: is een opdrachtregelinterface voor Azure.
  • Azure DevOps CLI: het is een uitbreiding van de Azure CLI voor het werken met Azure DevOps en Azure DevOps Server, ontworpen om naadloos te integreren met Git-, CI-pijplijnen en Agile-hulpprogramma's. Met de Azure DevOps CLI kunt u bijdragen aan uw projecten zonder de opdrachtregel te verlaten. CLI wordt uitgevoerd op Windows, Linux en Mac.
  • Samenvoegingsconflict met Git-pull-aanvragen: met deze opensource-extensie die is gemaakt door Microsoft DevLabs, kunt u de samenvoegingsconflicten voor pull-aanvragen op internet bekijken en oplossen. Conflicten met de doelvertakking moeten worden opgelost voordat een Git-pull-aanvraag kan worden voltooid. Met deze extensie kunt u deze conflicten op het web oplossen als onderdeel van de samenvoeging van pull-aanvragen in plaats van de samenvoeging uit te voeren en conflicten in een lokale kloon op te lossen.

De Azure DevOps CLI ondersteunt het retourneren van de queryresultaten in JSON, JSONC, YAML, YAMLC, tabel, TSV en geen. U kunt uw voorkeur configureren met behulp van de opdracht Configureren.

Hoe kunt u het doen?

Belangrijk

U moet het project hebben gemaakt in het eerste leertraject: Beschrijf het werken met Git lokaal.

  1. Nadat u de hoofdvertakking hebt gekloond naar een lokale opslagplaats, maakt u een nieuwe functievertakking, myFeature-1:

    myWebApp

    git checkout -b feature/myFeature-1

    Uitvoer:

    Overgeschakeld naar een nieuwe vertakking 'feature/myFeature-1'.

  2. Voer de Git-vertakkingsopdracht uit om alle vertakkingen te zien. De vertakking die wordt weergegeven met een sterretje is de vertakking 'momenteel uitgecheckt':

    myWebApp

    git branch

    Uitvoer:

    functie/myFeature-1

    main

  3. Breng een wijziging aan in het Program.cs-bestand in de functie/myFeature-1-vertakking:

    myWebApp

    notepad Program.cs

  4. Uw wijzigingen faseren en lokaal doorvoeren en vervolgens uw vertakking publiceren op afstand:

    myWebApp

    git status

    Uitvoer:

    Bij vertakkingsfunctie/myFeature-1 Wijzigingen die niet zijn gefaseerd voor doorvoeren: (gebruik 'git add <file>...' om bij te werken wat er wordt doorgevoerd) (gebruik 'git checkout -- <bestand>...' wijzigingen in werkmap) gewijzigd: Program.cs.

    myWebApp

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

    Uitvoer:

    [functie/myFeature-1 70f67b2] functie 1 toegevoegd aan program.cs 1 bestand gewijzigd, 1 invoeging (+).

    myWebApp

    git push -u origin feature/myFeature-1

    Uitvoer:

    Deltacompressie met maximaal 8 threads. Objecten comprimeren: 100% (3/3), klaar. Objecten schrijven: 100% (3/3), 348 bytes | 348.00 KiB/s, klaar. Totaal 3 (delta 2), hergebruikt 0 (delta 0) extern: Objecten analyseren... (3/3) (10 ms) remote: Packfile opslaan... gedaan (44 ms) remote: Index opslaan... 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.

    De afstandsbediening toont de geschiedenis van de wijzigingen:

    Schermopname van de externe geschiedenis van de wijzigingen.

  5. Azure DevOps CLI configureren voor uw organisatie en project. Organisatie- en projectnaam vervangen:

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

  6. Maak een nieuwe pull-aanvraag (met behulp van de Azure DevOps CLI) om de wijzigingen in de functie-1-vertakking te controleren:

    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

    Gebruik de schakeloptie --open wanneer u de pull-aanvraag ophaalt om deze in een webbrowser te openen nadat deze is gemaakt. De switch --deletesource-branch kan worden gebruikt om de vertakking te verwijderen nadat de pull-aanvraag is voltooid. Overweeg ook het gebruik van --auto-complete om automatisch te voltooien wanneer alle beleidsregels zijn doorgegeven en de bronvertakking kan worden samengevoegd in de doelvertakking.

    Notitie

    Zie Een pull-aanvraag maken om code te controleren en samen te voegen voor meer informatie over az repos pr create parameter.

    Het team controleert gezamenlijk de codewijzigingen en keurt de pull-aanvraag goed:

    Schermopname van de pull-aanvraag met goedgekeurde en voltooide codewijzigingen.

    De belangrijkste is klaar om vrij te geven. Team tagt de hoofdbranch met het releasenummer:

    Schermopname van het maken van een tagvoorbeeld.

  7. Begin met werken aan functie 2. Maak een vertakking op afstand vanuit de hoofdbranch en voer de betaling lokaal uit:

    myWebApp

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

    Uitvoer:

    Totaal 0 (delta 0), hergebruikt 0 (delta 0) Tot https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nieuwe vertakking] origin/HEAD -> refs/heads/feature/myFeature-2.

    myWebApp

    git checkout feature/myFeature-2

    Uitvoer:

    Overgeschakeld naar een nieuwe vertakking 'feature/myFeature-2' Branch-functie/myFeature-2 ingesteld voor het bijhouden van de functie voor externe vertakking/myFeature-2 van oorsprong.

  8. Wijzig Program.cs door dezelfde opmerkingsregel in de code te wijzigen die is gewijzigd in functie-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. Voer de wijzigingen lokaal door, push ze naar de externe opslagplaats en dien vervolgens een pull-aanvraag in om de wijzigingen van functie/myFeature-2 samen te voegen aan de hoofdvertakking:

    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

    Er wordt een kritieke fout gerapporteerd in productie tegen de release van feature-1 met de pull-aanvraag tijdens de vlucht. Als u het probleem wilt onderzoeken, moet u fouten opsporen in de versie van de code die momenteel in productie is geïmplementeerd. Als u het probleem wilt onderzoeken, maakt u een nieuwe fof-vertakking met behulp van de release_feature1-tag:

    myWebApp

    git checkout -b fof/bug-1 release_feature1

    Uitvoer:

    Overgeschakeld naar een nieuwe vertakking, 'fof/bug-1'.

  10. Wijzig Program.cs door dezelfde regel code te wijzigen die is gewijzigd in de release van 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. Faseer en voer de wijzigingen lokaal door en push vervolgens wijzigingen naar de externe opslagplaats:

    myWebApp

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

    Uitvoer:

    Naar https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nieuwe vertakking] fof/bug-1 - fof/bug-1 Branch fof/bug-1 ingesteld voor het bijhouden van externe vertakking fof/bug-1 van oorsprong.

  12. Onmiddellijk nadat de wijzigingen zijn geïmplementeerd in productie, tagt u de vertakking fof\bug-1 met de tag release_bug-1 en genereert u vervolgens een pull-aanvraag om de wijzigingen van fof/bug-1 weer samen te voegen in de hoofdmap:

    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

    Als onderdeel van de pull-aanvraag wordt de vertakking verwijderd. U kunt echter nog steeds verwijzen naar de volledige geschiedenis met behulp van de tag.

    Nu de kritieke foutoplossing uit de weg is gegaan, gaan we de pull-aanvraag voor functie 2 bekijken.

    Op de pagina vertakkingen wordt duidelijk dat de functie/myFeature-2-vertakking één wijziging voor de hoofd- en twee wijzigingen achter de hoofdvertakking is:

    Schermopname van de pagina Vertakkingen. De functie myFeature twee vertakkingen zijn één wijziging voor de hoofd- en twee wijzigingen achter het hoofd.

    Als u de pull-aanvraag goedkeurt, ziet u een foutbericht met de melding dat er een samenvoegingsconflict is opgetreden:

    Schermopname van samenvoegingsconflicten uit pull-aanvraag.

  13. Met de samenvoegingsextensie voor samenvoeging van pull-aanvragen kunt u samenvoegingsconflicten rechtstreeks in de browser oplossen. Ga naar het tabblad Conflicten en klik op Program.cs om de samenvoegingsconflicten op te lossen:

    Schermopname van de samenvoegingsextensie voor samenvoeging van pull-aanvragen.

    Met de gebruikersinterface kunt u de bron, het doel gebruiken, aangepaste wijzigingen toevoegen, controleren en de samenvoegbewerking verzenden. Wanneer de wijzigingen zijn samengevoegd, wordt de pull-aanvraag voltooid.

Op dit moment kunt u een releasebranch maken op basis van de kritieke foutoplossing die is geïmplementeerd in de vertakking fof/bug-1 en samengevoegd in master. Maak met behulp van de git-uitcheckopdracht een toegewezen releasevertakking vanuit de hoofdvertakking.

git checkout -b release/v1.1 main

Met deze opdracht maakt u een nieuwe vertakking met de naam release/v1.1 op basis van de hoofdvertakking.

Aangezien belangrijke mijlpalen tijdens het releaseproces worden bereikt, worden tagreleases in de releasebranch met behulp van Git-tags gebruikt. Tags fungeren als markeringen om specifieke versies van de software aan te geven.

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

Met deze opdracht maakt u een tag met de naam v1.1 om de releaseversie 1.1 in de releasebranch te markeren.

Hoe het werkt

We hebben geleerd hoe het Git-vertakkingsmodel u de flexibiliteit biedt om parallel aan functies te werken door voor elke functie een vertakking te maken.

Met de werkstroom voor pull-aanvragen kunt u codewijzigingen controleren met behulp van het vertakkingsbeleid.

Git-tags zijn een uitstekende manier om mijlpalen vast te leggen, zoals de versie van code die is vrijgegeven; tags bieden u een manier om vertakkingen van tags te maken.

We hebben een vertakking gemaakt van een vorige releasetag om een kritieke fout in productie op te lossen.

De vertakkingenweergave in de webportal maakt het eenvoudig om vertakkingen vóór de hoofdsite te identificeren. Het dwingt ook een samenvoegingsconflict af als lopende pull-aanvragen proberen samen te voegen naar de hoofdmap zonder de samenvoegingsconflicten op te lossen.

Met een lean vertakkingsmodel kunt u kortstondige vertakkingen maken en kwaliteitswijzigingen sneller naar productie pushen.