¿Cómo seleccionar un file de una twig para resolver conflictos durante la rebase de git?

Dado un git repo con dos twigs master y feature . Al volver a establecer la base de la twig de funciones en la parte superior del maestro utilizando el maestro de rebase master digamos que el file a.txt contiene un conflicto que debe resolverse antes de que la rebase pueda continuar.

Sé que puedo resolver el conflicto en tres pasos:

  1. abrir a.txt en mi editor resolver manualmente el conflicto
  2. llame a git add a.txt para decirle a git que he resuelto el conflicto manualmente
  3. llamar a git rebase --continue mover el rebase hacia adelante

¿Hay alguna manera de evitar el paso 1 diciendo a git que quiero la versión del file de la twig principal o quiero la versión del file desde la twig de características sin tener que hacer los pasos 1 y 2 anteriores?

Sí. De hecho, hay más de una forma de hacerlo.

Los commands rebase y merge (y cherry-pick, para el caso) todos toman la misma strategy y -X flags para pasar a la maquinaria de fusión de git subyacente. Para la estrategia recursive , " -Xours y " -Xtheirs eligen uno u otro "lado" de los files en el caso de un file modificado en ambas twigs fusionadas.

O bien, esto es bastante diferente, en los casos en que la fusión se detiene con un conflicto , puede usar git checkout con los --ours o --theirs flags, para elegir la versión de un lado o del otro. (Puede hacer esto con otros commands; aquí, me quedaré con --ours y --theirs ya que estos coinciden con los arguments de los commands que usan la maquinaria de fusión).

Por supuesto, esto es diferente porque puedes cambiar las opciones:

 $ git checkout main Switched to branch 'main' $ git merge branch ... conflicts in files A and B ... $ git checkout --ours -- A # takes main:A $ git checkout --theirs -- B # takes branch:B 

Tenga en count que esto es bastante diferente de la " estrategia nuestra" (lo anterior muestra la "estrategia recursive con la opción ours "). Con la " estrategia nuestra", ocurre algo completamente diferente. Comencemos sin eso, haciendo la misma fusión nuevamente:

 $ git checkout main && git merge branch ... conflicts ... $ git checkout --ours -- AB # take main:A and main:B 

Digamos que hay un tercer file, C , que git puede fusionarse por sí mismo. Cuando haces lo anterior, git se fusiona con C y tomas main:A y main:B Si git merge --strategy=ours branch que usar git merge --strategy=ours branch , sin embargo, git tomaría main:A , main:B y main:C Descartaría la branch:C cambia en lugar de fusionarlos automáticamente.

He usado git merge arriba porque hace que las cosas "nuestra" y "de ellos" "funcionen bien". Sin embargo, me desagrada la forma en que git los nombra, porque cuando estás haciendo una rebase, la versión de nosotros / ellos se intercambia, porque rebase funciona cambiando a la twig "otra" y haciendo una serie de selects de cereza. Es decir:

 $ git checkout mine; git rebase theirs 

funciona debajo haciendo el (muy) equivalente aproximado de:

 $ git checkout theirs; git cherry-pick theirs..mine 

y luego, arrastrando las tags de las twigs para que las twigs no se muevan realmente. (No es tan malo internamente 🙂 pero se las arregla para hacer --ours significa "suyo" y --theirs significa "nuestro", que es bastante malo externamente .)

Puedes usar:

 git checkout --ours -- path/to/file 

O:

 git checkout --theirs -- path/to/file 

… durante una fusión o rebase para elegir una versión particular de un file en conflicto; porque reescalar es un poco extraño , --theirs en este caso serían la versión de la function, --ours serían master .

Creo que lo que está buscando, que eliminará los tres pasos, es

git rebase master -X theirs

que resolverá automáticamente los conflictos a favor de la feature (la twig actualmente desprotegida), o

git rebase master -X ours

El sentido ours y el de theirs es contradictorio como arguments para rebase, como se señala en la descripción de la opción en http://git-scm.com/docs/git-rebase