APRENDER. PRATICAR. EVOLUIR.Identificar o problema que o patch resolve
Uma release antiga de um serviço fictício de pagamentos precisa de uma correção presente em desenvolvimento. A equipa não pode integrar toda a funcionalidade nova. Começa por identificar o defeito, o commit que o corrige, os pré-requisitos e os testes que demonstram o comportamento esperado. A unidade de decisão não é apenas o ID do commit: é a alteração no contexto da release de destino. Uma chamada a uma função nova pode aplicar sem conflito mesmo quando essa função não existe na release. Regista essas dependências antes de escolher os commits a transportar.
Observar identidade e rastreabilidade
O laboratório cria uma correção na branch source e um commit diferente na branch de destino. Cherry-pick -x aplica a correção ao destino. O novo commit tem outro ID, o conteúdo esperado aparece e a mensagem inclui a origem no caso sem conflito executado. O antecessor diferente faz parte da identidade do novo commit. A ligação à origem ajuda a revisão, mas não é aprovação nem prova de compatibilidade. Compara a alteração no destino, confirma os testes relevantes e associa o resultado ao novo commit efetivamente proposto para release.
Decidir perante um conflito
Num segundo repositório, source e main mudam a mesma linha para intenções diferentes. O cherry-pick falha com conflito. A experiência parte de uma worktree limpa e executa --abort; HEAD, conteúdo de destino e estado limpo são repostos. Esse resultado está delimitado pelo estado inicial controlado. Se a equipa decidir continuar, integra a intenção das alterações, prepara a resolução e usa --continue. Se decidir saltar um commit, --skip pode prosseguir a sequência. --quit apenas esquece a operação em curso; não deve ser apresentado como equivalente a cancelar e regressar à base.
Rever a versão nova de uma série
Depois de uma revisão ou rebase, compara os dois intervalos explícitos com range-diff para perceber que patches mudaram. A comparação apoia a leitura humana e não executa os testes da aplicação. Também não constitui um formato estável de parsing entre versões. Num exercício de revisão, o autor removeu um pré-requisito da série e manteve a correção final. O revisor deve perceber essa mudança e pedir evidência de compatibilidade. Se um patch ficar vazio, confirma se o comportamento já está presente ou se outra resolução eliminou a alteração. Decide saltar ou conservar um registo segundo a política aplicável.
Construir a decisão de aceitação
A nota de aceitação deve ligar defeito, origem, destino, resolução de conflitos, dependências e resultados de testes. No exercício, não há autorização para levar alterações não relacionadas só para tornar o cherry-pick mais simples. Uma alternativa é adaptar a correção à API antiga ou adiar até existir uma solução revista. Os laboratórios comprovam comportamento local dos comandos em Git 2.50.1; os tópicos de range-diff e patches vazios foram revistos na documentação atual e não executados pelo runner. Resumo: aplicação textual, rastreabilidade e aceitação funcional exigem evidências próprias. Relaciona esta aula com CI/CD, testes, release e integração de branches.
A correção aplicou com outro ID; numa experiência separada, --abort repôs o destino após conflito.
Armadilhas comuns
Sem conflito como compatível; -x como aprovação; quit como abort; range-diff como API estável.
Tópicos relacionados: Working tree, index e commit · Branches, merge e rebase · Reverter alterações e preservar trabalho
Revê o patch no destino e escolhe a operação do sequenciador segundo a decisão real.
Referência: Git: cherry-pick · Git 2.56; workflow concepts compatible with modern Git 2.x