Compartilhar via


Garfos

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

Visual Studio 2019 | Visual Studio 2022

As bifurcações de Repositório do Git são úteis quando as pessoas querem fazer alterações experimentais, arriscadas ou secretas em uma base de código, mas essas alterações precisam ser isoladas da base de código no repositório original. Uma nova é basicamente um novo repositório remoto que compartilha o código-fonte do repositório original.

Como uma versão independente, as alterações feitas na sua bifurcação, como a adição de confirmações ou branches, são ocultas do repositório original. Se você quiser mesclar as alterações da base de código no repositório original, você deve criar uma solicitação de pull (PR) para solicitar a revisão e a aprovação dessas alterações.

O processo de bifurcação não transfere permissões, políticas ou pipelines de build do repositório original para a sua bifurcação.

Este artigo aborda o trabalho com bifurcações nos repositórios Git do Azure Repos e fornece links para o conteúdo do GitHub que discute como gerenciar Bifurcações em repositórios do GitHub.

Neste artigo, você aprenderá a:

  • Compartilhar código entre forks
  • Escolher entre branches e forks
  • Habilitar bifurcações de repositório
  • Criar fork
  • Clonar o fork localmente
  • Enviar alterações locais por push para a sua bifurcação
  • Criar e concluir uma PR
  • Sincronizar sua bifurcação

Pré-requisitos para acesso ao Azure Repos

  • Os repositórios devem estar habilitados nas configurações do projeto do Azure DevOps. Se o hub do Repositório e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço do Azure DevOps para reabilitar o Repositório.

  • Para exibir o código em projetos privados, você deve ser membro de um projeto do Azure DevOps com nível de acesso Básico ou superior. Para projetos públicos, todos podem exibir o código.

  • Para clonar ou contribuir com o código para um projeto privado, você deve ser membro do grupo de segurança Colaboradores ou ter as permissões correspondentes definidas. Para projetos públicos, qualquer pessoa pode clonar e contribuir com código. Para obter mais informações, confira O que é um projeto público?

    Observação

    Para projetos públicos, os usuários que receberam acesso de Stakeholder têm acesso total ao Azure Repos.

  • Os repositórios devem estar habilitados nas configurações do projeto do Azure DevOps. Se o hub do Repositório e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço do Azure DevOps para reabilitar o Repositório.

  • Para exibir o código, você deve ser membro do projeto do Azure DevOps com acesso Básico ou superior. Se você não for um membro do projeto, será adicionado.

  • Para clonar ou contribuir com o código , você deve ser membro do grupo de segurança Colaboradores ou ter as permissões correspondentes, no projeto que quiser alterar.

Compartilhar código entre forks

O repositório original geralmente é chamado de repositório upstream. Você pode criar PRs para mesclar alterações em qualquer direção: da bifurcação para upstream ou de upstream para a bifurcação. A direção mais comum é de bifurcação para upstream. As permissões, políticas, os builds e os itens de trabalho do repositório de destino serão aplicados à PR.

Escolher entre branches e forks

Para uma pequena equipe de 2 a 5 desenvolvedores, um fluxo de trabalho de bifurcação pode não ser necessário porque todos podem trabalhar em branches de recursos e políticas de branch podem proteger o branch padrão. No entanto, se sua equipe expandir e superar esse arranjo, ela poderá mudar para um fluxo de trabalho de bifurcação.

Se o repositório tiver um grande número de confirmadores casuais ou pouco frequentes, como um projeto de código aberto, recomendamos o fluxo de trabalho de bifurcação. Normalmente, somente os colaboradores principais do projeto têm direitos de confirmações diretas em seu repositório. Outros colaboradores devem usar um fluxo de trabalho de bifurcação para isolar suas alterações propostas até que os colaboradores principais tenham a chance de revisar seu trabalho.

Habilitar bifurcações de repositório

Para habilitar bifurcações para um Repositório do Git do Azure Repos, consulte habilitar Bifurcações.

Para habilitar bifurcações para um repositório do GitHub, consulte Gerenciando a política de bifurcação para sua organização.

O fluxo de trabalho de fork

O fluxo de trabalho de bifurcação consiste em cinco etapas descritas nas seções a seguir.

  1. Criar um fork
  2. Clonar o fork localmente
  3. Enviar alterações locais por push para a sua bifurcação
  4. Criar e concluir uma PR
  5. Sincronizar sua bifurcação

Criar fork

As etapas a seguir descrevem como bifurcar um Repositório do Git do Azure Repos.

Observação

Para bifurcar um repositório em um projeto do Azure DevOps, você deve ter a permissão Criar Repositório para esse projeto. Os proprietários de repositório devem considerar a criação de um projeto dedicado para bifurcações e atribuir a permissão Criar Repositório a todos os colaboradores. Para obter mais informações sobre como definir permissões, consulte Definir permissões do Repositório do Git.

  1. No navegador da Web, navegue até o Repositório do Git do Azure Repos que você deseja bifurcar. Selecione Arquivos de >Repositório e, em seguida, escolha Bifurcação no menu de reticências para abrir a caixa de diálogo Bifurcação.

    Captura de tela do item de menu Bifurcação no menu Mais ações na página Arquivos de Repositório do Azure Repos.

  2. Na caixa de diálogo Bifurcação, nomeie o repositório bifurcado, escolha o projeto em que você deseja que a bifurcação seja criada, selecione os branches a serem incluídos na bifurcação e escolha Bifurcação. Você pode especificar se a bifurcação conterá todos os branches ou apenas o branch padrão. Se o repositório contiver vários branches do tópico, considere incluir apenas o branch padrão em sua bifurcação.

    Captura de tela da caixa de diálogo Bifurcação na página Arquivos de Repositório do Azure Repos.

