Alterar o branch padrão

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

O branch padrão é o primeiro branch no qual o Git fará check-out em um clone novo. Além disso, as solicitações de pull selecionam esse branch por padrão.

Vamos percorrer o processo de alteração do branch padrão. Também abordaremos outras coisas que você deve considerar e atualizar ao fazer essa alteração. Por fim, examinaremos uma ferramenta para facilitar a transição.

Definir um novo branch padrão

Você pode usar um branch diferente de main para novas alterações ou alterar a linha de desenvolvimento principal em seu repositório. Para alterar o nome do branch padrão para novos repositórios, consulte Todas as configurações e políticas de repositórios.

Para alterar o branch padrão do repositório para mesclar novas solicitações de pull, você precisa de pelo menos dois branches. Se houver apenas um branch, ele já será o padrão. Você deve criar um segundo branch para alterar o padrão.

Há outros aspectos que você deve considerar antes de fazer essa alteração.

Escolher um nome

O Git 2.28 adicionou a capacidade de escolher um nome de branch inicial. Ao mesmo tempo, o Azure Repos, o GitHub e outros provedores de hospedagem Git adicionaram a capacidade de escolher um nome de branch inicial diferente. Anteriormente, o branch padrão era quase sempre chamado de master. O nome alternativo mais popular é main. As opções menos comuns incluem trunk e development. Se não houver restrições das ferramentas usadas ou da equipe em que você está, qualquer nome de branch válido funcionará.

Atualizar outros sistemas

Quando você muda para um branch padrão diferente, outras partes do fluxo de trabalho podem ser afetadas. Você precisará levar essas partes em conta ao planejar uma alteração.

Pipelines

Atualize os gatilhos de CI para todos os pipelines. Os pipelines do designer podem ser editados na Web. Os pipelines YAML podem ser editados em seus respectivos repositórios.

Solicitações de pull em andamento

Redirecione cada solicitação de pull aberta para o novo branch padrão.

Clones existentes

Os novos clones do repositório receberão o novo branch padrão. Após a alteração, todos com um clone existente devem executar git remote set-head origin -a (substituindo origin pelo nome do remoto, se for outra coisa) para atualizar a exibição do branch padrão do remoto. No futuro os novos branches devem ser baseados no novo padrão.

Links de entrada

Alguns indicadores, documentos e outros arquivos que não são de código que apontam para arquivos no Azure Repos precisarão ser atualizados. O nome do branch para um arquivo ou diretório pode aparecer na URL.

Se uma URL contiver uma querystring para version, por exemplo &version=GBmybranchname, essa URL deverá ser atualizada. Felizmente, a maioria dos links para o branch padrão não terá um segmento version e poderá ser deixada como está. Além disso, depois de excluir o branch padrão antigo, as tentativas de navegar até ele serão levadas para o novo padrão de qualquer maneira.

Espelhamento temporário

Um Repositório do Git só pode ter um branch padrão. No entanto, por um tempo, você pode configurar o espelhamento ad hoc entre o padrão antigo e o novo padrão. Dessa forma, se os usuários finais continuarem enviando por push para o padrão antigo, eles não precisarão refazer o trabalho no final. Usaremos o Azure Pipelines para configurar esse espelhamento temporário.

O pipeline de espelhamento

1. No caso de todos os builds de CI existentes, atualize-os para disparar em relação ao novo branch padrão em vez do antigo.

2. Conceda à identidade de build a permissão Contribuir para seu repositório. Navegue até Configurações do Projeto>Repositórios>(seu repositório)>Permissões. Pode haver até duas identidades, uma para o serviço de build de coleção de projetos e outra para o serviço de build do projeto. Certifique-se de que a permissão Contribuir diga Permitir.

3. Se o novo branch padrão tiver políticas de branch, conceda também à identidade de build as Políticas de bypass ao enviar permissão por push. Essa permissão é um risco de segurança, pois um usuário mal-intencionado pode criar um pipeline para transferir código em segredo para um repositório em seu projeto. Quando o espelhamento não for mais necessário,certifique-se de remover essa permissão.

4. Adicione um novo arquivo mirror.yml ao repositório no novo branch padrão. Neste exemplo, presumimos que o branch padrão antigo era master e o novo é main. Atualize os branches de gatilho e a linha git push se os nomes de seu branch forem diferentes.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. Crie um novo pipeline, escolhendo "Azure Repos Git" e "Arquivo YAML do Azure Pipelines existente" no assistente. Escolha o arquivo mirror.yml que você adicionou na etapa anterior. Salve e execute o pipeline.

Solução de problemas

Esse pipeline será executado sempre que houver um push para master ou para main. Ele os manterá sincronizados desde que novos commits não cheguem em ambos os branches simultaneamente.

Se o pipeline começar a falhar com uma mensagem de erro como "As atualizações foram rejeitadas porque uma dica de branch enviada por push está atrás do seu remoto", alguém terá que mesclar o branch antigo no novo branch manualmente.

1. Clone o repositório e cd em seu diretório.
2. Faça o check-out do novo branch padrão com git checkout main (se main for o novo branch padrão).
3. Crie um novo branch para integrar os dois branches com git checkout -b integrate.
4. Mescle o branch padrão antigo com git merge master (se master for seu antigo branch padrão).
5. Envie o novo branch por push e, em seguida, abra e conclua uma solicitação de pull no novo branch padrão.
6. Em seguida, o pipeline de espelhamento deve ficar a cargo do espelhamento do commit de mesclagem de volta para o padrão antigo.