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 branch principal. Esse encapsulamento facilita para vários desenvolvedores trabalharem em um recurso particular sem perturbar a base de código principal. Isso também significa que a ramificação mestra 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 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 de recursos, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em um branch de recurso.

Além disso, as ramificações de recursos podem (e devem) ser enviadas para o repositório central. Isso possibilita compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial. Uma vez que mestre é 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.

Inicie com o branch 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 isso seja mantido e atualizado na branch principal.

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

Isso muda o repositório para a 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 uma ramificação chamada novo recurso com base no mestre 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 um novo recurso 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 de novos recursos ao repositório central. Para obter feedback sobre o novo branch de recursos, crie uma solicitação pull em uma solução de gerenciamento de repositório, como o Bitbucket Cloud ou 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 pull request é aprovada e não tem conflitos, você pode adicionar código à branch principal. Mesclar a partir da pull request no Bitbucket.

Solicitações pull

Além de isolar o desenvolvimento de recursos, as ramificações possibilitam discutir alterações por meio de pull requests. Quando alguém conclui um recurso, ele não é mesclado de imediato no mestre. Em vez disso, eles enviam a ramificação de recursos ao servidor central e arquivam uma pull request solicitando mesclar as adições no mestre. Isso dá a outros desenvolvedores 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.

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 uma ramificação chamada marys-feature com base no mestre, e a marcação -b diz ao Git para criar a ramificação, se ainda não existir. Nessa ramificação, Mary edita, organiza e faz commit das alterações da maneira usual, 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 completa o recurso. Antes de fazer a mesclagem no mestre, ela precisa registrar uma pull request 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 pull request na GUI do Git, solicitando a mesclagem do marys-feature no mestre, e os membros da equipe vão ser notificados direto. O melhor das pull requests é 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 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 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 mestre antes de executar a mesclagem, resultando em uma mesclagem de avanço rápido.

Algumas GUIs automatizam o processo de aceitação de pull request executando todos esses comandos apenas clicando no botão "Aceitar". Se não for o caso, ele deve pelo menos conseguir fechar direto a pull request quando a ramificação de recursos for mesclada no mestre.

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.