Fluxo de trabalho de uma ramificação de funções do Git
A ideia central por trás do Fluxo de trabalho de ramificação de funções é que todo desenvolvimento de funções deve ocorrer em uma ramificação dedicada em vez de na ramificação principal. Esse encapsulamento facilita para vários desenvolvedores trabalharem em uma função 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 funções também permite aproveitar solicitações pull, que são uma maneira de iniciar discussões em torno de uma ramificação. Eles dão a outros desenvolvedores a oportunidade de aprovar uma função antes que ela seja integrada ao projeto oficial. Ou, se você ficar preso no meio de uma função, 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 funções 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 funções 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 funções 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 funções do Git em relação a seus modelos de ramificação.
Como funciona
O fluxo de trabalho da ramificação de funções 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 uma nova função. As ramificações de recurso devem ter nomes descritivos, como itens-de-menu-animados ou item-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 funções, então os desenvolvedores podem editar, preparar e fazer o commit de alterações em uma ramificação de função.
Além disso, as ramificações de funções podem (e devem) ser enviadas para o repositório central. Assim é possível compartilhar uma função 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 funções 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 funções.
Comece com a ramificação principal
Todas as ramificações de funções 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.
Material relacionado
Log avançado do Git
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainCriar o repositório
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 função 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 nessa ramificação.
git checkout -b new-featureEssa 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 a função com o número de commits necessários. Trabalhe na função e faça commits como faria sempre que usa o Git. Quando estiver pronto, envie os commits, atualizando a ramificação de funções no Bitbucket.
git status
git add <some-file>
git commitEnviar ramificação de funções para remoto
É uma boa ideia enviar a ramificação de funções 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-featureEsse 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 nova ramificação de funções, 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 funções, as ramificações possibilitam discutir alterações por meio de solicitações pull. Quando alguém conclui uma função, o merge na principal não é imediato. Em vez disso, a pessoa envia a ramificação de funções 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 uma função específica, 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 uma função é 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 de funções na principal e envia a principal atualizada de volta ao repositório central.
As pull requests podem ser viabilizadas por soluções de gerenciamento de código-fonte, como o Bitbucket Cloud.
Exemplo
A seguir, é apresentado um exemplo do tipo de cenário no qual um fluxo de trabalho de ramificação de funções é usado. O cenário é o de uma equipe fazendo uma revisão de código em uma solicitação pull de nova função. Este é um exemplo das muitas finalidades em que este modelo pode ser usado.
Mary desenvolve uma nova função
Antes de começar a desenvolver uma função, Mary precisa de uma ramificação isolada para trabalhar. Ela pode solicitar uma nova ramificação com o seguinte comando:
git checkout -b marys-feature mainEssa 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 sua função com o número de commits necessários:
git status
git add <some-file>
git commitMary sai para almoçar
.svg?cdnVersion=2429)
Mary adiciona algumas confirmações à função ao longo da manhã. Antes de sair para almoçar, é uma boa ideia enviar a ramificação de funções 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-featureEste 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 função.
Mary termina a função
Quando Mary volta do almoço, ela conclui a função. 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 pushEm 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
.svg?cdnVersion=2429)
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
.svg?cdnVersion=2429)
Para fazer as alterações, Mary usa sempre o mesmo processo que usou para criar a primeira iteração de função. 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 a função
Quando Bill estiver pronto para aceitar a solicitação pull, alguém vai mesclar a função no projeto estável (isso pode ser feito por Bill ou Mary):
git checkout main
git pull
git pull origin marys-feature
git pushEsse processo em geral resulta em um commit de merge. Alguns desenvolvedores gostam disso porque é como uma união simbólica da função com o restante da base do código. Mas, se você prefere um histórico linear, é possível fazer o rebase da função 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 funções 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 sua própria ramificação. Ao isolar as funções em ramificações separadas, todos podem trabalhar com independência, mas ainda é essencial compartilhar alterações com outros desenvolvedores quando necessário.
Resumo
Neste documento, a gente discute o fluxo de trabalho de ramificação de recurso do Git. Esse fluxo de trabalho ajuda a organizar e rastrear ramificações voltadas para conjuntos de funções de domínio comercial. Outros fluxos de trabalho do Git, como o de bifurcação e o do Gitflow, são voltados a repositórios e podem aproveitar o fluxo de trabalho de ramificação de recurso do Git para gerenciar os modelos de ramificação. Este documento demonstrou um exemplo de código de alto nível e um exemplo fictício para implementar o fluxo de trabalho de ramificação de recurso do Git. Algumas considerações importantes sobre o fluxo de trabalho de ramificação de recurso:
- 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 funções vai criar um histórico coeso do Git de mesclagens de funções. Um modelo de ramificação de funções é 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.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
