Git Feature Branch Workflow

A ideia central por detrás do Feature Branch Workflow é que todo o desenvolvimento de características deve ter lugar num ramo dedicado em vez do master ramo. Este encapsulamento facilita o trabalho de múltiplos programadores numa determinada característica sem perturbar a base de código principal. Também significa que o master ramo nunca conterá código quebrado, o que é uma enorme vantagem para ambientes de integração contínua.

Desenvolvimento de funcionalidade de encapsulamento também torna possível alavancar pedidos de puxar, que são uma forma de iniciar discussões em torno de um ramo. Eles dão a outros programadores a oportunidade de assinar uma funcionalidade antes de esta ser integrada no projecto oficial. Ou, se ficar preso no meio de uma funcionalidade, pode abrir um pedido de puxar, pedindo sugestões aos seus colegas. A questão é que os pedidos de puxar tornam incrivelmente fácil para a sua equipa comentar o trabalho uns dos outros.

O fluxo de trabalho do ramo da funcionalidade Git é um fluxo de trabalho componível que pode ser aproveitado por outros fluxos de trabalho Git de alto nível. Discutimos outros fluxos de trabalho de Git na página de síntese do fluxo de trabalho de Git. Git Feature Branch Workflow é um modelo de fluxo de trabalho centrado em ramificações, o que significa que é um quadro orientador para a gestão e criação de ramificações. Outros fluxos de trabalho são mais focalizados. O Fluxo de Trabalho de Ramo de Funcionalidade de Git pode ser incorporado noutros fluxos de trabalho. O fluxo de trabalho de Git, e o fluxo de trabalho de Git Forking usam tradicionalmente um fluxo de trabalho de ramificação de Funcionalidades Git em relação aos seus modelos de ramificação.

Como funciona

br> O fluxo de trabalho de ramificação de Funcionalidades assume um repositório central, e master representa a história oficial do projecto. Em vez de se comprometerem directamente na sua filial local master, os programadores criam uma nova filial cada vez que começam a trabalhar numa nova funcionalidade. Os ramos de funcionalidade devem ter nomes descritivos, como animated-menu-items ou issue-#1061. A ideia é dar um objectivo claro e altamente focalizado a cada ramo. Git não faz distinção técnica entre ramo e ramo de característica, para que os programadores possam editar, encenar, e submeter alterações a um ramo de característica.

Além disso, os ramos de característica podem (e devem) ser empurrados para o repositório central. Isto torna possível partilhar uma funcionalidade com outros programadores sem tocar em qualquer código oficial. Uma vez que master é o único ramo “especial”, o armazenamento de vários ramos de características no repositório central não coloca quaisquer problemas. Claro, esta é também uma forma conveniente de apoiar os compromissos locais de todos. O que se segue é uma passagem do ciclo de vida de um ramo de características.

Começa com o ramo principal

Todos os ramos de características são criados a partir do estado de código mais recente de um projecto. Este guia assume que este é mantido e actualizado no ramo master.

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

Isto muda o reporte para o ramo master, puxa os últimos commits e reinicia a cópia local do reporte de master para corresponder à versão mais recente.

Cria um novo ramo

Utiliza um ramo separado para cada característica ou edição em que trabalhe. Depois de criar um ramo, verifica-o localmente para que quaisquer alterações que faça sejam feitas nesse ramo.

git checkout -b new-feature

Isto verifica um ramo chamado new-feature baseado em master, e a bandeira -b diz a Git para criar o ramo se este ainda não existir.

Actualizar, adicionar, submeter, e empurrar alterações

Neste ramo, editar, encenar, e submeter alterações da forma habitual, construindo a funcionalidade com tantos commits quantos forem necessários. Trabalhe na funcionalidade e faça commits como faria sempre que usasse Git. Quando estiver pronto, empurre os commits, actualizando o ramo da funcionalidade no Bitbucket.

git status
git add <some-file>
git commit

Empurre o ramo da funcionalidade para o remoto

É uma boa ideia empurrar o ramo da funcionalidade para o repositório central. Isto serve como uma cópia de segurança conveniente, ao colaborar com outros programadores, isto dar-lhes-ia acesso para ver os compromissos para o novo ramo.

