Fluxo de trabalho de um branch de recurso do Git

A ideia central por trás do Fluxo de trabalho de ramificação de recursos é que todo desenvolvimento de recursos deve ocorrer em uma ramificação dedicada em vez de na ramificação principal. Esse encapsulamento facilita para vários desenvolvedores trabalharem em um recurso particular sem perturbar a base de código principal. Além disso, ele indica que a ramificação principal nunca deve conter código quebrado, o que é uma enorme vantagem para ambientes de integração contínua.

Encapsular o desenvolvimento de recursos também permite aproveitar solicitações pull, que são uma maneira de iniciar discussões em torno de um branch. Eles dão a outros desenvolvedores a oportunidade de aprovar um recurso antes que ele seja integrado ao projeto oficial. Ou, se você ficar preso no meio de um recurso, vai poder abrir uma solicitação de recebimento pedindo sugestões de seus colegas. O ponto é que as solicitações pull tornam muito fácil para a equipe comentar sobre o trabalho um do outro.

O fluxo de trabalho da ramificação de recursos do Git é um fluxo de trabalho que pode ser aproveitado por outros fluxos de trabalho de alto nível do Git. Discutimos outros fluxos de trabalho do Git na página de visão geral do fluxo de trabalho do Git. O fluxo de trabalho da ramificação de recursos do Git é focado no modelo de ramificação, o que significa que é uma estrutura orientadora para gerenciar e criar ramificações. Outros fluxos de trabalho são mais focados em repositórios. O fluxo de trabalho da ramificação de recursos do Git pode ser incorporado em outros fluxos de trabalho. Os fluxos de trabalho Gitflow e o Git Forking Workflows como de costume usam um fluxo de trabalho da ramificação de recursos do Git em relação a seus modelos de ramificação.

Como funciona

O fluxo de trabalho da ramificação de recursos pressupõe um repositório central, e a ramificação principal representa o histórico oficial do projeto. Em vez de fazer o commit direto na ramificação principal local, os desenvolvedores criam uma nova ramificação sempre que começam a trabalhar em um novo recurso. As ramificações dos recursos devem ter nomes descritivos, como itens-de-menu-animados ou problema-#-1061. A ideia é dar um objetivo claro e bastante focado a cada ramificação. O Git não faz distinção técnica entre a ramificação principal e as de recursos, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em uma ramificação de recurso.

Além disso, as ramificações de recursos podem (e devem) ser enviadas para o repositório central. Assim é possível compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial. Uma vez que a principal é a única ramificação “especial”, o armazenamento de várias ramificações de recursos no repositório central não apresenta problemas. Com certeza, essa também é uma maneira conveniente de fazer backup das commits locais de todos. A seguir, é apresentado um passo a passo do ciclo de vida de uma ramificação de recursos.

Comece com a ramificação principal

Todas as ramificações de recursos são criadas a partir do último estado de código de um projeto. Este guia pressupõe que a manutenção e a atualização disso sejam feitas na ramificação principal.

git checkout main
git fetch origin 
git reset --hard origin/main

Essa ação muda o repositório para a ramificação principal, obtém os commits mais recentes e redefine a cópia local do repositório principal para corresponder à versão mais recente.

Criar um novo branch

Use um branch separado para cada recurso ou problema em que você trabalha. Depois de criar um branch, verifique-o no local para que todas as alterações que você fizer sejam nesse branch.

git checkout -b new-feature

Essa ação verifica uma ramificação chamada new-feature com base na principal, e a marcação -b indica para o Git criar a ramificação, se ainda não existir.

Atualizar, adicionar, fazer o commit enviar por push as alterações

Nesse branch, edite, prepare e faça os commits das alterações da maneira usual, construindo o recurso com o número de commits necessários. Trabalhe no recurso e faça commits como faria sempre que usa o Git. Quando estiver pronto, envie os commits, atualizando o branch de recursos no Bitbucket.

git status
git add <some-file>
git commit

Enviar branch do recurso para remoto

