O Github possui um fluxo de trabalho simples, porém muito poderoso: O Github Flow.
E se você é iniciante no Git, vai adorar aprender como essa grande plataforma desenvolve…
Pensando nisso, preparamos esse guia ilustrativo para você adicionar esse conhecimento ao seu Arsenal de Programador:
Git Workflow
O fluxo de trabalho no git funciona com 2 tipos de branchs:
main:
A branch principal do repositório.- E várias branchs secundárias. (usadas para criar features, hotfix, upgrades ou qualquer outra coisa que você precisar)
Agora vamos aos detalhes do fluxo…
Crie uma branch
Para iniciar qualquer alteração no projeto, você deve criar uma nova branch a partir da branch main
.
O nome da branch não faz diferença para o processo…
Mas é uma boa prática dar nomes muito descritivos, como por exemplo:
adiciona-painel-admin
altera-layout-home
Afinal, isso ajuda você a localizar a branch e evitar colisões.
Adicione seus commits
Em seguida, adicione seus commits na branch criada.
A mensagem dos commits não é relevante para o fluxo…
Mas é sempre bom escrever mensagens claras e objetivas para você poder gerenciar o histórico do seu projeto.
Porém defina um padrão de mensagem simples e não restritivo, para não afetar sua produtividade ou de outros membros da equipe.
Inclusive, compartilhei o padrão que mais utilizo nesse infográfico.
Abra um pull request
Quando o trabalho estiver concluído, abra um pull request para compartilhar seus commits.
E enquanto o pull request estiver aberto, você pode ir adicionando novos commits.
O que permite você discutir com sua equipe e, caso necessário, realizar alguma alteração.
Caso você não saiba como criar um pull request, dê uma olhada na documentação do Github.
Build (CI)
Depois que o pull request é criado, o serviço de integração continua (CI) executa todos os processos para validar o seu código…
Como por exemplo: testes unitários, testes de integração, validações, build…
E se todas as verificações passarem, é feito o deploy do projeto em um ambiente de teste ou homologação.
Faça o merge
Com o pull request aprovado e testado em um ambiente seguro, o caminho está limpo para realizar o merge com a branch main
.
Assim suas alterações devem aparecer na branch principal, e seu projeto estará pronto para o deploy em produção.
Delete a branch secundaria
Depois de feito o merge, delete sua branch de desenvolvimento.
Dessa forma, você finaliza o seu trabalho naquela branch.
Além de evitar que você (ou sua equipe) usem uma branch antiga por acidente.
E não se preocupe em perder informação. Afinal, o seu pull request e o histórico de commits não são apagados.
Você também pode sempre recuperar a branch deletada, ou reverter o pull request, se precisar…
Conclusão
O github flow possui poucas etapas justamente para ser simples, sólido e versátil.
Mas nem sempre vai servir para a sua situação atual…
Então recomendo que use ele como base e adapte o que precisar.
E se você gostou desse guia, ou ficou com alguma dúvida, não deixe de comentar abaixo:
[Infográfico] 4 Dicas para escrever commits com estilo
{ update-alternatives } Crie suas Variáveis de Ambiente como um Verdadeiro Maestro
Como exibir a Branch atual do Git no Terminal - Dica de Produtividade
[Infográfico] Estrutura de Diretórios Linux: O Mapa do Aventureiro Iniciante
Hey,
o que você achou deste conteúdo? Conte nos comentários.
Referências:
Github Docs