Cherry-pick: quando é adequado e o que custa ao histórico

O que é

git cherry-pick <commit> aplica a alteração introduzida por um commit sobre a branch atual e registra um novo commit. Segundo a documentação, é necessário que a árvore de trabalho esteja limpa; em caso de conflito, o comando para com CHERRY_PICK_HEAD definido até que se use --continue, --skip ou --abort. A opção -x acrescenta à mensagem a linha "(cherry picked from commit ...)". Para fazer pick de um merge commit é preciso usar -m <parent-number>, indicando qual pai é a linha principal (mainline). Com -n / --no-commit, vários picks são aplicados ao índice antes de um único commit.

Por que importa

O novo commit tem o mesmo patch, mas um ID e um pai diferentes. O Git compara commits pela ancestralidade, de modo que um merge posterior da branch de origem não sabe que a alteração já está presente: uma alteração idêntica nos dois lados costuma ser integrada sem conflito, mas qualquer diferença (um conflito resolvido durante o pick, uma edição posterior nas mesmas linhas) vira conflito, e de qualquer forma o histórico mantém dois commits para uma única alteração. Cada pick acrescenta, portanto, um custo pequeno e permanente: um histórico que precisa ser reconciliado pelo conteúdo do patch, e não pela ancestralidade. O comando git log --cherry-pick --left-right A...B existe justamente para omitir commits que introduzem a mesma alteração do outro lado, como descreve a documentação do git-log.

Como aplicar

• Backport de uma correção: faça o commit da correção na branch suportada mais antiga e depois faça merge para as mais novas, ou aplique-a para baixo com pick e -x, para que a origem continue rastreável. A documentação recomenda -x em picks entre branches públicas e o desaconselha em branches privadas.
• Resgate de um bom commit de uma branch que será descartada: faça o pick e depois apague a branch, para não restar uma linhagem duplicada.
• Quando se quer a branch inteira: faça merge ou rebase. Fazer pick de todos os commits de uma branch produz uma segunda linhagem das mesmas alterações, que um merge posterior não consegue reconhecer como já integradas.
• Hotfix publicado a partir de uma branch de release: faça o pick para a main imediatamente, antes que as duas divirjam ainda mais.
• Mantenha os commits escolhidos pequenos e autocontidos; o pick de metade de um refactor gera conflito mais tarde com a outra metade.

Armadilhas

O pick de um commit que depende de commits anteriores não escolhidos compila por sorte, ou não compila. A resolução de conflitos durante um pick não fica registrada em lugar nenhum além do novo commit. Um bisect numa branch formada por picks aponta para a cópia, e não para a discussão original, a menos que existam linhas de -x. Picks repetidos entre branches de vida longa são sinal de que o modelo de branching, e não a ferramenta, precisa mudar.