Este comando empurra o novo ramo para o repositório central (origem), e a bandeira -u adiciona-o como um ramo de localização remota. Após configurar o ramo de rastreio, git push pode ser invocado sem quaisquer parâmetros para empurrar automaticamente o ramo de novas-faracterísticas para o repositório central. Para obter feedback sobre o novo ramo de características, criar um pedido pull numa solução de gestão de repositório como Bitbucket Cloud ou Bitbucket Server. A partir daí, pode adicionar revisores e certificar-se de que tudo está bem antes da fusão.

Resolver feedback

Agora os colegas de equipa comentam e aprovam os commits empurrados. Resolver os seus comentários localmente, comprometer, e empurrar as alterações sugeridas para Bitbucket. As suas actualizações aparecem no pedido de extracção.

Fundir o seu pedido de extracção

Antes de fundir, poderá ter de resolver conflitos de fusão se outros tiverem feito alterações ao reporte. Quando o seu pedido de pull for aprovado e livre de conflitos, pode adicionar o seu código ao ramo master. Fundir a partir do pedido de puxar em Bitbucket.

pedidos de puxar

Para além de isolar o desenvolvimento de características, os ramos tornam possível discutir alterações através de pedidos de puxar. Quando alguém completa uma funcionalidade, não a fundem imediatamente em master. Em vez disso, empurram o ramo da funcionalidade para o servidor central e arquivam um pedido de puxar para fundir as suas adições em master. Isto dá a outros programadores uma oportunidade de rever as alterações antes de se tornarem parte da base principal de código.

A revisão de código é um grande benefício dos pedidos pull, mas na realidade são concebidos para serem uma forma genérica de falar sobre código. Pode-se pensar em pedidos de extracção como uma discussão dedicada a um ramo em particular. Isto significa que também podem ser utilizados muito mais cedo no processo de desenvolvimento. Por exemplo, se um programador precisar de ajuda com uma característica específica, tudo o que tem de fazer é apresentar um pedido de puxar. As partes interessadas serão notificadas automaticamente, e poderão ver a questão mesmo ao lado dos compromissos relevantes.

Após a aceitação de um pedido pull, o acto real de publicar uma funcionalidade é muito semelhante ao do Fluxo de Trabalho Centralizado. Primeiro, é necessário certificar-se de que o seu master está sincronizado com o upstream master. Depois, funde o ramo de características em master e empurre o ramo actualizado master de volta para o repositório central.

Os pedidos de puxar podem ser facilitados por soluções de gestão de repositório de produtos como Bitbucket Cloud ou Bitbucket Server. Ver a documentação dos pedidos de pull do Bitbucket Server para um exemplo.

Exemplo

O seguinte é um exemplo do tipo de cenário em que um fluxo de trabalho de ramificação de características é utilizado. O cenário é o de uma equipa que faz uma revisão de código num novo pedido de extracção de funcionalidade. Este é um exemplo dos muitos propósitos para os quais este modelo pode ser utilizado.

Mary começa uma nova funcionalidade

Antes de começar a desenvolver uma funcionalidade, Mary precisa de uma ramificação isolada para trabalhar. Ela pode solicitar um novo ramo com o seguinte comando:

git checkout -b marys-feature master

Isto verifica um ramo chamado marys-feature baseado em master, e a bandeira -b diz a Git para criar o ramo se este ainda não existir. Neste ramo, Mary edita, encena e comete alterações da forma habitual, construindo a sua característica com tantos commits quantos forem necessários:

git status
git add <some-file>
git commit

Mary vai almoçar

p>Mary adiciona alguns commits à sua característica ao longo da manhã. Antes de partir para o almoço, é uma boa ideia empurrar o seu ramo de reportagem até ao repositório central. Isto serve de apoio conveniente, mas se Mary estivesse a colaborar com outros criadores, isto também lhes daria acesso aos seus commits iniciais.

git push -u origin marys-feature

Este comando empurra marys-feature para o repositório central (origem), e a bandeira -u adiciona-a como um ramo de localização remota. Após configurar o ramo de localização, Mary pode chamar git push sem quaisquer parâmetros para empurrar a sua característica.