Para obter informações sobre como bifurcar um Repositório do GitHub, consulte Bifurcar um repositório.

Clonar o fork localmente

Depois de bifurcar um repositório, clone a bifurcação para criar uma cópia local em uma pasta no seu computador. Você pode clonar da linha de comando ou usando um IDE como o Visual Studio. Para obter mais informações sobre como clonar um repositório, consulte Clonar um Repositório do Git existente.

Quando você clona um repositório remoto, o Git atribui o alias origin como abreviação para a URL do repositório remoto clonado. Para conveniência, adicione outro alias chamado upstream para o repositório do qual você bifurcou, que é chamado de repositório upstream. As etapas a seguir descrevem como instalar um alias upstream.

Dica

Para sua conveniência, você pode usar os aliases origin e upstream em vez de suas URLs correspondentes em seus comandos Git.

Para adicionar um alias upstream no Visual Studio, siga estas etapas:

  1. Escolha Ferramentas > Opções na barra de menus para abrir a janela Opções. Selecione Controle do Código-Fonte > Configurações do Repositório do Git> Remotos e escolha Adicionar para abrir a caixa de diálogo Adicionar Remoto.

    Captura de tela do botão Adicionar no painel Remotos do submenu Configurações do Repositório do Git do menu Controle do Código-Fonte no Visual Studio 2019.

  2. Na caixa de diálogo Adicionar Remoto, adicione um novo remoto chamado upstream e insira a URL de clone do Git do repositório bifurcado. Em seguida, escolha Salvar.

    Captura de tela da caixa de diálogo Adicionar Remoto no Visual Studio 2019.

Enviar alterações locais por push para a sua bifurcação

Ao bifurcar, você cria uma versão pessoal do repositório original (o repositório original é chamado de "upstream"). A bifurcação é independente do upstream, mas compartilha o código e retém um link para o upstream, permitindo a sincronização futura. Portanto, não há nada que impeça você de trabalhar diretamente no branch main do clone local e, em seguida, efetuar push desse trabalho para o branch main da bifurcação. No entanto, geralmente é melhor usar branches de recursos para seu trabalho. Usando branches de recursos:

  • Você pode manter vários fluxos de trabalho independentes simultaneamente.

  • Você torna mais fácil para outras pessoas entenderem o trabalho que você compartilha porque esse trabalho é organizado em fluxos de trabalho distintos por branch.

Um fluxo de trabalho típico do Git inclui estas etapas:

  1. Criar um recurso local ou um branch de correção de bugs.

  2. Fazer alterações no novo branch e confirmar seu trabalho. Normalmente, as pessoas fazem várias confirmações ao trabalhar em um recurso ou correção de bug.

  3. Envie por push o recurso ou o branch de correção de bugs para a bifurcação. A sua bifurcação tem o alias origin.

Para obter informações sobre como efetuar push de suas alterações, consulte Compartilhar código com push.

Criar e concluir uma PR

Em Azure Repos, para mesclar no repositório original as alterações que você efetuou por push na bifurcação, você pode:

  1. Criar uma PR para solicitar revisão e aprovação de suas alterações. Ao abrir uma PR, defina o branch de origem da PR como o recurso ou o branch de correção de bugs na bifurcação. O branch de destino da PR normalmente é o branch main do repositório bifurcado. Esse repositório é chamado de repositório upstream e tem o alias upstream.

    A captura de tela a seguir mostra o repositório de origem e o branch e o repositório de destino de uma PR criada no Azure Repos.

    Captura de tela das opções de branch de origem e de destino da PR no Azure Repos.

    Para obter mais informações sobre como criar uma PR usando o navegador, o Visual Studio ou a CLI do Azure DevOps, consulte Criar uma PR.

    Importante

    Qualquer pessoa com a permissão para Ler no repositório upstream pode abrir uma PR para ele. Se o repositório upstream tiver um pipeline de build de PR configurado para ser executado na criação de PR, um build será executado nas alterações introduzidas por sua PR.

  2. Para que sua PR seja concluída, todos os revisores necessários devem aprovar as alterações de PR e todas as políticas de branch de destino devem ser atendidas. Na aprovação e conclusão da PR, as alterações no branch de origem da PR serão mescladas no branch de destino da PR.

Para obter informações sobre como criar e concluir uma PR do GitHub, consulte Criando uma solicitação de pull e Mesclando uma solicitação de pull.

Sincronizar sua bifurcação

Depois que uma PR mesclar as alterações da bifurcação no branch de destino do repositório upstream, você pode efetuar pull do branch de destino do repositório upstream para atualizar o branch local correspondente com as suas alterações e quaisquer alterações feitas por outros colaboradores. Então, você estará pronto para:

  • Criar um novo branch de recurso ou de correção de bug do branch local atualizado.

  • Atualizar a bifurcação enviando por push do seu branch local atualizado para origin.

Normalmente, o branch de destino do repositório upstream é main. Se você não estiver editando diretamente seu branch local main (você trabalha em branches de recursos), então, efetuar pull do branch upstream upstream/main atualizará seu branch local main sem conflitos de mesclagem.

Próximas etapas