Alterar a ramificação padrão

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

A ramificação padrão é a primeira ramificação que o Git verificará num novo clone. Além disso, por padrão, os pull requests direcionam esta ramificação.

Vamos percorrer o processo de alteração da ramificação padrão. Também abordaremos outras coisas que você deve considerar e atualizar ao fazer essa alteração. Finalmente, veremos uma ferramenta para facilitar a transição.

Pré-requisitos

Definir uma nova ramificação padrão

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

Para alterar a ramificação padrão do repositório para mesclar novas solicitações pull, você precisa de pelo menos duas ramificações. Se houver apenas uma filial, já é o padrão. Você deve criar uma segunda ramificação para alterar o padrão.

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

Escolha um nome

Git 2.28 adicionou a capacidade de escolher um nome de ramificação inicial. Ao mesmo tempo, Azure Repos, GitHub e outros provedores de hospedagem Git adicionaram a capacidade de escolher um nome de ramificação inicial diferente. Anteriormente, a ramificação padrão era quase sempre chamada master. O nome alternativo mais popular é main. Opções menos comuns incluem trunk e development. Na ausência de quaisquer restrições das ferramentas que você usa ou da equipe em que você está, qualquer nome de filial válido funcionará.

Atualizar outros sistemas

Quando você muda para uma ramificação padrão diferente, outras partes do seu fluxo de trabalho podem ser afetadas. Você precisará levar essas partes em consideração ao planejar uma mudança.

Tubulações

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

Pedidos de pull durante o voo

Redirecionar cada solicitação pull aberta para a nova ramificação padrão.

Clones existentes

Novos clones do repositório obterão a nova ramificação padrão. Após a mudança, todos com um clone existente devem executar git remote set-head origin -a (substituindo origin pelo nome do controle remoto se for outra coisa) para atualizar sua exibição da ramificação padrão do remoto. As futuras novas filiais devem basear-se no novo incumprimento.

Ligações recebidas

Alguns marcadores, documentos e outros arquivos não codificados que apontam para arquivos no Azure Repos precisarão ser atualizados. O nome da ramificação de um arquivo ou diretório pode aparecer na URL.

Se um URL contiver uma cadeia de caracteres de consulta para version, por exemplo, &version=GBmybranchname, esse URL deverá ser atualizado. Felizmente, a maioria dos links para a ramificação padrão não terá um segmento version e pode ser deixada as-is. Além disso, depois de excluir a ramificação padrão antiga, as tentativas de navegar até ela serão levadas para o novo padrão de qualquer maneira.

Espelhamento temporário

Um repositório Git só pode ter uma ramificação padrão. No entanto, por um tempo, você pode configurar o espelhamento ad-hoc entre o padrão antigo e o novo. Dessa forma, se os usuários finais continuarem a recorrer ao padrão antigo, eles não precisarão refazer o trabalho do lado deles. Usaremos do Azure Pipelines para configurar esse espelhamento temporário.

O pipeline de espelhamento

1. Para todas as compilações de CI existentes, atualize-as para acionar em relação à sua nova ramificação padrão em vez da antiga.

2. Conceda à identidade de build a permissão Contribute para o 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 compilação da coleção de projetos e outra para o serviço de compilação do projeto. Verifique se a permissão Contribuir diz Permitir.

3. Se a nova ramificação padrão tiver políticas de ramificação, conceda também à identidade de compilação as políticas de Bypass ao enviar permissão. Essa permissão é um risco de segurança, uma vez que um usuário mal-intencionado pode criar um pipeline para inserir código em 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 seu repositório na nova ramificação padrão. Neste exemplo, assumimos que a ramificação padrão antiga foi master e a nova é main. Atualize as ramificações de acionamento e a linha git push se os nomes das ramificações 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 "Existing Azure Pipelines YAML file" no assistente. Escolha o arquivo mirror.yml que você adicionou na etapa anterior. Salve e execute o pipeline.

Solução de problemas

Este pipeline será executado sempre que houver um push para master ou para main. Ele os manterá em sincronia, 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 ponta de ramificação empurrada está atrás de seu controle remoto", alguém terá que mesclar a ramificação antiga na nova ramificação manualmente.

1. Clone o repositório e cd no 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 uma nova ramificação para integrar as duas ramificações com git checkout -b integrate.
4. Mescle a ramificação padrão antiga com git merge master (se master for sua ramificação padrão antiga).
5. Faça o push da nova ramificação e, em seguida, abra um pedido de pull e conclua-o na nova ramificação padrão.
6. O pipeline de espelhamento deve então cuidar de espelhar a confirmação de mesclagem de volta ao padrão antigo.