Tire todas las confirmaciones de una rama, empujar compromete especificados a otra

Question

Tengo las siguientes ramas:

• master
• production

y las siguientes ramas remotas:

• origin/master
• origin/production

Tengo un script que recupera la rama origin/master y obtiene el diff de lo que ha cambiado desde mi último fetch (log -p master..origin/master). Luego me fusiono origin/master.

Las confirmaciones encontradas se envían a una herramienta de revisión de código.

Deseo enviar los commits exitosos - y solo ellos - a la rama de producción, y luego, por supuesto, al origin/production.

¿Cómo puedo hacer eso?

Además, tengo 2 scripts en ejecución: el que obtiene de origin/master, envía detalles a una base de datos y se fusiona, y el otro que estoy escribiendo que deberá enviar los commits correctos.

Me gustaría tener esos 2 scripts ejecutándose mientras se evitan las condiciones de carrera/conflicto de combinación. Como solo quiero trabajar con confirmaciones especificadas, ¿hay alguna manera de deshacerse de las confirmaciones que no quiero?

Answer 1

El término que creo que está buscando es una "selección de cereza". Es decir, tomar una sola confirmación desde el medio de una de las ramas y agregarlo a otro:

A-----B------C 
\ 
    \ 
    D 

convierte

A-----B------C 
\ 
    \ 
    D-----C' 

Esto, por supuesto, se puede hacer con el comando git cherry-pick.

El problema con este cometa es que git considera compromete a incluir toda la historia delante de ellos - por lo tanto, si tiene tres confirmaciones de este modo:

A-----B-----C 

Y tratar de deshacerse de B, usted tiene que crear una confirmación completamente nueva como esta:

A-----------C' 

Donde C 'tiene una ID de SHA-1 diferente. Del mismo modo, seleccionar un compromiso de una rama a otra consiste básicamente en generar un parche y luego aplicarlo, perdiendo así también la historia.

Este cambio de identificaciones de compromiso rompe la funcionalidad de fusión de git entre otras cosas (aunque si se usa con moderación hay heurísticas que se imprimirán sobre esto). Sin embargo, lo más importante es que ignora las dependencias funcionales: si C realmente usó una función definida en B, nunca lo sabrá.

Quizás una mejor forma de manejar esto sería tener ramas de grano más fino.Es decir, en lugar de solo tener un 'maestro', tener 'featureA', 'bugfixB', etc. Realice una revisión de código en una rama completa a la vez, donde cada rama está muy enfocada en hacer una sola cosa, y luego fusione una rama cuando termines Este es el flujo de trabajo para el que está diseñado git, y en qué es bueno :)

Si insistes en tratar las cosas al nivel de los parches, es posible que desees ver los darcs: considera que un repositorio es un conjunto de parches, y por lo tanto, la selección de cereza se convierte en la operación fundamental. Sin embargo, esto tiene su propio conjunto de problemas, como ser muy lento :)

Editar: Además, no estoy seguro de entender su segunda pregunta, sobre los dos scripts. ¿Tal vez podrías describirlo con más detalle, posiblemente como una pregunta separada para evitar que las cosas se vuelvan confusas?

Answer 2

que dan cuenta de esto es una cuestión de edad, sino que se hace referencia aquí: How to merge a specific commit in Git

Por lo tanto, una respuesta más reciente: Use ramas de características y tire de solicitudes.

el aspecto que tiene, donde Fa es una confirmación con la característica A, y FB es una confirmación con la función B:

  fA fC (bad commit, don't merge) 
     /\/
master ----A----B----C 
       \/
       fB 

peticiones de tracción están asociados con la funcionalidad de GitHub, pero realmente todo lo que quiero decir es que alguien tiene la responsabilidad de fusionar las ramas de características en maestra.