Explore o modelo de filial Git para entrega contínua

  • 3 minutos

O objetivo de escrever código é enviar melhorias para o seu software.

Um modelo de ramificação que introduz muita sobrecarga de processo não ajuda a aumentar a velocidade de obtenção de alterações para os clientes — o desenvolvimento de um modelo de ramificação oferece preenchimento suficiente para não enviar alterações de baixa qualidade. Mas, ao mesmo tempo, não introduz muitos processos para atrasá-lo.

A internet está cheia de estratégias de ramificação para o Git; Embora não haja certo ou errado, uma estratégia de ramificação perfeita funciona para sua equipe!

Você aprenderá sempre a usar a combinação de ramificações de recursos e solicitações pull para ter uma ramificação principal pronta para envio.

Preparação

Vamos abordar os princípios do que sugerimos:

  • O ramo principal:

    • O ramo principal é a única maneira de liberar qualquer coisa para a produção.
    • A ramificação principal deve estar sempre em um estado pronto para liberação.
    • Proteja a ramificação principal com políticas de ramificação.
    • Quaisquer alterações no fluxo de ramificação principal apenas através de solicitações pull.
    • Marque todas as versões na ramificação principal com tags Git.

  • O ramo de recursos:

    • Use ramificações de recursos para todos os novos recursos e correções de bugs.
    • Use sinalizadores de recursos para gerenciar ramificações de recursos de longa execução.
    • As alterações de ramificações de recursos para a principal apenas fluem por meio de solicitações pull.
    • Nomeie seu recurso para refletir sua finalidade.

  • O ramo de lançamento:

    • Crie uma ramificação de versão dedicada a partir de uma ramificação de recurso estável para se preparar para a implantação.
    • Garantir que a ramificação de liberação passe por testes completos e esforços de estabilização.
    • Aplique correções de bugs e alterações necessárias na ramificação de lançamento antes da implantação.
    • Marque lançamentos na ramificação de lançamento para marcar marcos significativos.

    Lista de sucursais:

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

  • Pull solicitações:

    • Revise e mescle o código com solicitações pull.
    • Automatize o que você inspeciona e valida como parte de solicitações pull.
    • Rastreia a duração da conclusão da solicitação de pull e define metas para reduzir o tempo necessário.

Usaremos o myWebApp criado nos exercícios anteriores. Consulte Descrever o trabalho com o Git localmente.

Nesta receita, usaremos três extensões modernas do mercado:

  • CLI do Azure: é uma interface de linha de comando para o Azure.
  • CLI do Azure DevOps: é uma extensão da CLI do Azure para trabalhar com o Azure DevOps e o Azure DevOps Server projetado para se integrar perfeitamente ao Git, pipelines de CI e ferramentas Agile. Com a CLI do Azure DevOps, você pode contribuir com seus projetos sem sair da linha de comando. A CLI é executada em Windows, Linux e Mac.
  • Git Pull Request Merge Conflict: Esta extensão de código aberto criada pelo Microsoft DevLabs permite que você revise e resolva os conflitos de mesclagem de solicitação pull na Web. Quaisquer conflitos com a ramificação de destino devem ser resolvidos antes que uma solicitação pull do Git possa ser concluída. Com essa extensão, você pode resolver esses conflitos na Web como parte da mesclagem de solicitação pull em vez de fazer a mesclagem e resolver conflitos em um clone local.

A CLI do Azure DevOps dá suporte ao retorno dos resultados da consulta em JSON, JSONC, YAML, YAMLC, table, TSV e none. Você pode configurar sua preferência usando o comando configure.

Como fazê-lo

Importante

