Cherry-pick — o que é, mecanismo e aplicação no Git

O que é Cherry-pick?

Cherry-pick é um comando Git que copia as alterações de um commit especificado e as aplica como um novo commit no branch atual. O nome vem da metáfora “colher cerejas”: o desenvolvedor seleciona apenas os commits de que precisa, ignorando o resto.

Ao contrário do Merge, o cherry-pick não cria um commit de mesclagem nem requer mesclagem completa de branches. Ao contrário do Rebase, o cherry-pick não transfere uma sequência de commits — apenas os especificados. Isso torna o cherry-pick uma ferramenta ideal para transferência seletiva de correções.

De acordo com a Atlassian, 2025, o cherry-pick é usado por 47% das equipes que trabalham com vários branches de release simultaneamente. O cherry-pick é especialmente procurado no desenvolvimento mobile, onde múltiplas versões de um aplicativo (releases LTS) são mantidas simultaneamente e é necessário transferir correções entre elas.

Mecanismo de transferência

Ao executar o cherry-pick, o Git calcula o diff entre o commit especificado e seu pai, então aplica esse diff ao branch atual. Se as alterações forem aplicadas sem conflitos — o Git cria um novo commit com a mesma mensagem, mas com um novo SHA. Se houver conflito — o cherry-pick pausa para resolução manual.

Como funciona o Cherry-pick

A sintaxe do cherry-pick é simples: especifique o hash do commit a ser transferido. O Git copia as alterações para o branch atual como um novo commit. A transferência de vários commits de uma vez e de intervalos completos é suportada.

# Transferir um commit individual para o branch atual
git cherry-pick a1b2c3d4

# Transferir vários commits
git cherry-pick a1b2c3d4 e5f6g7h8

# Transferir um intervalo de commits (de a1b2 a f9e8, excluindo a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Após executar o cherry-pick, o branch atual recebe um novo commit com as alterações da origem. A mensagem do commit é copiada da origem por padrão, mas pode ser modificada com a flag -n (não criar commit) ou --edit (editar mensagem).

Exemplo de transferência de correção

Considere um cenário típico: um bug crítico é encontrado e corrigido no develop, que também existe no branch de release release/v2.0. Apenas essa correção precisa ser transferida, sem mesclar todo o develop no branch de release.

# Encontrar o hash do commit com a correção no develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Mudar para o branch de release
git checkout release/v2.0

# Aplicar a correção
git cherry-pick a1b2c3d4

# Se houver conflito — resolver e continuar
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

A flag -x adiciona uma referência ao SHA original na mensagem do commit: “(cherry picked from commit a1b2c3d4)”. Isso facilita rastrear de onde o commit foi transferido. Recomenda-se usar -x em todos os cenários, exceto rascunhos temporários.

Trabalhando com conflitos

Em caso de conflito, o cherry-pick se comporta como merge: o Git pausa e marca os arquivos conflitantes. O desenvolvedor resolve o conflito, executa git add e depois git cherry-pick --continue. Para cancelar — git cherry-pick --abort. A flag --strategy permite especificar uma estratégia de mesclagem (por exemplo, recursive com opções).

# Resolução de conflito durante cherry-pick
# Git mostra arquivos conflitantes
git status

# Resolver manualmente, então:
git add arquivo_permitido.kt
git cherry-pick --continue

# Ou cancelar cherry-pick:
git cherry-pick --abort

Quando usar Cherry-pick

Cherry-pick é ideal em cenários onde é necessária uma transferência seletiva de alterações sem mesclar branches inteiros. Vamos ver cinco casos principais em que o cherry-pick se torna a melhor escolha.

• Transferência de hotfix — uma correção é encontrada no develop, mas precisa ser aplicada ao branch de release (release/v2.0). O Cherry-pick transfere apenas o commit da correção sem afetar funcionalidades inacabadas do develop
• Backport para versões antigas — uma correção para a versão atual precisa ser transferida para um release LTS. Em vez de mesclar toda a base de código atual, o cherry-pick seleciona apenas os commits necessários
• Desfazer commit no branch errado — se um commit foi feito no branch errado, o cherry-pick o transfere para o correto, e o commit original é revertido
• Transferência de documentação — alterações em README ou arquivos de configuração que devem estar em todos os branches são convenientes de transferir via cherry-pick
• Aplicação seletiva — de um branch protótipo, apenas um commit bem-sucedido precisa ser aproveitado sem transferir todo o protótipo para o desenvolvimento principal

