A maioria dos líderes de engenharia sabe informar a velocidade do sprint do time. Poucos conseguem dizer com que frequência os squads estão fazendo commits de código e o que esse padrão revela sobre a saúde das entregas. Commit frequency mede com que frequência os players do seu time enviam mudanças de código para um repositório em um determinado período. Isso importa porque uma commit frequency baixa ou irregular é um sinal precoce de trabalho bloqueado, tarefas grandes demais ou risco de entrega se acumulando antes de aparecer nas métricas do sprint. Esta página cobre a definição, como medir, benchmarks publicados, como melhorar e como o DevStats extrai esses dados do seu Git.
Principais pontos
- Commit frequency mede com que frequência mudanças de código são enviadas a um repositório em uma janela de tempo definida. Commits frequentes e consistentes são um sinal forte de que o trabalho está bem dividido e que o código avança pelo pipeline sem lacunas longas que acumulam risco.
- A fórmula é simples: Commit Frequency = Total de Commits / Período de Tempo (dia, semana ou sprint). Times de engenharia de elite, conforme definido pelo relatório DORA State of DevOps 2023, tendem a fazer commits várias vezes por dia por player, enquanto times de baixo desempenho podem ficar dias sem commits em trabalhos ativos.
- O erro mais comum dos times é tratar commit frequency como uma pontuação de produtividade. Um player que faz dez commits por dia não é automaticamente mais eficaz do que um que faz dois. O contexto importa: complexidade da tarefa, estrutura do codebase e processos de revisão influenciam o que é um padrão saudável para o seu squad.
- O DevStats acompanha commit frequency automaticamente ao se conectar ao seu provedor Git, com benchmarks extraídos de mais de 1.000 times de engenharia. Comece um trial gratuito e veja os números do seu squad em menos de dois minutos.
Definição de commit frequency
Commit frequency é o número de commits de código enviados a um repositório de controle de versão em um período específico. É um sinal de processo que mostra com que continuidade o código flui pelo pipeline de entrega, não uma medida de output individual.
Tecnicamente: Commit Frequency = Total de Commits / Período de Tempo. A maioria dos times mede isso por dia ou por semana, tanto no nível do repositório quanto agregado por squad. Quando a commit frequency cai bruscamente em um projeto ativo, geralmente aponta para um problema de processo: itens de trabalho grandes demais, gargalos de revisão ou escopo de tarefa pouco claro. Times que entregam com consistência tendem a mostrar padrões de commit estáveis e previsíveis, não picos seguidos de longos silêncios. Acompanhar essa métrica no nível do squad se conecta diretamente à previsibilidade de entrega, que é o que seus stakeholders e parceiros de produto se importam.
Commit frequency está dentro da dimensão Activity do SPACE framework e alimenta diretamente os sinais de throughput que indicam se o pipeline avança em um ritmo sustentável.
Por que commit frequency importa para times de engenharia
Quando squads ficam dias sem commits em trabalhos ativos, a causa raiz raramente aparece antes da sprint review. O trabalho se acumula em branches de longa duração, conflitos de merge se multiplicam e o risco de integração cresce silenciosamente. Quando um sprint perde a meta, o sinal já estava visível nos padrões de commit dias antes. Squads que fazem commits pequenos e frequentes reduzem o overhead de integração, identificam problemas mais cedo na revisão e mantêm o PR cycle time curto, porque há simplesmente menos código para revisar por pull request.
Para líderes de engenharia, commit frequency se conecta a dois KPIs importantes: entrega no prazo e visibilidade da capacidade do time. Padrões de commit irregulares podem mascarar se um squad está genuinamente produtivo ou travado em um bloqueio que ninguém escalou. Também se conecta à experiência do desenvolvedor: players bloqueados tendem a mostrar isso nos padrões de commit antes de mencionar qualquer coisa na standup. Monitorar o processo, não a pessoa, dá os dados para fazer as perguntas certas.
Nos frameworks DORA e SPACE, commit frequency é um indicador antecedente para deployment frequency e change lead time. Medir é o primeiro passo. O que você faz com esse sinal é onde o seu julgamento como líder de engenharia mais importa.
Como medir commit frequency
Extraia dados de commit diretamente do seu provedor Git: GitHub, GitLab, Bitbucket e Azure DevOps expõem isso via API ou analytics nativo. Calcule o total de commits por repositório por período e normalize pelo tamanho do squad se quiser uma visão por player. Para a maioria dos times, uma cadência semanal é a janela de medição certa durante sprints ativos. A medição diária é útil em ciclos de release críticos, quando você precisa de sinais mais antecipados.
Nenhum benchmark publicado pelo DORA cobre commit frequency no nível individual ou de squad diretamente. A pesquisa State of DevOps do DORA foca em deployment frequency como métrica de output. A tabela abaixo reflete padrões qualitativos observados em times de engenharia, e os benchmarks variam por tamanho do time, maturidade do codebase e modelo de release. Os benchmarks do DevStats permitem comparar os padrões do seu squad com times de tamanho e estágio similares.
| Nível de desempenho | Benchmark de commit frequency | O que indica |
|---|---|---|
| Elite | Vários commits por dia por player ativo | Trabalho bem dimensionado, fluxo contínuo, risco de integração baixo |
| Alto | Commits diários por player ativo | Ritmo de entrega saudável com agrupamento ocasional |
| Médio | 2 a 4 commits por player por semana | Algum agrupamento ou problemas de dimensionamento de tarefas; vale investigar |
| Baixo | Menos de 1 commit por player por semana em trabalho ativo | Provável trabalho bloqueado, tarefas grandes demais ou escopo pouco claro |
Esses intervalos são guias qualitativos, não limites rígidos. Um squad trabalhando em um grande refactor pode fazer commits com menos frequência do que um que está entregando features. O contexto dos seus dados de sprint e do issue tracker é essencial para a interpretação.
Commit frequency na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que um squad perdia consistentemente as metas do sprint, mesmo sem reportar bloqueios nas standups. Ela extraiu os dados de commit das quatro semanas anteriores e viu um padrão claro: os commits se concentravam nos dois últimos dias de cada sprint, com quase nenhuma atividade na primeira metade. O trabalho estava sendo feito, mas era agrupado em grandes entregas de última hora que não deixavam tempo para code review ou QA significativos.
Ela fez uma sessão de trabalho com o lead do squad para quebrar o backlog do sprint em tarefas menores e independentes. Também estabeleceu uma norma para o squad: nenhum pull request deveria representar mais de um dia de trabalho. Quatro sprints depois, a atividade de commit se distribuiu por toda a janela do sprint, o tempo de retorno do code review caiu e o squad entregou no prazo em três dos quatro sprints seguintes. Os dados de commit frequency não resolveram o problema. Eles deram o sinal necessário para fazer a pergunta certa.
Como melhorar commit frequency
- Quebre itens de trabalho em tarefas concluíveis em meio dia ou menos. Tickets grandes são a causa mais comum de commit frequency baixa. Se um player não consegue concluir uma unidade de trabalho significativa em algumas horas, a tarefa provavelmente é grande demais. Revise o dimensionamento do backlog no sprint planning e defina um limite máximo de story points que o squad aceite.
- Adote trunk-based development ou feature branches de curta duração. Branches de longa duração desestimulam commits frequentes porque os players sentem que precisam de um trecho "completo" antes de enviar. O trunk-based development ou uma disciplina de um branch por dia cria uma função de forçamento natural para commits menores e mais frequentes.
- Monitore PR cycle time junto com commit frequency. Se commit frequency sobe, mas o PR cycle time continua alto, o gargalo se deslocou para a revisão. Essas duas métricas funcionam juntas: uma diz com que velocidade o código está sendo escrito, a outra diz com que velocidade ele está sendo revisado e mergeado.
- Use o activity heatmap para identificar padrões, não outliers. O DevStats exibe um activity heatmap que mostra a distribuição de commits ao longo da semana e do sprint. Use-o para identificar se a entrega do seu squad está concentrada no início, no final ou distribuída de forma consistente, e decida se esse padrão se encaixa no seu modelo de release.
- Alinhe as normas de commit com a cadência do sprint. Se o seu squad roda sprints de duas semanas, um player deve ter atividade de commit visível até o terceiro dia. Defina essa expectativa explicitamente no acordo de trabalho do time para que se torne um padrão de processo, não um julgamento de desempenho.
Commit frequency vs. deployment frequency
Commit frequency e deployment frequency são relacionadas, mas medem estágios diferentes do pipeline de entrega. Commit frequency mede com que frequência o código é escrito e enviado ao controle de versão. Deployment frequency, uma das quatro DORA metrics principais, mede com que frequência esse código chega à produção.
| Commit frequency | Deployment frequency | |
|---|---|---|
| Mede | Código enviado a um repositório | Código entregue em produção |
| Começa quando | Um player faz push de um commit | Um pipeline de deployment é acionado |
| Termina quando | O commit chega ao repositório | O release alcança o ambiente de produção |
| Melhor para | Diagnosticar problemas de fluxo cedo no pipeline | Medir o output de entrega de ponta a ponta |
Use commit frequency para diagnosticar problemas de fluxo no início do pipeline e use deployment frequency para medir se essas melhorias estão chegando à produção.