Mary termina a sua característica

Quando Mary volta do almoço, ela completa a sua funcionalidade. Antes de a fundir em master, ela precisa de apresentar um pedido de puxar para que o resto da equipa saiba que já o fez. Mas primeiro, deve certificar-se de que o repositório central tem os seus compromissos mais recentes:

git push

Então, ela arquiva o pedido de extracção na sua GUI Git pedindo para fundir marys-feature em master, e os membros da equipa serão notificados automaticamente. O melhor dos pedidos de puxar é que eles mostram comentários mesmo ao lado dos seus compromissos relacionados, por isso é fácil fazer perguntas sobre conjuntos de alterações específicas.

A factura recebe o pedido de puxar

p>Bill recebe o pedido de puxar e dá uma olhadela emmarys-feature.Decide que quer fazer algumas alterações antes de o integrar no projecto oficial, e ele e Mary têm algumas costas e verso através do pedido de puxar.

Mary faz as alterações

p> Para fazer as alterações, Mary usa exactamente o mesmo processo que usou para criar a primeira iteração da sua característica. Ela edita, encena, compromete, e empurra actualizações para o repositório central. Toda a sua actividade aparece no pedido de extracção, e Bill ainda pode fazer comentários pelo caminho.

Se quisesse, Bill poderia puxar marys-feature para o seu repositório local e trabalhar nele por conta própria. Qualquer compromisso que ele adicionasse também apareceria no pedido de extracção.

Mary publica a sua característica

p>Once Bill está pronto para aceitar o pedido de puxar, alguém precisa de fundir a característica no projecto estável (isto pode ser feito por Bill ou Mary):

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

Este processo resulta frequentemente num compromisso de fusão. Alguns programadores gostam disto porque é como uma junção simbólica da funcionalidade com o resto da base de código. Mas, se for parcial a um histórico linear, é possível rebasear a funcionalidade na ponta de master antes de executar a fusão, resultando numa fusão rápida.

algumas GUI’s irão automatizar o processo de aceitação do pedido de puxar, executando todos estes comandos apenas clicando num botão “Aceitar”. Se o seu não o fizer, deverá pelo menos ser capaz de fechar automaticamente o pedido de pull quando o ramo de funcionalidade for fundido em master.

Meanwhile, John está a fazer exactamente a mesma coisa

Enquanto Mary e Bill estão a trabalhar na funcionalidade de marys-feature e a discuti-la no seu pedido de pull, John está a fazer exactamente a mesma coisa com o seu próprio ramo de funcionalidade. Ao isolar as características em ramos separados, todos podem trabalhar independentemente, mas ainda é trivial partilhar as mudanças com outros criadores quando necessário.

Resumo

br> Neste documento, discutimos o fluxo de trabalho do ramo de características de Git. Este fluxo de trabalho ajuda a organizar e seguir os ramos que estão concentrados em conjuntos de características do domínio empresarial. Outros fluxos de trabalho de Git como o fluxo de trabalho de Git Forking e o fluxo de trabalho de Gitflow são redireccionados e podem alavancar o fluxo de trabalho de ramificações de Git Feature para gerir os seus modelos de ramificação. Este documento demonstrou um exemplo de código de alto nível e um exemplo fictício para a implementação do Fluxo de Trabalho do Ramo de Funcionalidades de Git. Algumas associações chave a fazer com o Fluxo de Trabalho de Ramo de Funcionalidade são:

• focused on branching patterns
• pode ser alavancado por outros fluxos de trabalho repo orientados
• promover a colaboração com os membros da equipa através de pedidos de puxar e fundir revisões

/ul>

Utilizar a rebase de git durante as fases de revisão e fusão de um ramo de funcionalidade criará uma história coesa de fusão de funcionalidades Git. Um modelo de ramificação de características é uma grande ferramenta para promover a colaboração dentro de um ambiente de equipa.

Vá um clique mais fundo nos fluxos de trabalho de Git lendo o nosso tutorial abrangente do fluxo de trabalho de Gitflow.