Você precisa ter o projeto criado no primeiro Caminho de Aprendizagem: Descreva o trabalho com o Git localmente.

  1. Depois de clonar a ramificação principal em um repositório local, crie uma nova ramificação de recurso, myFeature-1:

    myWebApp

    git checkout -b feature/myFeature-1

    Saída:

    Mudou para uma nova ramificação 'feature/myFeature-1'.

  2. Execute o comando Git branch para ver todas as ramificações. A ramificação que aparece com um asterisco é a ramificação "atualmente verificada":

    myWebApp

    git branch

    Saída:

    recurso/myFeature-1

    main

  3. Faça uma alteração no arquivo Program.cs na ramificação feature/myFeature-1:

    myWebApp

    notepad Program.cs

  4. Prepare suas alterações e confirme localmente e, em seguida, publique sua ramificação remotamente:

    myWebApp

    git status

    Saída:

    No recurso de ramificação/myFeature-1 Alterações não preparadas para confirmação: (use "git add <file>..." para atualizar o que será confirmado) (use "git checkout -- <file>..." para descartar alterações no diretório de trabalho) modificado: Program.cs.

    myWebApp

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

    Saída:

    [feature/myFeature-1 70f67b2] recurso 1 adicionado a program.cs arquivo 1 alterado, 1 inserção (+).

    myWebApp

    git push -u origin feature/myFeature-1

    Saída:

    Compressão delta usando até 8 threads. Comprimir objetos: 100% (3/3), feito. Objetos de escrita: 100% (3/3), 348 bytes | 348,00 KiB/s, concluído. Total 3 (delta 2), reutilizado 0 (delta 0) remoto: Analisando objetos... (3/3) (10 ms) remoto: Armazenando packfile... feito (44 ms) remoto: Armazenando índice... feito (62 ms) Para https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [new branch] feature/myFeature-1 -> feature/myFeature-1 Branch feature/myFeature-1 configurado para rastrear o recurso de ramificação remota/myFeature-1 desde a origem.

    O controle remoto mostra o histórico das alterações:

    Captura de tela do histórico remoto das alterações.

  5. Configure a CLI do Azure DevOps para sua organização e projeto. Substitua o nome da organização e do projeto:

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

  6. Crie uma nova solicitação pull (usando a CLI do Azure DevOps) para revisar as alterações na ramificação do recurso 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

    Use a opção --open ao gerar a solicitação pull para abri-la em um navegador da Web depois de criada. A opção --deletesource-branch pode ser usada para excluir a ramificação após a conclusão da solicitação pull. Além disso, considere usar --auto-complete para concluir automaticamente quando todas as políticas tiverem passado e a ramificação de origem puder ser mesclada na ramificação de destino.

    Nota

    Para obter mais informações sobre az repos pr create parameter, consulte Criar uma solicitação pull para revisar e mesclar código.

    A equipe analisa conjuntamente as alterações de código e aprova a solicitação pull:

    Captura de tela da solicitação pull com alterações de código aprovadas e concluídas.

    O principal está pronto para ser lançado. A equipe marca a ramificação principal com o número da versão:

    Captura de ecrã da criação de um exemplo de etiqueta.

  7. Comece a trabalhar no Recurso 2. Crie uma ramificação remota da ramificação principal e faça o checkout localmente:

    myWebApp

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

    Saída:

    Total 0 (delta 0), reutilizado 0 (delta 0) Para https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [novo ramo] origem/HEAD -> refs/heads/feature/myFeature-2.

    myWebApp

    git checkout feature/myFeature-2

    Saída:

    Mudei para um novo recurso de ramificação 'feature/myFeature-2' Branch feature/myFeature-2 configurado para rastrear o recurso de ramificação remota/myFeature-2 desde a origem.

  8. Modifique Program.cs alterando a mesma linha de comentário no código alterado no recurso-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. Confirme as alterações localmente, envie-as por push para o repositório remoto e, em seguida, gere uma solicitação pull para mesclar as alterações do recurso/myFeature-2 para a ramificação principal:

    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

    Um bug crítico é relatado na produção em relação à versão feature-1 com a solicitação pull em voo. Para investigar o problema, você precisa depurar em relação à versão do código atualmente implantado em produção. Para investigar o problema, crie uma nova ramificação fof usando a tag release_feature1:

    myWebApp

    git checkout -b fof/bug-1 release_feature1

    Saída:

    Mudou para uma nova ramificação, 'fof/bug-1'.

  10. Modifique Program.cs alterando a mesma linha de código que foi alterada na versão 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. Prepare e confirme as alterações localmente e, em seguida, envie as alterações por push para o repositório remoto:

    myWebApp

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

    Saída:

    Para https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 configurado para rastrear branch remoto fof/bug-1 desde a origem.

  12. Imediatamente após as alterações terem sido implementadas na produção, marque a ramificação fof\bug-1 com a tag release_bug-1 e, em seguida, gere uma solicitação pull para mesclar as alterações de fof/bug-1 de volta à principal:

    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

    Como parte da solicitação pull, a ramificação é excluída. No entanto, você ainda pode fazer referência a todo o histórico usando a tag .

    Com a correção de bug crítico fora do caminho, vamos rever a solicitação pull do recurso-2.

    A página de ramificações deixa claro que a ramificação feature/myFeature-2 é uma mudança à frente da principal e duas alterações atrás da principal:

    Captura de ecrã da página de filiais. O recurso myFeature dois ramos são uma mudança à frente do principal e duas mudanças atrás do principal.

    Se você tentasse aprovar a solicitação pull, veria uma mensagem de erro informando sobre um conflito de mesclagem:

    Captura de tela de conflitos de mesclagem da solicitação pull.

  13. A extensão Git Pull Request Merge Conflict resolution torna possível resolver conflitos de mesclagem diretamente no navegador. Navegue até a guia conflitos e clique em Program.cs para resolver os conflitos de mesclagem:

    Captura de tela da extensão de resolução de conflitos de mesclagem de solicitação pull do Git.

    A interface do usuário permite que você pegue a origem, o destino, adicione alterações personalizadas, revise e envie a mesclagem. Com as alterações mescladas, a solicitação pull é concluída.

Neste ponto, você pode criar uma ramificação de lançamento com base na correção de bug crítico implementada na ramificação fof/bug-1 e mesclada no master. Usando o comando git checkout, crie uma ramificação de liberação dedicada a partir da ramificação principal.

git checkout -b release/v1.1 main

Este comando cria uma nova ramificação chamada release/v1.1 com base na ramificação principal.

À medida que marcos significativos são alcançados durante o processo de lançamento, as liberações de tags na ramificação de lançamento usam tags Git. As tags servem como marcadores para indicar versões específicas do software.

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

Este comando cria uma tag chamada v1.1 para marcar a versão de lançamento 1.1 na ramificação de lançamento.

Como funciona

Aprendemos como o modelo de ramificação Git oferece a flexibilidade de trabalhar em recursos em paralelo, criando uma ramificação para cada recurso.

O fluxo de trabalho de solicitação pull permite que você revise as alterações de código usando as políticas de ramificação.

As tags Git são uma ótima maneira de registrar marcos, como a versão do código liberada; oferecem uma maneira de criar ramificações a partir de tags.

Criamos uma ramificação a partir de uma tag de lançamento anterior para corrigir um bug crítico na produção.

A visualização de ramificações no portal da Web facilita a identificação de ramificações antes da principal. Além disso, ele força um conflito de mesclagem se quaisquer solicitações pull em andamento tentarem mesclar para a principal sem resolver os conflitos de mesclagem.

Um modelo de ramificação enxuta permite criar ramificações de curta duração e empurrar as mudanças de qualidade para a produção mais rapidamente.