Flujo de trabajo de Git Cherry-pick vs Merge

Suponiendo que soy el mantenedor de un repositorio, y quiero obtener cambios de un contribuyente, hay algunos flujos de trabajo posibles:

1. cherry-pickCada uno me comprometo desde el control remoto (en orden). En este caso, git registra la confirmación como no relacionada con la rama remota.
2. En mergela rama, agrego todos los cambios y agrego un nuevo compromiso de "conflicto" (si es necesario).
3. I mergecada confirmación de la rama remoto individualmente (de nuevo en orden), permitiendo que los conflictos que se registran para cada confirmación, en lugar de agrupar todos juntos como una sola.
4. Para completar, podría hacer una rebase(¿igual que la cherry-pickopción?), Sin embargo, entiendo que esto puede causar confusión para el contribuyente. Quizás eso elimina la opción 1.

En ambos casos 2 y 3, git registra el historial de ramificaciones de las confirmaciones, a diferencia de 1.

¿Cuáles son las ventajas y desventajas entre el uso de uno cherry-picko los mergemétodos descritos? Tengo entendido que el método 2 es la norma, pero creo que resolver una gran confirmación con una sola fusión de "conflicto" no es la solución más limpia.

Ambos rebase (y cherry-pick) y mergetienen sus ventajas y desventajas. Argumento por mergeesto, pero vale la pena entender ambos. (Busque aquí una respuesta alternativa y bien argumentada que enumere los casos en los que rebasese prefiere).

mergese prefiere sobre cherry-picky rebasepor un par de razones.

1. Robustez . El identificador SHA1 de un commit lo identifica no solo en sí mismo sino también en relación con todos los otros commits que lo preceden. Esto le ofrece una garantía de que el estado del repositorio en un SHA1 determinado es idéntico en todos los clones. No hay (en teoría) ninguna posibilidad de que alguien haya hecho lo que parece el mismo cambio, pero en realidad está corrompiendo o secuestrando su repositorio. Puede elegir cambios individuales y probablemente sean los mismos, pero no tiene ninguna garantía. (Como un problema secundario menor, los nuevos commits seleccionados con cereza ocuparán un espacio adicional si alguien más selecciona nuevamente en el mismo commit, ya que ambos estarán presentes en la historia incluso si sus copias de trabajo terminan siendo idénticas).
2. Facilidad de uso . La gente tiende a entender elmerge flujo de trabajo con bastante facilidad. rebasetiende a considerarse más avanzado. Es mejor comprender ambos, pero las personas que no quieren ser expertos en el control de versiones (que en mi experiencia ha incluido a muchos colegas que son muy buenos en lo que hacen, pero que no quieren pasar el tiempo extra) tienen más facilidad. El tiempo se acaba de fusionar.

Incluso con un flujo de trabajo pesado de fusión rebaseycherry-pick aún son útiles para casos particulares:

1. Una desventaja mergees la historia desordenada. rebaseevita que una larga serie de confirmaciones se dispersen en su historial, como lo serían si se fusionara periódicamente en los cambios de otros. De hecho, ese es su propósito principal mientras lo uso. Lo que quieres tener mucho cuidado es nuncarebase codificar lo que ha compartido con otros repositorios. Una vez que se edita una confirmación, pushalguien más podría haberse comprometido además, y el rebase causará, en el mejor de los casos, el tipo de duplicación discutida anteriormente. En el peor de los casos, puede terminar con un repositorio muy confuso y errores sutiles, le llevará mucho tiempo descubrirlo.
2. cherry-pick es útil para probar un pequeño subconjunto de cambios de una rama de tema que básicamente ha decidido descartar, pero se dio cuenta de que hay un par de piezas útiles.

En cuanto a preferir fusionar muchos cambios sobre uno: es mucho más simple. Puede ser muy tedioso hacer fusiones de conjuntos de cambios individuales una vez que comience a tener muchos de ellos. La resolución de fusión en git (y en Mercurial, y en Bazar) es muy muy buena. No se encontrará con problemas importantes al fusionar incluso ramas largas la mayor parte del tiempo. En general, combino todo de una vez y solo si obtengo una gran cantidad de conflictos hago una copia de seguridad y vuelvo a ejecutar la fusión por partes. Incluso entonces lo hago en grandes trozos. Como un ejemplo muy real, tuve un colega que tenía 3 meses de cambios para fusionar, y obtuve unos 9000 conflictos en la base de código de línea 250000. Lo que hicimos para arreglar es fusionar el valor de un mes a la vez: los conflictos no se acumulan linealmente, y hacerlo en partes resulta en mucho menos de 9000 conflictos. Todavía era mucho trabajo, pero no tanto como tratar de hacerlo un compromiso a la vez.

En mi opinión, la selección de cerezas debe reservarse para situaciones raras en las que se requiere, por ejemplo, si realizó alguna corrección directamente en la rama 'maestra' (tronco, rama de desarrollo principal) y luego se dio cuenta de que debería aplicarse también a 'mantenimiento '. Debe basar el flujo de trabajo en fusión o rebase (o "git pull --rebase").

Recuerde que la confirmación seleccionada o modificada es diferente desde el punto de vista de Git (tiene un identificador SHA-1 diferente) que el original, por lo que es diferente de la confirmación en el repositorio remoto. (Rebase generalmente puede lidiar con esto, ya que verifica la identificación del parche, es decir, los cambios, no una identificación de confirmación).

También en git puedes fusionar muchas ramas a la vez: la llamada fusión de pulpo . Tenga en cuenta que la fusión de pulpos tiene que tener éxito sin conflictos. Sin embargo, puede ser útil.

HTH

Rebase y Cherry-pick es la única forma de mantener limpio el historial de confirmaciones. Evite usar la fusión y evite crear conflictos de fusión. Si está utilizando gerrit, configure un proyecto en Fusionar si es necesario y un proyecto en modo selección de cereza e inténtelo usted mismo.