Alterar a ramificação padrão

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

A ramificação padrão é a primeira ramificação que o Git fará check-out em um novo clone. Além disso, as solicitações pull visam essa ramificação por padrã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.

Definir uma nova ramificação padrão

Você pode usar uma ramificação diferente para main 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.

Nota

Alterar a ramificação padrão requer que você tenha permissão para Editar políticas . Para obter mais informações, consulte Definir permissões do repositório Git.

1. No repositório do projeto, selecione Ramos.

2. Na página Ramos, selecione Mais opções ao lado da nova ramificação padrão desejada e escolha Definir como ramificação padrão.

   

3. Depois de definir a nova ramificação padrão, você pode excluir o padrão anterior, se desejar.

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

Escolha um nome

O 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 nomeada 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.

Pipelines

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 ser executados 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 querystring 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 version segmento e pode ser deixada como está. 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 pressionando para o padrão antigo, eles não precisarão refazer o trabalho do seu lado. Usaremos o Azure Pipelines para configurar esse espelhamento temporário.

Nota

Esta seção usa linguagem que está em desacordo com a perspetiva da Microsoft. Especificamente, a palavra master aparece em vários lugares consistentes com a forma como tem sido usada no Git. O objetivo deste tópico é explicar como mudar para uma linguagem mais inclusiva, como main. Evitar todas as menções tornaria as direções muito mais difíceis de master entender.

O pipeline de espelhamento

Nota

Essas instruções não são infalíveis, e a configuração do repositório pode exigir alterações adicionais, como afrouxamento de permissões e políticas.

Aviso

Se as ramificações padrão antigas e novas forem atualizadas antes que esse pipeline seja executado, o pipeline não poderá espelhar as alterações. Alguém terá que mesclar manualmente a ramificação padrão antiga na nova ramificação padrão para executá-la automaticamente novamente.

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

2. Conceda a permissão Contribuir da identidade de compilação ao seu repositório. Navegue até Project Settings>Repositories>(your repo)>Permissions. 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 por push . 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 era master e a nova é main. Atualize as ramificações de acionamento e a linha se os nomes das git push 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 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á 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 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 uma nova ramificação para integrar as duas ramificações com git checkout -b integrateo .
4. Mescle a ramificação padrão antiga com git merge master (se master for sua ramificação padrão antiga).
5. Empurre a nova ramificação e, em seguida, abra e conclua uma solicitação pull para a 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.