Forks

  • Artigo

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

Visual Studio 2019 | Visual Studio 2022

Os forks de repositório Git são úteis quando as pessoas querem fazer alterações experimentais, arriscadas ou ocultas em uma base de código, mas essas alterações precisam ser isoladas da base de código no repositório original. Um novo fork é 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 bifurcação, como a adição de commits ou ramificações, ficam ocultas do repositório original. Se você quiser mesclar as alterações da base de código no repositório original, deverá criar uma solicitação pull (PR) para solicitar revisão e aprovação dessas alterações.

O processo de bifurcação não transfere permissões, políticas ou pipelines de construção do repositório original para a 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 nos repositórios do GitHub.

Neste artigo, vai aprender a:

  • Compartilhar código entre bifurcações
  • Escolha entre ramos e garfos
  • Ativar garfos de recompra
  • Criar um fork
  • Clonar o seu fork localmente
  • Empurre as alterações locais para a sua bifurcação
  • Criar e concluir um RP
  • Sincronize a sua bifurcação

Pré-requisitos para acesso ao Azure Repos

  • Os repositórios devem ser habilitados em suas configurações de projeto do Azure DevOps. Se o hub Repos e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço de DevOps do Azure para reativar Repos.

  • Para exibir 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 visualizar o código.

  • Para clonar ou contribuir com o código de 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, consulte O que é um projeto público?

    Nota

    Para projetos públicos, os usuários com acesso de Partes Interessadas têm acesso total aos Repositórios do Azure.

  • Os repositórios devem ser habilitados em suas configurações de projeto do Azure DevOps. Se o hub Repos e as páginas associadas não forem exibidos, consulte Ativar ou desativar um serviço de DevOps do Azure para reativar Repos.

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

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

Compartilhar código entre bifurcações

O repositório original é muitas vezes referido como o repo a montante . Você pode criar PRs para mesclar alterações em qualquer direção: de fork para upstream, ou upstream para fork. A direção mais comum é da bifurcação para montante. As permissões, políticas, compilações e itens de trabalho do repositório de destino serão aplicados ao PR.

Escolha entre ramos e garfos

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 ramificações de recursos e as políticas de ramificação podem proteger a ramificação padrão. No entanto, se sua equipe expandir e superar esse arranjo, eles poderão mudar para um fluxo de trabalho de bifurcação.

Se o seu repositório tiver um grande número de committers casuais ou pouco frequentes, como um projeto de código aberto pode, recomendamos o fluxo de trabalho de bifurcação. Normalmente, apenas os contribuidores principais do seu projeto devem ter direitos de confirmação direta para o seu repositório original. Outros colaboradores devem usar um fluxo de trabalho de bifurcação para isolar as alterações propostas até que os colaboradores principais tenham a chance de revisar seu trabalho.

Ativar garfos de recompra

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

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

O fluxo de trabalho de bifurcação

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

  1. Criar uma bifurcação
  2. Clone seu garfo localmente
  3. Empurre as alterações locais para a sua bifurcação
  4. Criar e concluir um RP
  5. Sincronize a sua bifurcação

Criar um fork

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

Nota

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

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

    Captura de ecrã do item de menu Forquilha no menu Mais ações na página Repo Files no Azure Repos.

  2. Na caixa de diálogo Bifurcação, nomeie o repositório bifurcado, escolha o projeto onde deseja que a bifurcação seja criada, selecione as ramificações a serem incluídas na bifurcação e escolha Bifurcação. Você pode especificar se a bifurcação conterá todas as ramificações ou apenas a ramificação padrão. Se o repositório contiver várias ramificações de tópico, considere incluir apenas a ramificação padrão em sua bifurcação.

    Captura de ecrã da caixa de diálogo Fork na página Repo Files no Azure Repos.

Para obter informações sobre como bifurcar um repositório GitHub, consulte Fork a repo.

Clonar o seu fork localmente

