Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022
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 no forque, como a adição de commits ou ramos, 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 fork não transfere permissões, políticas ou pipelines de build do repositório original para o seu fork.
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 forks
- Escolha entre ramos e garfos
- Ativar bifurcações de repositório
- Criar um fork
- Clonar o seu fork localmente
- Faça push das alterações locais para o seu fork.
- Criar e concluir um RP
- Sincronize o seu fork
Pré-requisitos
| Categoria | Requerimentos |
|---|---|
| Acesso ao projeto | Membro de um projeto . |
| Permissões | - Ver código em projetos privados: Acesso pelo menos Básico. - Clone ou contribua para o código em projetos privados: Membro do grupo de segurança Contributors ou permissões correspondentes no projeto. - Definir permissões de ramo ou repositório: Gerir permissões para o ramo ou repositório. - Alterar ramificação padrão: Editar políticas e permissões para o repositório. - Importar um repositório: Membro do grupo de segurança Administradores de Projeto ou com permissão de Criar repositório ao nível do projeto Git definida como Permitir. Para obter mais informações, consulte Definir permissões do repositório Git. |
| Serviços | Repos ativado. |
| Ferramentas | Opcional. Utilize os comandos az repos: Azure DevOps CLI. |
Nota
Em projetos públicos, os usuários com acesso Partes Interessadas têm acesso total aos repositórios do Azure, incluindo visualização, clonagem e contribuição para o código.
| Categoria | Requerimentos |
|---|---|
| Acesso ao projeto | Membro de um projeto . |
| Permissões | - Visualização de código: Pelo menos acesso básico. - Clone ou contribua para o código: Membro do grupo de segurança Contributors ou com permissões correspondentes no projeto. |
| Serviços | Repos ativado. |
Compartilhar código entre forks
O repositório original é muitas vezes referido como o repositório upstream. 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 a sua equipa se expandir e ultrapassar este arranjo, eles poderão mudar para um sistema de fluxo de trabalho de ramificação.
Se o seu repositório tiver um grande número de colaboradores casuais ou pouco frequentes, como num projeto de código aberto, recomendamos o fluxo de trabalho de fork. 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 bifurcações de repositório
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 secções seguintes.
- Criar uma bifurcação
- Clone o seu fork localmente
- Envie as alterações locais para o seu repositório derivado
- Criar e concluir um RP
- Sincronize o seu fork
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, tenha 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 de Criar repositório a todos os colaboradores. Para obter mais informações sobre como definir permissões, consulte Definir permissões de repositório Git.
No navegador da Web, navegue até o repositório Git do Azure Repos que você deseja bifurcar. Selecione > e, em seguida, escolha Fork no menu de reticências para abrir a caixa de diálogo Fork.
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 o fork conterá todos os ramos ou apenas o ramo padrão. Se o repositório contiver várias ramificações de tópico, considere incluir apenas a ramificação padrão no seu fork.
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 o seu fork para criar uma cópia local numa pasta do seu 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:
Escolha Ferramentas > Opções na barra de menus para abrir a janela Opções. Selecione Source Control > Git Repository Settings > Remotos (Configurações remotas do repositório Git de controle do código-fonte) e escolha Adicionar para abrir Adicionar remoto caixa de diálogo.
Na caixa de diálogo Adicionar remoto, adicione um novo controle remoto chamado
upstreame insira a URL de clone do Git do repositório bifurcado. Em seguida, escolha Salvar.
Faça push das alterações locais para o seu fork.
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 depois enviar esse trabalho para o ramo main do seu fork. No entanto, geralmente é melhor usar ramificações de recursos para o seu trabalho. Usando ramificações de funcionalidades:
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:
Crie um recurso local ou ramificação de correção de bug.
Faça alterações na nova ramificação e comete as tuas alterações. Normalmente, as pessoas fazem várias confirmações ao trabalhar em um recurso ou correção de bug.
Push a funcionalidade ou a ramificação de correção de bug para o fork. A 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:
Crie um RP para solicitar a revisão e aprovação de suas alterações. Ao abrir um Pedido de Pull, defina a ramificação de origem do Pedido de Pull como a ramificação de funcionalidade ou correção de erros no seu repositório bifurcado. A ramificação de destino PR é normalmente a
mainramificação do repositório que você bifurcou. Esse repositório é referido como o repositório upstream e tem o aliasupstream.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.
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 em Project Valid Users e com a permissão Ler no repositório upstream pode abrir um PR nele. 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.
Para que o seu PR seja concluído, todos os revisores necessários devem aprovar as alterações do PR e todas as políticas do ramo de destino devem ser cumpridas. 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 pull request do GitHub, consulte Criar um pull request e Mesclar um pull request.
Sincronize o seu fork
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 o seu fork ao fazer push da sua ramificação local atualizada para .
Normalmente, a ramificação de destino do repositório upstream é main. Se não estiveres a editar diretamente a tua ramificação local main (trabalhas em ramificações de funcionalidades), então fazer pull da ramificação upstream/main upstream atualizará a tua ramificação local main sem conflitos de mesclagem.