Alterar o branch padrão

Serviços do Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

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 direcionam 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.

Pré-requisitos

Definir um ramo padrão novo

"Você pode usar um branch diferente de main para novas alterações ou alterar sua linha principal de desenvolvimento 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 duas ramificações. Se houver apenas um branch, ele já é o padrão. Você precisa criar um segundo ramo 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 master. O nome alternativo mais popular é main. 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

Novos clones do repositório obterão o novo ramo 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 favoritos, documentos e outros arquivos não de código que apontam para arquivos no Azure Repos precisarão ser atualizados. O nome da ramificação 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 ramo padrão não terá um segmento version e pode ser deixada como está. Além disso, depois de excluir o branch padrão antigo, as tentativas de navegar até ele serão redirecionadas para o novo branch padrão de qualquer maneira.

Espelhamento temporário

Um repositório 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 a permissão de Contribuir à identidade de build do seu repositório. Navegue até Configurações do Projeto>Repositórios>(seu repositório)>Permissões. Podem existir até duas identidades: uma para o serviço de compilação da coletânea de projetos e outra para o serviço de compilação do projeto. Verifique se a permissão Contribuir diz 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 malicioso pode criar um pipeline para infiltrar código em um repositório no seu projeto. Quando o espelhamento não for mais necessário, remova essa permissão.

4. Adicione um novo arquivo, mirror.yml ao seu repositório no novo ramo 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 mirror.yml arquivo que você adicionou na etapa anterior. Salve e execute o pipeline.

Resoluçã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 antigo branch padrão com git merge master (caso master seja o seu branch padrão antigo).
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.