¿Cuál es la mejor manera de poner parche en un subrango de una sucursal?

Question

En Subversion, es fácil fusionar un rango de conjuntos de cambios/diffs de una rama usando "svn merge -r a: b mybranch". Pero en git, encontré que solo es posible seleccionar una confirmación de una sucursal para aplicar ese parche a mi rama de trabajo actual. Entonces, me pregunto si existe una manera rápida de aplicar todas las confirmaciones de una sola vez entre dos etiquetas en una rama de corrección de errores a mi rama maestra actual.

Answer 1

La manera más fácil de realizar la acción que está buscando es con git rebase. Aquí hay una receta. Supongamos que la etiqueta A es la confirmación, sobre la cual se basa la serie de parches que desea seleccionar y esa etiqueta B es la confirmación del parche final de la serie. Además, supongamos que br es el nombre de la rama actual y la rama donde se aplicará la nueva serie de parches.

# Checkout a new temporary branch at the current location 
git checkout -b tmp 

# Move the br branch to the head of the new patchset 
git branch -f br B 

# Rebase the patchset onto tmp, the old location of br 
git rebase --onto tmp A br 

Answer 2

Por lo que sé, no se puede git merge de esta manera. Merge está destinado a unir dos ramas que tienen un historial en común, no para recoger varias confirmaciones o series de parches. Siento que elegir es lo que estás pidiendo.

Usted puede utilizar cereza Git (no cereza recoger!) Para saber qué se compromete debe ser insertado en su rama, a continuación, git cherry-pick ellos. También puede pedir explícitamente git cherry-pick para registrar el origen de esos commits en caso de que esté eligiendo cuidadosamente de una sucursal pública. Esta es probablemente la mejor manera de lidiar con este problema. (Otro podría haber sido exportarlos a través de git format-patch y luego importarlos con git-am/git-apply, pero eso probablemente sería más lento, además no registrará el origen de los commits.)

EDITAR: "Público" (rama) se debe entender como algo no sujeto a la edición de historial. Por supuesto, puede hacerlo al desarrollar software de código cerrado sin que el código sea público.

Answer 3

La manera más fácil que he encontrado para hacer esto es:

git cherry-pick starthash..endhash 

nota que los dos puntos no tienen espacios separándolas de las etiquetas de hash.