É uma boa ideia enviar o branch do recurso para o repositório central. Isso serve como um backup conveniente, ao colaborar com outros desenvolvedores, e lhes daria acesso para visualizar commits para o novo branch.

git push -u origin new-feature

Esse comando envia a new-feature ao repositório central (origem) e a marcação -u o adiciona como uma ramificação de rastreamento remoto. Depois de configurar a ramificação de rastreamento, o git push pode ser solicitado sem nenhum parâmetro para enviar direto a ramificação new-feature ao repositório central. Para obter feedback sobre a ramificação de novo recurso, crie uma solicitação pull em uma solução de gerenciamento de repositório, como o Bitbucket Cloud ou o Bitbucket Data Center. A partir daí, você pode adicionar revisores e garantir que tudo esteja correto antes de fazer o merge.

Resolver Feedback

Agora, os colegas de equipe comentam e aprovam os commits enviados. Esclareça seus comentários no local, faça o commit e envie as alterações sugeridas ao Bitbucket. As atualizações aparecem na solicitação pull.

Mesclar solicitação pull

Antes de fazer o merge, talvez seja necessário resolver conflitos de merge se outras pessoas fizerem alterações no repositório. Quando a solicitação pull é aprovada e não tem conflitos, você pode adicionar código à ramificação principal. Faça o merge a partir da solicitação pull no Bitbucket.

Solicitações pull

Além de isolar o desenvolvimento de recursos, as ramificações possibilitam discutir alterações por meio de solicitações pull. Quando alguém conclui um recurso, o merge na principal não é imediato. Em vez disso, a pessoa envia a ramificação de recursos ao servidor central e registra uma solicitação pull para fazer o merge das adições na principal. Assim os outros desenvolvedores têm a oportunidade de revisar as alterações antes que elas se tornem parte da base de código principal.

A revisão de código é um grande benefício das solicitações pull, mas elas foram projetadas para ser uma maneira genérica de falar sobre código. Você pode pensar em solicitações pull como uma discussão dedicada a um branch específico. Isso significa que eles também podem ser usados muito antes no processo de desenvolvimento. Por exemplo, se um desenvolvedor precisar de ajuda com um recurso específico, tudo o que precisa fazer é registrar uma solicitação pull. As partes interessadas vão ser notificadas direto e podem ver a pergunta ao lado dos commits relevantes.

Depois que uma solicitação pull é aceita, o ato real de publicar um recurso é quase o mesmo que no Fluxo de trabalho centralizado. Primeiro, você precisa garantir que a principal local esteja sincronizada com a principal upstream. Em seguida, você faz o merge da ramificação do recurso na principal e envia a principal atualizada de volta ao repositório central.

Solicitações pull podem ser facilitadas por soluções de gerenciamento de repositório de produtos, como o Bitbucket Cloud ou Bitbucket Server. Veja a documentação de solicitações pull do Bitbucket Server para ter um exemplo.

Exemplo

A seguir, é apresentado um exemplo do tipo de cenário no qual um fluxo de trabalho de branch de recurso é usado. O cenário é o de uma equipe fazendo uma revisão de código em uma solicitação pull de novo recurso. Este é um exemplo das muitas finalidades em que este modelo pode ser usado.

Mary desenvolve um novo recurso

Antes de começar a desenvolver um recurso, Mary precisa de um branch isolado para trabalhar. Ela pode solicitar um novo branch com o seguinte comando:

 git checkout -b marys-feature main

Essa ação verifica uma ramificação chamada marys-feature com base na principal, e a marcação -b diz ao Git para criar a ramificação, se ainda não existir. Nessa ramificação, Mary edita, prepara e faz commit das alterações da maneira normal, desenvolvendo seu recurso com o número de commits necessários:

git status
git add <some-file>
git commit

Mary sai para almoçar

Mary adiciona algumas confirmações ao recurso ao longo da manhã. Antes de sair para almoçar, é uma boa ideia enviar o branch de recursos ao repositório central. É como um backup conveniente, mas se Mary estivesse colaborando com outros desenvolvedores, também possibilitaria o acesso deles a commits iniciais feitos por ela.

git push -u origin marys-feature

