Explorar o modelo GIT branch para entrega contínua

3 minutos

A finalidade de escrever código é enviar aprimoramentos ao software.

Um modelo de ramificação que introduz muita sobrecarga de processo não ajuda a aumentar a velocidade de efetivaçã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 apresente muitos processos para atrasar o trabalho.

A Internet está cheia de estratégias de ramificação para Git. Embora não exista certo ou errado, uma estratégia de ramificação perfeita é aquela que funciona para sua equipe.

Você aprenderá a sempre usar a combinação de branches de recursos e solicitações de pull para criar um branch principal pronto para o envio.

Preparando-se

Vamos abranger os princípios do que sugerimos:

O branch principal:
- O branch principal é a única maneira de lançar algo para produção.
- O branch principal sempre deve estar em um estado pronto para lançamento.
- Proteja o branch principal com políticas de branch.
- Todas as alterações no branch principal fluem somente por meio de solicitações de pull.
- Marque todos os lançamentos no branch principal com tags do Git.
O branch de recursos:
- Use branches de recursos para todos os novos recursos e correções de bugs.
- Use sinalizadores de recurso para gerenciar branches de recursos de execução prolongada.
- As alterações de branches de recurso para o principal fluem apenas por meio de solicitações de pull.
- Nomeie seu recurso para refletir a finalidade.
O branch de lançamento:
- Crie um branch de lançamento dedicado de um branch de recurso estável para se preparar para a implantação.
- Garanta que o branch de lançamento passe por testes minuciosos e esforços de estabilização.
- Aplique correções de bug e alterações necessárias ao branch de lançamento antes da implantação.
- Marque os lançamentos no branch de lançamento com tags para indicar marcos significativos.
Lista de branches:
```
bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem
```
Solicitações de pull:
- Revisam e mesclam o código com solicitações de pull.
- Automatizam o que você inspeciona e valida como parte das solicitações de pull.
- Acompanha a duração da conclusão da solicitação de pull e das metas definidas para reduzir o tempo necessário.

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

Nesta receita, usaremos três extensões de tendência do marketplace:

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 Azure DevOps Server elaborados para se integrar perfeitamente ao Git, a pipelines de CI e a ferramentas Agile. Com a CLI do Azure DevOps, você pode contribuir nos projetos sem sair da linha de comando. A CLI é executada no Windows, no Linux e no Mac.
Conflito de mesclagem de solicitação de pull do Git: essa extensão de código-fonte aberto criada pelo Microsoft DevLabs permite que você revise e resolva conflitos de mesclagem de solicitação de pull na Web. Quaisquer conflitos com a ramificação de destino devem ser resolvidos antes que uma solicitação de 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 de pull em vez de fazer a mesclagem e resolver conflitos em um clone local.

A CLI do Azure DevOps dá suporte ao retorno dos seguintes resultados de consulta: JSON, JSONC, YAML, YAMLC, tabela, TSV e nenhum. Você pode configurar sua preferência usando o comando de configuração.

Como fazer

Importante

Você precisa ter o projeto criado no primeiro Roteiro de Aprendizagem: Descrever como trabalhar com o Git localmente.

Depois de clonar o branch principal em um repositório local, crie o branch de recursos myFeature-1:

myWebApp
```
git checkout -b feature/myFeature-1
```
Saída:

Alternado para uma nova ramificação 'feature/myFeature-1'.
Execute o comando Git branch para ver todas as ramificações. A ramificação que aparece com um asterisco é a que está "atualmente em check-out":

myWebApp
```
git branch
```
Saída:

feature/myFeature-1

main
Faça uma alteração no arquivo Program.cs no branch feature/myFeature-1:

myWebApp
```
notepad Program.cs
```
Prepare as alterações e faça commit localmente. Depois publique o branch no remoto:

myWebApp
```
git status
```
Saída:

