A ideia principal por trás do fluxo de trabalho do branch de recursos é que todo o desenvolvimento de recursos deve ocorrer em um branch dedicado, em vez do branch principal. Esse encapsulamento facilita o trabalho de vários desenvolvedores em um recurso específico sem interromper a principal base de código. Significa também que o branch principal nunca vai conter um 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 do branch 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 do branch do recurso Git é focado no modelo de branch, o que significa que é uma estrutura orientadora para gerenciar e criar branches. Outros fluxos de trabalho são mais focados em repositórios. O fluxo de trabalho do branch de recurso do Git pode ser incorporado a outros fluxos de trabalho. Os fluxos de trabalho Gitflow e o Git Forking como de costume usam um fluxo de trabalho do branch de recurso Git em relação a seus modelos de branch.

Como funciona

O fluxo de trabalho do branch de recursos assume um repositório central e o branch principal representa o histórico oficial do projeto. Em vez de fazer o commit no branch principal local, os desenvolvedores criam um novo branch sempre que começam a trabalhar em um novo recurso. Os branches 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 branch. O Git não faz distinção técnica entre o branch principal e os recursos, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em um branch de recurso.
 

Além disso, os branches de recursos podem (e devem) ser enviados para o repositório central. Isso torna possível compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial. Uma vez que o branch principal é o única branch "especial", o armazenamento de vários branches de recursos no repositório central não apresenta problemas. Com certeza essa também é uma maneira conveniente de fazer backup dos commits locais de todos. A seguir, é apresentado um passo a passo do ciclo de vida de um branch de recurso.

Inicie com o branch principal

Todos os branches de recursos são criados a partir do último estado de código de um projeto. Este guia pressupõe que isso seja mantido e atualizado no branch principal.

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

Isso muda o repositório para o branch principal, obtém os commits mais recentes e redefine a cópia local do repositório mestre 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

Isso verifica um branch chamado novo recurso com base no branch principal, e o sinalizador -b indica para o Git criar o branch, se ele 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 um novo recurso ao repositório central (origem) e o sinalizador -u o adiciona como um branch de rastreamento remoto. Depois de configurar o branch de rastreamento, o git push pode ser solicitado sem nenhum parâmetro para enviar direto o branch de novos recursos ao repositório central. Para obter feedback sobre o novo branch de recursos, crie uma solicitação pull em um em uma solução de gerenciamento de repositório como o Bitbucket Cloud o Bitbucket Server. A partir daí, você pode adicionar revisores e garantir que tudo esteja correto antes de mesclar.

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 mesclar, talvez seja necessário resolver conflitos de mesclagem 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 ao branch principal. Mesclar a partir da solicitação pull no Bitbucket.

Solicitações pull

Além de isolar o desenvolvimento de recursos, os branches possibilitam discutir alterações por meio de solicitações pull. Quando alguém conclui um recurso, ele não é mesclado de imediato no branch principal. Em vez disso, eles enviam o branch do recurso ao servidor central e arquivam uma solicitação pull solicitando mesclar as adições no branch principal. Isso dá a outros desenvolvedores a oportunidade de revisar as alterações antes que elas se tornem parte da principal base de código.

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 o mestre local esteja sincronizado com o master upstream. Em seguida, você mescla o branch do recurso no mestre e envia o push mestre atualizado 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 master

Isso verifica um branch chamado marys-feature com base no mestre e o sinalizador -b diz ao Git para criar o branch, se ele ainda não existir. Nesse branch, Mary edita, organiza e faz o commit das alterações da maneira usual, desenvolvendo recurso com o número de commits necessários:

git status
git add <some-file>
git commit

Mary sai para almoçar

Mary acrescenta alguns commits ao recurso ao longo da manhã. Antes de ela sair para almoçar, é uma boa ideia enviar o branch de recursos ao repositório central. Isso serve como um backup conveniente, mas se Mary estivesse colaborando com outros desenvolvedores, isso também daria acesso a commits iniciais feitos por ela.

x

git push -u origin marys-feature

Este comando envia o marys-feature para o repositório central (origem), e o sinalizador -u o adiciona como um branch de rastreamento remoto. Depois de configurar o branch de rastreamento, Mary pode solicitar o git push sem nenhum parâmetro para enviar recurso.

Mary termina o recurso

Quando Mary volta do almoço, ela completa o recurso. Antes de fazer a mesclagem no branch 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 arquiva a solicitação pull na GUI do Git, solicitando a fusão do marys-feature no branch 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, por isso é fácil fazer perguntas sobre conjuntos de alterações específicos.

Bill recebe a solicitação pull

Bill recebe a solicitação pull 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 solicitação pull.

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 solicitação pull.

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 master
git pull
git pull origin marys-feature
git push

Esse processo em geral resulta em um commit de mesclagem. 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 refazer o recurso na extremidade do branch principal antes de executar a mesclagem, resultando em uma mesclagem 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, ele deve pelo menos conseguir fechar direto a solicitação pull quando o branch do recurso for mesclado no branch principal.

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 branch
• podem ser aproveitados por outros fluxos de trabalho orientados para repositórios
• promove a colaboração com os membros da equipe por meio de solicitações pull e análises de mesclagem

Utilizar o git rebase durante os estágios de revisão e mesclagem de um branch de recursos vai criar um histórico coeso do Git de mesclagens de recursos. Um modelo de branch 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.