Ofício, qualidade e times · Iniciante

Trabalhar com versões: branches, merges e histórico

Em uma linha: Branches curtos e merges frequentes evitam a maior parte da dor de versão — e um histórico legível vale o esforço no dia em que você investiga um incidente.

Um fluxo simples

Um branch principal estável, branches curtos por mudança, um merge após revisão e testes. Um branch que vive duas semanas vai criar conflitos e um merge assustador — e isso é quase sempre sinal de que a tarefa é grande demais.

Mensagens de mudança

Uma primeira linha curta dizendo o que mudou, depois o porquê. O 'porquê' é o que não dá para recuperar do código, e é o que você vai buscar daqui a um ano.

Vincule à tarefa ou à discussão. Uma mudança sem contexto é um enigma futuro.

Higiene

Não guarde arquivos construídos, segredos ou arquivos grandes no repositório. Marque versões com tags. E não reescreva histórico já publicado — isso quebra o trabalho dos outros.

Indo mais fundo

Decida uma política de merge — preservar o histórico completo ou esmagar em uma única mudança — e aplique-a. A consistência importa mais do que a escolha em si, porque um histórico misturado é difícil de navegar exatamente quando você precisa encontrar quando algo quebrou.