Para o desenvolvimento mobile, o cherry-pick é crucial ao dar suporte a múltiplas versões de um aplicativo. Por exemplo, se um bug for encontrado na versão 3.2 já publicada no Google Play, e o develop contém código para a versão 4.0 — o cherry-pick permite transferir a correção para o branch v3.x sem mesclar todas as mudanças disruptivas. Isso é especialmente relevante para projetos onde duas ou mais versões principais com diferentes APIs e dependências são mantidas simultaneamente.

Exemplo prático: em um aplicativo mobile, uma falha é detectada durante a autenticação via Google Sign-In no Android 12. A correção é feita no develop e passa pela revisão de código. No entanto, o branch de release atual v2.5 já está em fase de teste beta. O Cherry-pick do commit de correção do develop para release/v2.5 permite incluir a correção no próximo release sem transferir outras alterações que ainda não estão prontas para publicação.

Ao usar cherry-pick em projetos mobile, é importante considerar dependências: se a correção afetar arquivos que foram alterados no develop após o ponto de divergência do branch de release, o cherry-pick pode trazer um conjunto incompleto de alterações. Nesses casos, é necessário verificar se todas as alterações relacionadas também foram transferidas, caso contrário o aplicativo pode não compilar ou funcionar incorretamente. Sempre verifique a compilação após o cherry-pick antes de enviar as alterações para o branch compartilhado.

Cherry-pick vs Merge vs Rebase

As três principais ferramentas de integração de alterações no Git — merge, rebase e cherry-pick — resolvem tarefas diferentes. A escolha depende de quanto precisa ser transferido e como o histórico deve ficar.

Merge — quando você precisa mesclar dois branches inteiramente e preservar informações de ramificação. Rebase — quando você precisa atualizar um branch pessoal para o estado mais recente com histórico limpo. Cherry-pick — quando você precisa apenas de um commit ou vários commits selecionados.

Na prática, essas ferramentas são combinadas: uma funcionalidade é desenvolvida com rebase periódico no develop, depois mesclada via --no-ff merge, e quando é necessário transferir uma correção para outro branch, o cherry-pick é usado. Cada ferramenta resolve sua própria tarefa em seu próprio estágio.

Riscos e limitações do Cherry-pick

Cherry-pick é uma ferramenta útil, mas potencialmente perigosa quando usada incorretamente ou em excesso. Os principais riscos estão relacionados à duplicação de commits, perda de contexto e conflitos durante mesclagens posteriores.

• Duplicação de commits — se o mesmo commit posteriormente entrar no branch via merge, o Git criará um segundo commit idêntico nas alterações. Isso polui o histórico e dificulta o git bisect
• Perda de contexto — o cherry-pick transfere o diff, mas não transfere informações sobre commits pais e dependências. Se o cherry-pick aplicou o commit A sem o commit B do qual A dependia, podem ocorrer erros lógicos
• Conflitos no merge — após o cherry-pick, durante uma mesclagem completa de branches, o Git pode ver as mesmas alterações duas vezes e criar conflitos que poderiam ter sido evitados com um merge normal
• Falta de rastreabilidade — sem a flag -x, é impossível saber que um commit foi transferido de outro branch. Ao buscar a origem de uma alteração, um desenvolvedor pode passar horas descobrindo de onde o commit veio

Recomendações para minimizar riscos: use sempre a flag -x para indicar o SHA original, documente o motivo do cherry-pick na mensagem do commit e, quando possível, use merge em vez de cherry-pick quando o contexto permitir. Se os cherry-picks se tornarem numerosos — considere reestruturar os branches.

Verificações automatizadas para Cherry-pick

Os pipelines de CI devem considerar o cherry-pick como um cenário separado. Recomenda-se configurar uma verificação automatizada: quando um commit cherry-pick é criado, o CI verifica se os arquivos alterados correspondem ao conjunto esperado e executa testes para os módulos afetados. Isso reduz o risco de regressão ao transferir alterações entre branches.