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.
Se você não tiver um projeto, crie um ou crie uma conta gratuitamente.
Se você não for um membro do projeto, será adicionado.
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.
- Criar um 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
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.
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.
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.
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:
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.
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.
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:
Criar um recurso local ou um branch de correção de bugs.
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.
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:
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 aliasupstream
.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.
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.
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.