Como fazer um bom gerenciamento de configuração com Git

1. Definir uma estratégia única de branches

   • quando membros da equipe com conhecimentos especializados diversos trabalham juntos, podem surgir conflitos na forma de abordar o fluxo de trabalho
   • para evitar isso, a liderança deve definir uma única estratégia de branches e compartilhá-la com todos
   • a decisão sobre o workflow de branches pode variar conforme vários fatores, como tamanho da equipe, nível de experiência, necessidade de escalabilidade e restrições de trabalho
   • a equipe de desenvolvimento pode seguir um workflow já estabelecido ou criar um workflow adequado às necessidades do time
   • o que um workflow pode incluir
     • workflow centralizado: há um único repositório e uma única branch master. Existe risco de sobrescrever alterações
     • feature branch: sempre que uma nova funcionalidade é adicionada, cria-se uma nova branch. Os commits relacionados à funcionalidade ficam nessa feature branch
     • Git Flow: uma forma mais extrema de feature branches. No desenvolvimento com Git Flow, há uma branch master e uma branch de desenvolvimento separada. Suporta branches de funcionalidade, release e hotfix. O desenvolvimento é feito na branch de desenvolvimento, passa para a branch de release e depois é feito merge na branch master
     • desenvolvimento task-branch: GitLab Flow é um exemplo desse tipo de desenvolvimento. É uma forma de desenvolvimento orientada a funcionalidades que combina feature branches com rastreamento de issues. O GitLab Flow usa branches dedicadas separadas para manter vários ambientes, como staging, teste de produção e produção. Isso garante que as alterações com commit sejam testadas em todos os ambientes
   • efeitos na colaboração:
     • quando todos trabalham em harmonia dentro do mesmo workflow, diminui a chance de sobrescrever código ou comprometer a branch master
     • todos os participantes se familiarizam com os processos de desenvolvimento e deploy, facilitando que os membros do time contribuam no trabalho uns dos outros
     • uma estratégia de branches clara e concisa leva a um ciclo positivo de merge de novo código e evolução do projeto
     • esse ambiente ajuda os membros da equipe a organizar reuniões e gerenciar prazos e carga de trabalho
     • impacto de cada workflow na colaboração
       • workflow centralizado: eficaz para equipes pequenas (menos de 5 desenvolvedores) que conseguem se comunicar bem para evitar que duas pessoas trabalhem ao mesmo tempo no mesmo código de forma redundante
       • feature branch e GitFlow: conectam equipes mais diversas porque exigem mais code review, regras de push, aprovadores de código e testes mais amplos
       • desenvolvimento task-branch: leva os membros da equipe a dividir os requisitos em pequenos blocos de funcionalidade que são passados para task branches. Esse workflow inclui práticas colaborativas como snippets de código, code review e testes unitários. Se os testes falharem, os membros do time colaboram para descobrir o que deu errado

2. Fazer commits frequentes em pequenas unidades

   • ao priorizar apenas o grau de conclusão, pode-se acabar fazendo grandes commits só quando o projeto estiver quase pronto
   • se você pular validações simples de funcionalidade e pequenos passos, pode desenvolver algo incorreto e gastar tempo seguindo uma direção errada
   • faça commit sempre que houver testes funcionais e código operacional
   • é preciso simplificar o projeto em pequenas etapas e encontrar uma forma de atingir grandes objetivos com commits frequentes
   • impacto na colaboração:
     • quando existe uma cultura de commits frequentes, todos ganham visibilidade sobre o repositório de código e conseguem entender com facilidade no que os outros estão trabalhando
     • ao compartilhar o trabalho em feature branches ou em merge requests, é possível evitar esforços duplicados de outros membros da equipe
     • mesmo que ainda não esteja pronto para revisão, é preciso fazer push frequente para a feature branch
     • compartilhar o trabalho antes da conclusão estimula discussões e feedback, permitindo melhorar a qualidade antes mesmo do code review
     • dividir o trabalho em vários commits oferece informações úteis para futuras revisões de código por desenvolvedores e outras equipes
     • fica possível identificar claramente, commit por commit, como a funcionalidade foi desenvolvida
     • também é possível manter intacto o histórico de alterações não relacionadas, fazer rollback até um ponto específico e reverter seletivamente apenas certas mudanças de código

3. Escrever mensagens de commit detalhadas

   • a mensagem de commit deve refletir não apenas o conteúdo do commit, mas também a intenção do desenvolvedor
   • a mensagem de commit deve explicar por que a mudança aconteceu
   • exemplo de boa mensagem de commit: “combinei os templates para reduzir o código duplicado na tela do usuário”
   • palavras como “mudança”, “melhoria”, “correção” e “reestruturação” em mensagens de commit não trazem informação útil
   • impacto na colaboração:
     • mensagens de commit detalhadas aumentam a transparência e dão visibilidade ao progresso, ajudando colegas de equipe, clientes e futuros contribuidores a entender o processo de desenvolvimento
     • ao fazer code review, as mensagens de commit ajudam a seguir procedimentos repetidos e a identificar mudanças que surgiram após releases, alinhamentos e alterações de requisitos
     • mensagens de commit detalhadas ajudam as equipes de QA e segurança a identificar áreas problemáticas ao inspecionar o código e a reverter mudanças específicas
     • escrever mensagens de commit detalhadas evita trabalho duplicado entre os membros da equipe, minimiza atrasos e ajuda a manter o avanço do projeto de forma estável

4. Desenvolver usando branches

   • desenvolver em uma branch é como copiar o estado atual em um ponto específico e trabalhar a partir dele
   • usando branches, é possível alterar o código sem impactar a codebase principal
   • o histórico de mudanças é gerenciado dentro da branch
   • quando o código estiver pronto, ele pode ser merged na branch master
   • programar em branches permite abordar o desenvolvimento de forma mais estruturada
   • é possível manter rascunhos em desenvolvimento separados do código master estável que já passou por testes consistentes
   • impacto na colaboração:
     • permite que os membros tentem soluções inovadoras e experimentos para resolver problemas complexos
     • a equipe de desenvolvimento pode se desafiar de forma criativa sem a ansiedade de impactar a branch master
     • é possível colaborar para verificar se a solução funciona corretamente antes de fazer merge na branch master
     • as equipes de operações, QA e segurança podem revisar o código antes do deploy, garantindo que todos tenham a oportunidade de sugerir ideias e discutir possíveis problemas antes do release

5. Fazer code review regularmente

   • garante melhoria contínua e evita código instável
   • quando houver código a ser revisado, deve-se pedir code review a colegas, membros da equipe ou especialistas da área que conheçam bem o projeto
   • pontos de atenção ao fazer code review:
     • explicar quais mudanças são necessárias
     • oferecer alternativas, mas assumindo que o desenvolvedor já as considerou
     • mesmo durante a solução do problema, é preciso procurar formas de simplificar o código
   • efeitos na colaboração:
     • o code review apresenta outras perspectivas sobre a resolução de problemas e a implementação
     • funciona como um novo olhar para encontrar bugs, problemas de lógica ou possíveis corner cases
     • ajuda a reduzir problemas que podem surgir enquanto a equipe enfrenta questões difíceis e avança rumo ao release
     • permite revisar soluções, dar opiniões e colaborar com outros membros da equipe durante a revisão
     • é possível aprender diferentes formas de programar, know-how de workflow e novas maneiras de resolver problemas