Você está procurando uma solução técnica para um problema humano. Isso raramente funciona.
Aqui estão algumas abordagens que eu usei no passado ou que tenho em mente sem realmente ter uma oportunidade para elas na prática. Alguns podem não se aplicar ao seu caso, dependendo da posição que você ocupa em uma equipe (se você é um líder de equipe com excelente reputação, é provável que tenha uma oportunidade melhor de reforçar sua visão do que se você for um graduado que acabou de ingressar em uma equipe durante o estágio).
Discuta o problema com seus colegas de trabalho e explique as consequências de grandes confirmações. Talvez eles simplesmente não entendam que fusões complicadas são uma conseqüência direta de confirmações raras, e que pequenas e frequentes confirmações facilitarão (relativamente) as fusões.
Eu conhecia muitos programadores que estavam simplesmente convencidos de que as fusões são sempre complicadas. Eles realizavam no máximo um commit por dia, evitavam usar ferramentas poderosas, como o diff e a mesclagem automática do Visual Studio, e tinham uma péssima prática de mesclagem manual (a menos que "Take mine" sem inspeção diferencial adicional seja realmente uma boa prática). Para eles, isso não tinha nada a ver com eles e era a natureza inerente de uma fusão.
Dê exemplos concretos do que está acontecendo em outras empresas (especialmente aquelas pelas quais seus colegas de trabalho têm profundo respeito). Eles podem simplesmente não ter consciência de que é um problema e estar convencidos de que um máximo de confirmação por dia é o que toda equipe faz.
Algumas pessoas não sabem que existem equipes de 5 a 10 membros que fazem até 50 empurrões para a produção, o que se traduz em uma média de 5 a 10 confirmações por dia por pessoa. Eles podem não entender nem como isso é possível, nem por que alguém faria isso.
Lidere pelo exemplo. Faça o suficiente pequeno compromete-se. Se possível, faça uma breve apresentação mostrando suas e suas mesclagens lado a lado durante uma semana (não tenho certeza se é fácil extrair esse tipo de informação de um controle de versão). Enfatize os eventuais erros que eles cometeram durante as mesclagens e compare-os com o número de erros que você cometeu (que deve ser próximo de zero).
Use a técnica "Eu te disse", quando apropriado . Quando você vir seus colegas sofrendo uma fusão dolorosa, comente em voz alta que pequenas e frequentes confirmações podem tornar a fusão (relativamente) indolor.
Explique que não há duração mínima para fazer uma confirmação. Uma confirmação pode até corresponder a uma pequena alteração feita em alguns segundos. Renomear um arquivo, remover um comentário obsoleto, corrigir um erro de digitação são todas as tarefas que podem ser confirmadas imediatamente.
Os programadores não devem ter medo de fazer um pequeno commit, mas agregar muitas alterações em um grande commit.
Trabalhe com indivíduos em vez de com uma equipe, quando apropriado. Se houver uma pessoa que se recusa a realizar com frequência pequenos e frequentes, converse com essa pessoa individualmente para ver por que ela está recusando.
Eles podem fornecer razões perfeitamente válidas que podem lhe dar uma dica sobre o que está acontecendo com uma equipe. Algumas razões pelas quais eu me ouvi:
“Meu professor / mentor me disse que a melhor prática é fazer um compromisso por dia.” Isso não me surpreende, dado o que eu tinha que ouvir de meus professores na faculdade .
“Meus colegas me disseram que eu deveria fazer menos comprometimentos.” Também me disseram isso em algumas equipes e entendo o que eles querem dizer. Tínhamos um registro praticamente preenchido com meus commits (o que não é difícil de fazer quando quatro colegas de equipe nem fazem um commit por dia), o que frustrou meus colegas de trabalho.
“Eu pensei que pequenos commits dificultam a localização de uma revisão.” Ponto de alguma forma válido, mesmo quando a equipe se esforça para escrever mensagens de log descritivas.
“Não quero perder muito espaço em nosso servidor de controle de versão.” Obviamente, a pessoa não entende como as confirmações são armazenadas (nem quão barato é o espaço de armazenamento).
“Acho que um commit deve corresponder a uma tarefa específica.” Dado que, muitas vezes, uma tarefa corresponde a algum trabalho a ser realizado em um dia (como nos quadros de tarefas do gerenciamento visual), isso não é uma coincidência. A pessoa deve aprender a fazer a diferença entre uma tarefa em um backlog (2 a 8 horas de trabalho) e uma mudança isolada logicamente que deve ser confirmada (alguns segundos a algumas horas de trabalho). Isso também está relacionado ao ponto 5.
Pesquise o motivo pelo qual a equipe não está realizando confirma com mais frequência. Você pode se surpreender com os resultados.
Recentemente, mencionei em uma resposta diferente que a velocidade de uma consolidação é importante, e mesmo centenas de milissegundos podem levar os desenvolvedores a se comprometerem com menos frequência.
Outras razões podem incluir:
Regras excessivamente complicadas para escrever uma mensagem de confirmação.
A regra que força o desenvolvedor a vincular a confirmação a uma tarefa de um sistema de rastreamento de erros.
O medo de quebrar a construção.
A falta de vontade de lidar com o risco de interromper a compilação agora: se você fizer um commit na sexta-feira à noite pouco antes de sair, poderá adiar o tratamento da compilação interrompida até segunda-feira.
O medo de fazer uma fusão.
Determine se os desenvolvedores entendem que há outros benefícios a serem confirmados com frequência . Por exemplo, uma plataforma de Integração Contínua é um grande incentivo para ter confirmações frequentes , pois permite identificar com precisão onde a regressão foi introduzida .
Prefiro a plataforma CI dizendo que eu quebrei a compilação na revisão 5023, que consiste em uma alteração de dois métodos em um arquivo que fiz quinze minutos atrás, em vez da revisão 5023, que consiste em alterações que abrangem quatro dúzias de arquivos e representam 13 horas de trabalho.