¿Qué es git cherry-pick y cuándo es útil?

Question

Accepted Answer

**git cherry-pick** aplica un **commit específico** de una rama a otra — copiando solo los cambios de ese commit, sin fusionar toda la rama. Es útil para aplicar selectivamente cambios particulares, como hacer backport de una corrección. ## Cómo funciona cherry-pick ```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 toma los cambios de un commit específico y los aplica como un nuevo commit en tu rama actual — selectivamente, sin traer el resto de la rama de origen. ## Casos de uso comunes ```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 ``` ## Advertencias ```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 qué es importante Comprender `git cherry-pick` es valioso para **aplicar selectivamente cambios específicos**, una capacidad útil para situaciones particulares, por lo que es conocimiento práctico de Git que vale la pena saber. La capacidad central — aplicar solo los **cambios de un commit específico** a otra rama sin fusionar toda la rama — aborda necesidades reales que la fusión no puede manejar de manera limpia. El uso más común e importante es el **backport**: aplicar una corrección de bug específica de la rama principal a una rama de release o mantenimiento, obteniendo solo esa corrección sin fusionar todos los otros cambios (posiblemente inestables o no liberados) de main en la rama de release — una necesidad frecuente al mantener software liberado. Otros usos incluyen aplicar un commit único listo mientras el resto de su rama no está listo, mover un commit hecho en la rama incorrecta a la correcta, y extraer selectivamente un cambio. Comprender las **advertencias** es importante para usar cherry-pick apropiadamente: crea **commits duplicados** (los mismos cambios con hashes diferentes en cada rama), que pueden causar confusión o conflictos si las ramas se fusionan más tarde, por lo que debe usarse **deliberadamente para necesidades selectivas** en lugar de como método de integración rutinaria (merge o rebase son mejores para integrar ramas completas), y hacer cherry-pick de muchos commits es una señal de que probablemente quieras un merge en su lugar. Este criterio — usar cherry-pick para situaciones específicas y selectivas (especialmente backporting) mientras se prefiere merge/rebase para integración rutinaria — refleja una práctica sólida de Git. Ya que aplicar selectivamente cambios específicos (especialmente hacer backport de correcciones a ramas de release) es una necesidad real, ocasionalmente importante, y ya que cherry-pick es la herramienta para ello (con advertencias sobre su uso apropiado), comprender `git cherry-pick` — cómo funciona, sus casos de uso clave como backporting, y cuándo usarlo versus merge/rebase — es conocimiento práctico y valioso de Git para manejar los escenarios de cambios selectivos que surgen al mantener y gestionar software entre ramas.