Depois de bifurcar um repositório, clone a bifurcação para criar uma cópia local em uma pasta no computador. Você pode clonar a partir 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 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. Por conveniência, adicione outro alias nomeado upstream para o repositório do qual você se bifurcou, que é conhecido como repositório upstream. As etapas a seguir descrevem como adicionar um upstream alias.

Gorjeta

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

Para adicionar um upstream alias no Visual Studio, siga estes passos:

  1. Escolha Opções de Ferramentas > na barra de menus para abrir a janela Opções. Selecione Source Control > Git Repository Settings > Remotes (Configurações remotas do repositório Git de controle do código-fonte) e escolha Adicionar para abrir a caixa de diálogo Adicionar remoto .

    Captura de tela do botão Adicionar no painel Controles remotos do submenu Configurações do repositório Git do menu Controle do código-fonte no Visual Studio 2019.

  2. Na caixa de diálogo Adicionar remoto, adicione um novo controle 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.

Empurre as alterações locais para a sua bifurcação

Ao bifurcar, você cria uma versão pessoal do repositório original (o repositório original é chamado de "upstream"). O fork é independente do upstream, mas o fork compartilha o código e mantém um link para o upstream, permitindo uma sincronização futura. Então, não há nada que impeça você de trabalhar diretamente no ramo do clone local e, em main seguida, empurrar esse trabalho para o main ramo do seu garfo. No entanto, geralmente é melhor usar ramificações de recursos para o seu trabalho. Usando ramificações de recursos:

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

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

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

  1. Crie um recurso local ou ramificação de correção de bug.

  2. Faça alterações na nova ramificação e comprometa seu trabalho. Normalmente, as pessoas fazem várias confirmações ao trabalhar em um recurso ou correção de bug.

  3. Empurre o recurso ou a ramificação de correção de bug para a bifurcação. Sua bifurcação tem o alias origin.

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

Criar e concluir um RP

No Azure Repos, para mesclar no repositório original as alterações enviadas para a bifurcação, você pode:

  1. Crie um RP para solicitar a revisão e aprovação de suas alterações. Ao abrir uma ramificação, defina a ramificação de origem de RP como a ramificação de recurso ou correção de bugs na bifurcação. A ramificação de destino PR é normalmente a main ramificação do repositório que você bifurcou. Esse acordo de recompra é referido como o acordo de recompra a montante e tem o pseudónimo upstream.

    A captura de tela a seguir mostra o repositório de origem e a ramificação e o repositório de destino e a ramificação de uma RP criada no Azure Repos.

    Captura de ecrã das opções de ramificação de origem e destino de RP no Azure Repos.

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

    Importante

    Qualquer pessoa com a permissão de leitura no repositório upstream pode abrir um PR para ele. Se o repositório upstream tiver um pipeline de compilação de RP configurado para ser executado na criação de RP, uma compilação será executada nas alterações introduzidas pelo seu PR.

  2. Para que seu RP seja concluído, todos os revisores necessários devem aprovar as alterações de RP e todas as políticas de ramificação de destino devem ser atendidas. Na aprovação e conclusão de RP, as alterações na ramificação de origem de RP serão fundidas na ramificação de destino de RP.

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

Sincronize a sua bifurcação

Depois que um PR mescla as alterações da sua bifurcação na ramificação de destino do repositório upstream, você pode extrair da ramificação de destino do repositório upstream para atualizar sua ramificação local correspondente com suas alterações e quaisquer alterações feitas por outros contribuidores. Então você está pronto para:

  • Crie um novo recurso ou ramificação de correção de bug a partir da ramificação local atualizada.

  • Atualize sua bifurcação empurrando de sua ramificação local atualizada para origin.

Normalmente, a ramificação de destino do repositório upstream é main. Se você não estiver editando diretamente sua ramificação local main (você trabalha em ramificações de recurso), retirar da ramificação upstream/main upstream atualizará sua ramificação local main sem conflitos de mesclagem.

Próximos passos

Compartilhar código com pushReview pull requests