Na ramificação feature/myFeature-1 as alterações não são preparadas para confirmação: (use "git add <file>..." para atualizar o que será confirmado) (use "git checkout -- <file>..." para descartar as 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 ao program.cs 1 arquivo alterado, 1 inserção(+).

myWebApp
```
git push -u origin feature/myFeature-1
```
Saída:

Compactação Delta usando até 8 threads. Compactando 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 arquivo de pacote... concluído (44 ms) remoto: Armazenando índice... concluído (62 ms) Para https://dev.azure.com/organization/teamproject/\_git/MyWebApp * [nova ramificação] feature/myFeature-1 -> feature/myFeature-1 Ramificação feature/myFeature-1 configurada para rastrear a ramificação remota feature/myFeature-1 desde a origem.

O remoto mostra o histórico das alterações:
Configure a CLI do Azure DevOps para sua organização e projeto. Substitua organização e nome do projeto:
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
Crie uma solicitação de pull (usando a CLI do Azure DevOps) para revisar as alterações no branch 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
```
Use a opção --open ao criar a solicitação de pull para abri-la em um navegador da Web após a criação. A opção --deletesource-branch pode ser usada para excluir o branch após a conclusão da solicitação de pull. Além disso, considere usar --auto-complete para concluir automaticamente quando todas as políticas forem aprovadas e o branch de origem puder ser mesclado no branch de destino.

Observação

Para obter mais informações sobre o parâmetro de criação de az repos pr, confira Criar uma solicitação de pull para revisar e mesclar código.

A equipe revisa as alterações de código e aprova a solicitação de pull em conjunto:

O principal está pronto para lançamento. A equipe marca a ramificação principal com o número da versão:
Inicie o trabalho no Recurso 2. Crie um branch no remoto do branch principal e faça o check-out 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 * [nova ramificação] origin/HEAD – > refs/heads/feature/myFeature-2.

myWebApp
```
git checkout feature/myFeature-2
```
Saída:

Alternado para uma nova ramificação 'feature/myFeature-2' Branch feature/myFeature-2, configurada para rastrear a ramificação remota feature/myFeature-2 desde a origem.

Modifique Program.cs alterando a mesma linha de comentário no código que foi alterado no feature-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();

Confirme as alterações localmente, envie-as por push para o repositório remoto e gere uma solicitação de pull para mesclar as alterações de feature/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 em produção na versão feature-1 com a solicitação de pull em andamento. Para investigar o problema, você precisa depurar a versão do código implantada em produção no momento. Para investigar o problema, crie uma ramificação fof usando a marca release_feature1:

myWebApp
```
git checkout -b fof/bug-1 release_feature1
```
Saída:

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

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();

Prepare as alterações e faça commit delas localmente. Depois 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 * [nova ramificação] fof/bug-1 - fof/bug-1 Branch fof/bug-1 configurada para rastrear a ramificação remota fof/bug-1 desde a origem.
Imediatamente depois que as alterações forem distribuídas para produção, marque a ramificação fof\bug-1 com a marca release_bug-1 e crie uma solicitação de pull para mesclar as alterações de fof/bug-1 novamente no 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 de pull, o branch é excluído. No entanto, você ainda pode fazer referência a todo o histórico usando a marcação.

Com a correção do bug crítico feita, vamos revisar a solicitação pull do recurso 2.

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

Se você tentou aprovar a solicitação de pull, verá uma mensagem de erro informando sobre um conflito de mesclagem:
A extensão de resolução de conflito de mesclagem de solicitação de pull do Git permite resolver conflitos de mesclagem diretamente no navegador. Navegue até a guia conflitos e clique em Program.cs para resolver os conflitos de mesclagem:

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 de pull é concluída.

Neste ponto, você pode criar um branch de lançamento com base na correção crítica de bugs implementada no branch fof/bug-1 e mesclada no master. Usando o comando git checkout, crie um branch de lançamento dedicado a partir do branch master.

git checkout -b release/v1.1 main

Esse comando cria um novo branch chamado release/v1.1 com base no branch master.

Conforme marcos significativos são alcançados durante o processo de lançamento, marque os lançamentos no branch de lançamento usando tags do Git. As tags servem como marcadores para denotar versões específicas do software.

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

Esse comando cria uma tag chamada v1.1 para marcar a versão de lançamento 1.1 no branch de lançamento.

Como ele funciona

Aprendemos como o modelo de ramificação do Git oferece a flexibilidade para trabalhar nos recursos em paralelo criando um branch para cada recurso.

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

As tags do Git são uma ótima maneira de registrar marcos, como a versão do código liberada. É possível criar branches usando tags.

Criamos um branch de uma tag de versão anterior para corrigir um bug crítico na produção.

A exibição de branches no portal da Web facilita a identificação dos branches à frente do principal. Além disso, ela força um conflito de mesclagem quando alguma solicitação de pull contínua tenta fazer a mesclagem no principal sem resolver os conflitos de mesclagem.

Um modelo simples permite criar ramificações de curta duração e enviar alterações de qualidade para a produção mais rapidamente.

Explorar o modelo GIT branch para entrega contínua

Preparando-se

Como fazer

Como ele funciona

Comentários