Este comando envia o marys-feature para o repositório central (origem), e a marcação -u o adiciona como uma ramificação de rastreamento remoto. Depois de configurar a ramificação de rastreamento, Mary pode solicitar o git push sem nenhum parâmetro para enviar seu recurso.

Mary termina o recurso

Quando Mary volta do almoço, ela conclui o recurso. Antes de fazer o merge na principal, ela precisa registrar uma solicitação pull informando o restante da equipe que ela terminou. Mas primeiro ela deve garantir que o repositório central tenha os commits mais recentes:

Git push

Em seguida, ela registra a solicitação pull na GUI do Git, solicitando o merge da marys-feature na principal, e os membros da equipe vão ser notificados direto. O melhor das solicitações pull é que elas mostram comentários ao lado dos commits relacionados, então é fácil fazer perguntas sobre conjuntos de alterações específicos.

Bill recebe a solicitação pull

Bill recebe a pull request e analisa o marys-feature. Ele decide se tem interesse em fazer algumas alterações antes de integrá-lo ao projeto oficial, e ele e Mary conversam sobre alterações por meio da da pull request.

Mary faz as alterações

Para fazer as alterações, Mary usa sempre o mesmo processo que usou para criar a primeira iteração de recurso. Ela edita, organiza, faz o commit e envia atualizações para o repositório central. Toda a atividade dela aparece na solicitação pull, e Bill ainda pode fazer comentários.

Se ele quisesse, Bill poderia enviar o marys-feature no repositório local e trabalhar sozinho. Quaisquer commits adicionados também apareceriam na pull request.

Mary publica o recurso

Quando Bill estiver pronto para aceitar a solicitação pull, alguém vai mesclar o recurso no projeto estável (isso pode ser feito por Bill ou Mary):

git checkout main
git pull
git pull origin marys-feature
git push

Esse processo em geral resulta em um commit de merge. Alguns desenvolvedores gostam disso porque é como uma união simbólica do recurso com o restante da base do código. Mas, se você prefere um histórico linear, é possível fazer o rebase do recurso na extremidade da principal antes de executar o merge, resultando em um merge de avanço rápido.

Algumas GUIs automatizam o processo de aceitação de solicitação pull executando todos esses comandos apenas clicando no botão "Aceitar". Se não for o caso, ela deve pelo menos conseguir fechar direto a solicitação pull quando o merge da ramificação de recursos na principal for feito.

Enquanto isso, John está fazendo a mesma coisa

Enquanto Mary e Bill estão trabalhando no marys-feature e discutindo isso na solicitação pull, John está fazendo a mesma coisa com seu próprio branch de recursos. Ao isolar os recursos em branches separados, todos podem trabalhar com independência, mas ainda é essencial compartilhar alterações com outros desenvolvedores quando necessário.

Resumo

Neste documento, discutimos o fluxo de trabalho do branch de recurso do Git. Esse fluxo de trabalho ajuda a organizar e rastrear branches focados nos conjuntos de recursos do domínio comercial. Outros fluxos de trabalho do Git, como o Git Forking Workflow e o Gitflow Workflow, são focados em repositórios e podem aproveitar o fluxo de trabalho do branch de recurso do Git para gerenciar modelos de branch. Este documento demonstrou um exemplo de código de alto nível e um exemplo fictício para implementar o fluxo de trabalho do branch de recurso no Git. Algumas associações importantes a serem feitas com o fluxo de trabalho do branch de recurso do Git são:

• focados nos padrões de ramificação
• podem ser aproveitados por outros fluxos de trabalho orientados para repositórios
• promove a colaboração com os membros da equipe por meio de pull requests e análises de mesclagem

Utilizar o git rebase durante os estágios de revisão e mesclagem de uma ramificação de recursos vai criar um histórico coeso do Git de mesclagens de recursos. Um modelo de ramificação de recursos é uma ótima ferramenta para promover a colaboração em um ambiente de equipe.

Vá mais fundo nos fluxos de trabalho do Git lendo o tutorial abrangente do Fluxo de trabalho Gitflow.