O que é git cherry-pick e quando é útil?

Question

Accepted Answer

**git cherry-pick** aplica um **commit específico** de uma branch para outra — copiando apenas as mudanças desse commit, sem fazer merge de toda a branch. É útil para aplicar seletivamente mudanças particulares, como fazer backport de uma correção. ## Como cherry-pick funciona ```bash # apply a specific commit from another branch onto the current branch git cherry-pick # → creates a NEW commit on the current branch with that commit's changes # (a copy — new hash, same changes) git cherry-pick # multiple commits git cherry-pick A..B # a range of commits ``` Cherry-pick pega as mudanças de um commit específico e as aplica como um novo commit na sua branch atual — seletivamente, sem trazer o resto da branch de origem. ## Casos de uso comuns ```text ✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch (without merging all of main's other changes into the release branch) ✓ Applying a specific commit that's ready, while the rest of its branch isn't ✓ Moving a commit made on the wrong branch to the correct one ✓ Selectively pulling one change from another branch ``` ## Cuidados ```text ⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch): → can cause confusion/conflicts if branches are later merged (the change appears twice, though Git often handles it). Prefer merge/rebase for integrating whole branches. ⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead ⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default → Use cherry-pick for SELECTIVE, specific needs — not routine integration. ``` ## Por que isso importa Compreender `git cherry-pick` é valioso para **aplicar seletivamente mudanças específicas**, uma capacidade útil para situações particulares, então é conhecimento Git prático que vale a pena aprender. A capacidade principal — aplicar apenas as **mudanças de um commit específico** em outra branch sem fazer merge de toda a branch — aborda necessidades reais que merge não consegue resolver de forma limpa. O uso mais comum e importante é **backporting**: aplicar uma correção específica de bug da branch principal para uma branch de release ou manutenção, obtendo apenas essa correção sem fazer merge de todas as outras mudanças do main (possivelmente instáveis ou não lançadas) na branch de release — uma necessidade frequente na manutenção de software lançado. Outros usos incluem aplicar um single commit pronto enquanto o resto da sua branch não está pronto, mover um commit feito na branch errada para a correta, e puxar seletivamente uma mudança. Compreender os **cuidados** é importante para usar cherry-pick apropriadamente: ele cria **commits duplicados** (as mesmas mudanças com hashes diferentes em cada branch), o que pode causar confusão ou conflitos se as branches forem posteriormente fazer merge, então deve ser usado **deliberadamente para necessidades seletivas** em vez de ser um método de integração rotineiro (merge ou rebase são melhores para integrar branches inteiras), e fazer cherry-pick de muitos commits é um sinal de que você provavelmente quer um merge em vez disso. Esse julgamento — usar cherry-pick para situações específicas e seletivas (especialmente backporting) enquanto se prefere merge/rebase para integração rotineira — reflete uma prática Git sólida. Como aplicar seletivamente mudanças específicas (especialmente fazer backport de correções para branches de release) é uma necessidade real e ocasionalmente importante, e como cherry-pick é a ferramenta para isso (com cuidados sobre seu uso apropriado), entender `git cherry-pick` — como funciona, seus principais casos de uso como backporting, e quando usá-lo versus merge/rebase — é conhecimento Git valioso e praticamente relevante para lidar com os cenários de mudanças seletivas que surgem ao manter e gerenciar software entre branches.