Explorar o fluxo de trabalho de ramificação de funcionalidades
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.
O encapsulamento facilita o trabalho de vários desenvolvedores em um recurso específico sem perturbar a base de código principal. Isso também significa que o branch principal nunca conterá código desfeito, uma grande vantagem para ambientes de integração contínua.
Encapsular o desenvolvimento de funcionalidades também possibilita o uso de pull requests, que são uma maneira de iniciar discussões sobre um branch. Eles permitem que outros desenvolvedores revisem ou aprovem um recurso antes que ele seja integrado ao projeto oficial. Ou, se você ficar preso no meio de uma funcionalidade, poderá abrir um pull request pedindo sugestões de seus colegas.
Pull requests tornam incrivelmente fácil para sua equipe comentar no trabalho uns dos outros. Além disso, os branches de funcionalidades podem (e devem) ser enviados para o repositório central. Ele permite compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial.
Como o main é o único ramo "especial", armazenar vários branches de funcionalidades no repositório central não apresenta nenhum problema. Também é uma maneira conveniente de fazer backup das confirmações locais de todos.
Fluxo de Trabalho do Branch de Release
Além do Fluxo de Trabalho de Branch de Funcionalidade, outra estratégia comumente usada nos fluxos de trabalho de ramificação do Git é a Estratégia de Release Branch. Essa estratégia envolve a criação de ramificações dedicadas especificamente para à preparação de versões. A ramificação de lançamento normalmente é criada a partir de uma ramificação de recurso estável, garantindo que ela contenha apenas código completamente testado e validado. Depois de criado, o branch de lançamento passa por testes adicionais, correções de bugs e esforços de estabilização para preparar a base de código para implantação. O branch de lançamento permite o isolamento das atividades de lançamento do desenvolvimento de recursos em andamento, fornecendo um ambiente controlado para finalizar e polir a próxima versão. Depois que todos os ajustes e verificações necessários tiverem sido feitos no branch de lançamento, ele será mesclado no branch principal ou implantado diretamente na produção, dependendo do processo de lançamento da equipe. A Estratégia do Ramo de Lançamento ajuda as equipes a gerenciar as complexidades da coordenação das atividades de lançamento, mantendo um ramo principal estável para o desenvolvimento contínuo.
Fluxo de trabalho de desenvolvimento baseado em tronco
O fluxo de trabalho de desenvolvimento baseado em tronco pressupõe um repositório central e o principal representa o histórico oficial do projeto. Em vez de se comprometerem diretamente com o branch principal local, os desenvolvedores criam uma nova ramificação sempre que começam a trabalhar em um novo recurso. As branches de funcionalidade devem ter nomes descritivos, como new-banner-images ou bug-91. A ideia é dar a cada ramificação uma finalidade clara e altamente focada.
O Git não faz distinção técnica entre os branches principais e de recursos, para que os desenvolvedores possam editar, preparar e confirmar alterações em um branch de recursos.
Criar um ramo
Quando estiver trabalhando em um projeto, você terá muitos recursos ou ideias diferentes em andamento a qualquer momento – alguns dos quais estão prontos para serem lançados e outros que não estão. O branching existe para ajudá-lo a gerenciar esse fluxo de trabalho. Ao criar um branch em seu projeto, você cria um ambiente em que pode experimentar novas ideias.
Além de criar branches para novos recursos ou correções, as equipes que seguem um fluxo de trabalho de branch de lançamento também criam branches especialmente dedicados à preparação de versões de lançamento. Essas ramificações de lançamento normalmente são derivadas de ramificações de funcionalidades estáveis para garantir que contenham código completamente testado e validado. Depois de criado, o branch de lançamento passa por testes adicionais, correções de bugs e esforços de estabilização para preparar a base de código para implantação.
Adicionar confirmações
Depois que a ramificação for criada, é hora de fazer alterações. Sempre que você adicionar, editar ou excluir um arquivo, faça uma confirmação e adicione-os ao branch.
Adicionar commits mantém registrado seu progresso enquanto você trabalha em um branch de funcionalidades.
Os commits também criam um histórico transparente do seu trabalho que outras pessoas podem seguir para entender suas ações, e por que.
Cada confirmação tem uma mensagem de confirmação associada explicando por que uma alteração específica foi feita.
Além disso, cada commit é considerado uma unidade separada de alteração. Ele permite reverter as alterações se um bug for encontrado ou você decidir ir em uma direção diferente.
As mensagens de confirmação são essenciais, especialmente porque o Git rastreia suas alterações e as exibe como confirmações depois de enviadas por push para o servidor.
Ao escrever mensagens de confirmação claras, você pode tornar mais fácil para outras pessoas acompanharem e fornecerem comentários.
Abrir uma solicitação de pull
Diagrama 
As Solicitações de Pull iniciam uma discussão sobre seus commits. Como eles estão fortemente integrados ao repositório Git subjacente, qualquer pessoa pode ver exatamente quais alterações seriam mescladas se aceitassem sua solicitação.
Você pode abrir um Pull Request a qualquer momento durante o processo de desenvolvimento quando:
- Você tem pouco ou nenhum código, mas deseja compartilhar capturas de tela ou ideias gerais.
- Você está preso e precisa de ajuda ou conselhos.
- Você está pronto para que alguém revise seu trabalho.
Usando o sistema de @mention na mensagem do seu pull request, você pode pedir feedback de pessoas ou equipes específicas, estejam elas no corredor ou a 10 fusos horários de distância.
As Solicitações de Pull ajudam a contribuir com projetos e para gerenciar alterações em repositórios compartilhados.
Se você estiver usando um modelo Fork & Pull, os Pull Requests fornecem uma maneira de notificar os mantenedores do projeto sobre as alterações que você gostaria que eles considerassem.
Se você estiver usando um modelo de repositório compartilhado, as Solicitações de Pull ajudarão a iniciar a revisão de código e a conversa sobre as alterações propostas antes de serem mescladas no branch principal.
Discutir e revisar seu código
Depois que uma Solicitação de Pull for aberta, a pessoa ou a equipe que estiver revisando suas alterações poderá ter perguntas ou comentários.
Talvez o estilo de codificação não corresponda às diretrizes do projeto, a alteração está sem testes de unidade, tudo parece excelente e as propriedades estão em ordem.
As Solicitações de Pull foram projetadas para incentivar e capturar esse tipo de conversa.
Você também pode continuar a fazer push para o seu branch, considerando a discussão e o feedback sobre seus commits.
Suponha que alguém comente que você esqueceu de fazer algo ou, se houver um bug no código, você poderá corrigi-lo em seu branch e submeter a alteração.
O Git mostrará seus novos commits e qualquer feedback que você possa receber na visão unificada de Pull Request.
Os comentários de Solicitação de Pull são escritos no Markdown, para que você possa inserir imagens e emojis, usar blocos de texto pré-formatados e outra formatação leve.
Implantar
Com o Git, você pode fazer o deploy a partir de um branch para teste final em um ambiente antes de mesclar com a main.
Depois que sua solicitação de pull for revisada e a ramificação passar nos testes, você poderá implantar suas alterações para verificá-las. Você poderá revertê-lo se o branch causar problemas implantando o principal existente.
Mesclar
Depois que suas alterações forem verificadas, é hora de fazer a fusão do código no branch principal.
Depois de mescladas, as Solicitações de Pull preservam um registro das alterações históricas no código. Como eles são pesquisáveis, eles deixam qualquer um voltar no tempo para entender por que e como uma decisão foi tomada.
Você pode associar problemas ao código incorporando palavras-chave específicas ao texto da Solicitação de Pull. Quando seu pull request é mesclado, as issues relacionadas também podem ser fechadas.
Esse fluxo de trabalho ajuda a organizar e acompanhar branches focados em funcionalidades do domínio de negócios.
Outros fluxos de trabalho do Git, como o Fluxo de Trabalho de Forking do Git e o Fluxo de Trabalho Gitflow, são focados no repositório e podem usar o Fluxo de Trabalho de Branch de Características do Git para gerenciar seus modelos de ramificação.