Alterar o branch padrão

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

O branch padrão é o primeiro branch que 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 novo branch padrão

Você pode usar um branch diferente de main 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ê 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 nomeado master. O nome alternativo mais popular é main. Opções menos comuns incluem trunk e development. Sem quaisquer 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. Pipelines de designer podem ser editados na Web. Os pipelines YAML podem ser editados em seus respectivos repositórios.

Solicitações de pull no voo

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

Clones existentes

Novos clones do repositório obterão o novo branch padrão. Após a opção, todos com um clone existente devem ser executados git remote set-head origin -a (substituindo origin pelo nome do seu controle remoto se for outra coisa) para atualizar a exibição do branch padrão do remoto. As novas ramificações futuras devem ser baseadas 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 version segmento e pode ser deixada as-is. 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 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. Para todos os builds de CI existentes, atualize-os para disparar em relação ao seu novo branch padrão em vez do antigo.

2. Conceda a permissão de contribuição de identidade de build ao seu repositório. Navegue atérepositórios>de configurações> do projeto (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. 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 mal-intencionado pode criar um pipeline para esgueirar o código em um repositório em seu projeto. Quando o espelhamento não for mais necessário, remova 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 git push linha se os nomes de 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 "Git do Azure Repos" 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 novas confirmações não cheguem em ambas as ramificações 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 de seu controle 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. Confira a nova ramificação padrão com git checkout main (se main for sua nova ramificação padrão).
3. Crie um branch para integrar os dois branches com git checkout -b integrate.
4. Mesclar o branch padrão antigo com git merge master (se master for o branch padrão antigo).
5. Envie por push o novo branch e, em seguida, abra e conclua uma solicitação de pull para o novo branch padrão.
6. Em seguida, o pipeline de espelhamento deve cuidar do espelhamento da confirmação de mesclagem para o padrão antigo.