Explorar o fluxo de trabalho do branch de recursos
A ideia principal por trás do Fluxo de Trabalho de Branch de Recursos é que todo o desenvolvimento de recursos deve ocorrer em um branch dedicado e não no branch principal.
O encapsulamento facilita o trabalho de vários desenvolvedores em um recurso específico sem atrapalhar 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.
O encapsulamento do desenvolvimento de recursos também possibilita o uso de solicitações de pull, que são uma forma de iniciar discussões a cerca de um branch. Ele permitem que outros desenvolvedores saiam de um recurso antes que ele seja integrado ao projeto oficial. Ou, se você ficar preso no meio de um recurso, poderá abrir uma solicitação de pull pedindo sugestões dos colegas.
As solicitações de pull facilitam bastante os comentários da equipe sobre o trabalho uns dos outros. Além disso, os branches de recursos podem (e devem) ser enviados por push para o repositório central. Isso possibilita compartilhar um recurso com outros desenvolvedores sem tocar em nenhum código oficial.
Como o principal é o único branch "especial", o armazenamento de vários branches de recursos no repositório central não apresenta nenhum problema. Essa também é uma forma fácil de fazer o back-up dos commits locais de todos.
Fluxo de trabalho do branch de lançamento
Além do Fluxo de trabalho do Branch de Recursos, outra estratégia comumente usada nos fluxos de trabalho de ramificação do Git é a Estratégia do Branch de Lançamento. Essa estratégia envolve a criação de branches dedicados especificamente para preparar versões. O branch de lançamento normalmente é criado a partir de um branch de recursos estável, garantindo que ele contenha apenas um código totalmente 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 de atividades relacionadas à versão do desenvolvimento de recursos em andamento, fornecendo um ambiente controlado para finalizar e refinar a versão futura. 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 Branch de Lançamento ajuda as equipes a gerenciar as complexidades da coordenação das atividades de lançamento, mantendo um branch principal estável para desenvolvimento contínuo.
Fluxo de trabalho de desenvolvimento baseado em tronco
O fluxo de trabalho de desenvolvimento baseado em tronco assume um repositório central e o principal representa o histórico oficial do projeto. Em vez de fazer commit diretamente no branch principal local, os desenvolvedores criam um branch sempre que começam a trabalhar em um novo recurso. Os branches de recursos devem ter nomes descritivos, como novas-imagens-banner ou bug-91. A ideia é dar uma finalidade clara e altamente focada a cada ramificação.
O Git não faz distinção técnica entre a ramificação principal e as de recursos, para que os desenvolvedores possam editar, apresentar e fazer commit de alterações em uma ramificação de recursos.
Criar um branch
Quando estiver trabalhando em um projeto, você terá muitos recursos ou ideias diferentes em andamento a qualquer momento, alguns deles estarão prontos para uso e outros ainda não. A ramificação existe para ajudar você a gerenciar esse fluxo de trabalho. Ao criar um branch no projeto, você cria um ambiente no qual 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 dedicados especificamente para preparar versões. Esses branches de versão normalmente são derivados de branches de recursos estáveis para garantir que contenham código totalmente 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 commits
Depois que o branch é criado, é hora de fazer alterações. Sempre que adicionar, editar ou excluir um arquivo, você está fazendo um commit e adicionando-o ao branch.
A adição de commits acompanha o progresso enquanto você trabalha em um branch de recursos.
Os commits também criam um histórico transparente do seu trabalho, que outras pessoas podem seguir para entender suas ações e por quê.
Cada commit tem uma mensagem de commit associada, explicando por que uma alteração específica foi feita.
Além disso, cada commit é considerado uma unidade de alteração separada. Ele permite reverter as alterações quando um bug é encontrado ou quando você decide seguir uma direção diferente.
As mensagens de commit são essenciais, especialmente porque o Git rastreia as alterações e as exibe como commits quando que elas são enviadas para o servidor.
Ao escrever mensagens de commit claras, você pode facilitar para que outras pessoas acompanhem o trabalho e forneçam comentários.
Abrir uma solicitação de pull
As solicitações de pull iniciam uma discussão sobre os commits. Como elas são totalmente integrados ao repositório Git subjacente, qualquer pessoa pode ver exatamente quais alterações seriam mescladas se aceitasse sua solicitação.
Você pode abrir uma solicitação de pull 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 @mention em sua mensagem de solicitação de pull, você pode solicitar comentários de pessoas ou equipes específicas, independentemente de elas estarem perto ou longe fisicamente.
As solicitações de pull ajudam a contribuir em projetos e a gerenciar alterações em repositórios compartilhados.
Se você estiver usando um modelo Fork e Pull, as solicitações Pull fornecerão uma maneira de notificar os mantenedores do projeto sobre as alterações que você gostaria que eles considerassem.
Quando você está usando um modelo de repositório compartilhado, as solicitações de pull ajudam o a iniciar a revisão de código e a conversa sobre as alterações propostas antes que elas sejam mescladas no branch principal.
Discutir e revisar o código
Depois que uma solicitação de pull for aberta, a pessoa ou a equipe que estiver revisando as alterações poderá ter dúvidas ou comentários.
Talvez o estilo de codificação não seja igual às diretrizes do projeto, a alteração não tenha testes de unidade, tudo pareça excelente e os objetos estejam 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 seu branch, considerando a discussão e os comentários sobre os comitts.
Se alguém comentar que você se esqueceu de fazer algo ou se houver um bug no código, você poderá corrigi-lo no branch e fazer push da alteração.
O Git mostrará os novos commits e quaisquer comentários que você possa receber na exibição Solicitação de Pull unificada.
Os comentários de Solicitação de Pull são escritos em 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 a implantação de uma ramificação para o teste final em um ambiente antes de mesclar com o principal.
Depois que a solicitação de pull tiver sido revisada e o branch passar nos testes, você poderá implantar as alterações para verificá-las. Se a ramificação causar problemas, você poderá reverter a ação implantando o principal existente.
Mesclar
Agora que as alterações foram verificadas, é hora de mesclar o código na ramificação principal.
Depois de mescladas, as solicitações pull preservam um registro das alterações históricas no código. Como são pesquisáveis, eles permitem que qualquer pessoa volte 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 sua solicitação de pull é mesclada, os problemas relacionados também podem ser fechados.
Esse fluxo de trabalho ajuda a organizar e acompanhar ramificações que se concentram em conjuntos de recursos de domínio empresarial.
Outros fluxos de trabalho do Git, como o fluxo de trabalho de criação de fork do Git e o fluxo de trabalho Gitflow, são focados no repositório e podem usar o Fluxo de Trabalho da Ramificação de recurso do Git para gerenciar os modelos de ramificação.