Git rebase continuamente falla y requiere intervención manual de fusión

Question

Tengo un problema con el rebase del maestro en una rama 'desplegar' dentro de uno de mis repositorios.

Mi repositorio se configura de la siguiente manera:

master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master

Generalmente mi flujo de trabajo es:

1. Desarrollar en la rama maestra ... probar, sonreír, comprometerse.
2. Revisa la deploy rama
3. Ejecutar git rebase master en la rama de implementación: esto solía funcionar sin problemas
4. Presione al control remoto y luego ejecute cap deploy
5. Relájate

El problema que tengo ahora es que cuando ejecuto git rebase --continue en la rama de implementación, aparece un error requerido de fusión manual / combinación de 3 vías (no creo que el mensaje de error sea realmente lo suficientemente genérico para enviar). Git me dice que realice una fusión y luego use git rebase master --interactive para finalizar, lo que nunca funciona.

Lo que he encontrado 'funciona' se está ejecutando <=>, limpiando la lista de selección (hay 5 'confirmaciones' repetidas pero con diferentes números de referencia (mismo mensaje) en esta lista, así que elegiré uno de ellos) y luego haga la fusión manualmente. Una vez que haya hecho esto para cada confirmación, entonces puedo continuar con el rebase y todo es feliz ...

Hasta la próxima vez que necesite realizar un rebase.

Entonces, ¿alguien sabe lo que podría ser feliz? El proyecto no es realmente 'secreto', por lo que si es necesario puedo publicar mensajes, registros, gráficos de ramas, etc.

Gracias

Answer 1

Lo que parece que podría estar sucediendo es que ha cambiado el historial de confirmación de esas " repetido " se compromete de tal manera que tengan un sha1 diferente. Cada sha1 es exclusivo no solo del commit, sino también del historial de commit. Por lo tanto, es imposible (bueno, muy improbable que suceda durante la vida del universo), tener dos sha1 identitarios en la misma historia o tener dos sha1 en dos historias diferentes incluso. Si cambia algo en su confirmación, como con una enmienda o un rebase interactivo, cambiará el sha1. Por lo tanto, dos confirmaciones que podrían tener el mismo aspecto, en realidad se tratan de manera diferente.

Por lo tanto, es muy probable que haya rebaseado de la otra rama, haya realizado algún tipo de rebase interactivo o haya modificado las confirmaciones, continúe confirmando un poco más de código que modificó esa misma parte del código, y luego, en la próxima rebase, tiene conflictos porque las confirmaciones que tiene en su sucursal local que difieren de la sucursal de la que está haciendo un rebase se eliminan de la sucursal, el flujo ascendente se incluye incluyendo esa confirmación que ya obtuvo y cambió el sha1 de, y luego cuando se repiten las confirmaciones en la rama, termina con un conflicto porque el estado del código ha cambiado de lo que se esperaba de la confirmación porque se creó originalmente a partir de un historial diferente al que tiene ahora en su rama. Wow, esa fue una frase larga ...

Cuando estás " limpiando " arriba de la lista de selección ... lo que está haciendo es probable que elimine estas confirmaciones repetidas antes de volver a modificar, por lo que ahora no volverá a aplicar los cambios que ya se han aplicado, por lo que no habrá más conflictos.

Sin embargo, si solo quisiera resolver los conflictos durante el rebase, esta sería probablemente la mejor opción para que no elimine accidentalmente una confirmación que desea. Resolver los conflictos hará que el conjunto de cambios de ese compromiso sea diferente y aplicable al historial que tenga. Una vez que presiona esta resolución de conflicto de fusión, no debería ver los problemas nuevamente a menos que modifique las confirmaciones que ya se han presionado nuevamente.

Para encontrar qué archivos tienen los conflictos de fusión, haga lo siguiente:

git status

o

git ls-files -u

Una vez que sepa qué archivos tienen conflictos, si tiene una configuración de mergetool puede hacer:

git mergetool <file>

Si prefiere fusionar manualmente, puede encontrar los marcadores y líneas de fusión haciendo:

grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *

en el nivel superior de su ruta de repositorio y edite. Cuando edite manualmente, asegúrese de eliminar los marcadores y hacer que la versión final del archivo tenga el aspecto que desea ... git no hace nada especial con los marcadores por usted. Cuando haya terminado de editar manualmente, asegúrese de hacer

git add <file>

para agregar el archivo para agregarlo al índice y eliminar el indicador no combinado. Cuando haya terminado de resolver todos los archivos no fusionados, haga

git rebase --continue

Para completar el rebase.

Answer 2

Para que git rebase --continue funcione, debe fusionar los archivos en conflicto (edítelos, elija las partes que desee entre los marcadores de conflicto & # 8220; < < lt; < < < < & # 8221 ;, & # 8220; ======= & # 8221 ;, & # 8220; & Gt; & Gt; & Gt; & Gt; & Gt; & Gt; & Gt; & # 8221;) y luego git add al índice (el índice es donde se registran como en conflicto, al agregar un archivo se borra su estado en conflicto). Verifique la diferencia actual con git diff --cached, luego git log -p master..deploy si se ve bien.

Antes de intentar su rebase (o después de abortar una problemática), revise git rebase -i para ver las confirmaciones que está tratando de cambiar. Es uno de estos que está en conflicto con lo que tienes en master .

Las confirmaciones que está eliminando al eliminar su & # 8216; seleccione & # 8217; las líneas en log -p podrían no ser exactamente las mismas (aunque tengan el mismo & # 8216; asunto & # 8217; en su mensaje de confirmación). El hecho de que piense que solo debería haber uno de ellos indica que algo sospechoso está sucediendo con su rama deploy . ¿Son estos & # 8216; duplicados & # 8217; commits en la punta de deploy o hay otros commits después de ellos? Tal vez ver el contenido de esos & # 8216; a pescado & # 8217; commits (<=>, arriba) le dará una pista sobre su fuente.

Answer 3

Puede definir un atributo en el directorio padre de su " despliegue -específico " archivos, para seleccionar siempre el contenido de la rama de implementación en caso de fusión.

Para ver un ejemplo de administrador de fusión, consulte esta respuesta SO .

Otras se han discutido estrategias , pero la clave permanece: siempre considere una fusión como " una fusión de todo el proyecto " y no una fusión basada en archivos. De ahí los atributos para refinar esa fusión de todo el proyecto cuando se trata de alguna & Quot; special & Quot; archivos.