Recentemente precisei aumentar a equipe de um projeto. Notei que não era mais possível deixar todo o código em um único branch, pois isso estava atrasando o deploy em produção: O planejamento inicial era terminar uma tarefa, seguir com a próxima de forma rápida e assim não precisaríamos criar um branch. Porém isso começou a ocorrer com frequência e a tarefa foi ficando mais longa que o esperado – o que gerava o atraso na publicação em produção.
Surgiu a necessidade de adotar um padrão para versionamento do nosso código.
Já atuei em empresas onde decidimos criar um fluxo próprio. Nunca achei essa abordagem muito boa, pois a cada novo desenvolvedor que entrava na empresa era necessário a explicação de como estava versionado o código e toda uma apresentação de como funcionava o padrão que ele deveria seguir.
Com base em toda experiência que já tive, resolvi adotar um fluxo de versionamento utilizado na comunidade de desenvolvimento de software e que todo desenvolvedor conhece: O Git Flow.
Pontos positivos:
-
Organização e padronização;
- Não vai para produção código que não estiver terminado ou homologado;
- Não precisarei gastar tempo explicando como o desenvolvedor versionarará sua demanda;
-
Qualquer dúvida do profissional ele pode encontrar na web;
-
O profissional estará usando o que o mercado está usando!
Pontos negativos:
-
Exige que o profissional saiba git;
-
O responsável do versionamento, precisa ser organizado: Se o desenvolvedor não finalizar uma feature ou um hotfix, o código ficará perdido.
Só encontrei esses pontos negativos. Você tem ou vê outro ponto negativo? por favor deixem nos comentários.
Oragnização do Git Flow
- Ele tem 2 branchs principais, develop e master.
- Possui 3 branchs que vão caminhar de acordo com novas features, hotfix e release para publicar em produção.
- Fundamental criar tags no versionamento: São criadas na finalização da release e hotfix.
Existem alguns padrões para nomear o branch disponível na internet, mas eu resolvi adotar o versionamento semântico, porque assim não é exigido muita criatividade para nomear um branch: major.minor.patch.
Para quem está em dúvida do que é o versionmento sermántico deixo o link
Conclusão:
Dessa forma consegui organizar meu código e a organização das versões. A interação do responsável técnico, equipe de negócios e os desenvolvedores também ficou facilitada. Organização sempre ajuda quando o cenário existente é acelerado e de pequenas entregas.
Postarei mais experiencias com o git flow, mas caso queira aprender como usar o git flow estou disponível para ensinar no Super Prof.