Fusionar file 'específico' (desde la twig de desarrollo) a maestro (twig)

Mi twig dev tiene varios files y confirmaciones de todos los desarrolladores, pero solo me interesa fusionar los cambios de un file específico.

File-A File-B File-C 

Necesito fusionar todo, desde File-B (en la twig dev) hasta master
Haga que File-B sea el mismo que File-B en dev-branch, (preservando todos los loggings de commit)

Incluso con la aclaración, todavía falta algo. Pero quizás puedas get lo que quieras usando git merge-file . O tal vez no.

Necesito fusionar todo, desde File-B (en la twig dev) hasta master

(OK hasta ahora)

Haga que File-B sea el mismo que File-B en dev-branch, (preservando todos los loggings de commit)

Esta parte no tiene sentido.

Primero, "fusionar" no significa "hacer lo mismo que".

En segundo lugar, el git log muestra commits . Los commits en un repository son el historial en el repository. Cada confirmación es una instantánea completa de un tree fuente. Commit 19afc3d puede contener 23 files, y la confirmación subsecuente o posterior b099ca2 puede contener 23 files del mismo nombre, 22 de los cuales tienen el mismo contenido. Pero son solo dos commits separados, cada uno con 23 files.

Agregar una nueva confirmación a un repository hace justamente eso: agrega una nueva confirmación, con una nueva instantánea.

Ejecutar git merge hace algo más complejo. Dependiendo del gráfico de compromiso existente y las opciones que suministre en el momento en que ejecuta git merge , puede hacer una fusión real. Lo hace atravesando el gráfico de compromiso para encontrar un compromiso base de fusión, que es el primer compromiso en el que las dos partes del gráfico vuelven a join:

 ...--A--B--C--D <-- master (HEAD) \ E--F--G <-- dev 

Aquí, la base de combinación es commit B Git puede entonces descubrir lo que hemos cambiado:

 git diff --find-renames <hash-of-B> <hash-of-D> 

y descubra lo que cambiaron:

 git diff --find-renames <hash-of-B> <hash-of-G> 

Git luego combina estos cambios para get ambos sets de cambios. Entonces, si, con respecto al compromiso B , cambiamos el File-B para agregar tres líneas, y ellos cambiaron el File-B para eliminar un set no relacionado de tres líneas, el cambio total será: agregue nuestras tres líneas y elimine sus tres líneas.

Si Git puede combinar todos los cambios en todos los files, Git realizará una nueva confirmación de fusión , con dos padres en vez de uno:

 ...--A--B--C--D---H <-- master (HEAD) \ / E--F--G <-- dev 

Es una combinación de fusión (combinación como un adjetivo) o una fusión (fusión como nombre), hecha utilizando, como su instantánea, todos los files de la base B cambiados por la combinación de nuestros cambios ( B hasta- D ) y sus cambios ( B -a- G ).

Algunos de los files en H pueden ser iguales a algunos de los files en cualquiera de B , D y G , pero si es así, eso se debe a los resultados de combinar los dos sets de cambios.

Si ejecuta git merge-file , debe proporcionar la versión base del file y las dos versiones de bifurcación del file. Git combinará los cambios en ese único file, de la forma en que normalmente lo hace Git con una fusión real. Git no realizará un nuevo commit del resultado, y si lo haces, no será un commit de fusión , solo será un commit ordinario:

 ...--A--B--C--D---H <-- master (HEAD) \ E--F--G <-- dev 

Si literalmente quieres que el file sea el mismo , es decir, ignoras cualquier cambio que hayamos hecho en commit C y D , y simplemente tomas la versión del file desde commit G directamente, puedes hacerlo con git checkout dev -- File-B . Nuevamente, comprometer el resultado hará una confirmación ordinaria, sin fusión.

Si desea realizar una fusión, realizar una combinación adecuada de File-B pero ignorar sus cambios en todos los files, excepto en un file específico, que requiere un set de commands Git ligeramente más complicado:

 git merge --no-commit dev git checkout master -- [all files except for FileB] 

(o, de manera equivalente, guarde la versión fusionada en algún lugar, verifique todo desde el master con git checkout master -- . , luego vuelva a colocar el file fusionado y git add FileB ). Sin embargo, tenga en count que al registrar esto como un commit de fusión le dice a Git que el resultado correcto para hacer la fusión completa es lo que acaba de cometer. Si desea, más adelante, fusionar otros cambios de dev , lo hará mucho más difícil para usted.