tag - Git rebase: los conflictos siguen bloqueando el progreso

git tag best practices (6)

Aquí hay algunas ideas:

Antes de comenzar la rebase, asegúrate de que no estás en medio de una rebase o am. Do: rm -rf .git/rebase-apply
- si usas Bash, mejora tu prompt bash para que siempre presente esta información automáticamente
Un poco que mencionaste no entendí: "y luego intentas continuar: al principio intento un compromiso:" ... ¿por qué comprometer? En el medio de una rebase, creo que solo deberías "agregar git" después de ordenar o "git rm" para lanzar cambios o confirmar una eliminación de archivos. Quizás eso arruinó algo?
prueba una fusión en lugar de una rebase
prueba algunas de las ideas de Ethan Rowe

Tengo una rama git (llamada v4), que se hizo desde el maestro ayer. Hubo un par de cambios en el maestro, que quiero entrar en v4. Entonces, en v4, traté de hacer una rebase desde el maestro, y un archivo sigue arruinando cosas: un archivo de texto de una línea, que contiene el número de versión. Este archivo es app/views/common/version.txt , que antes de rebasar contiene este texto:

v1.4-alpha-02

Esto es lo que estoy haciendo:

> git rebase master First, rewinding head to replay your work on top of it... Applying: new version, new branch error: patch failed: app/views/common/version.txt:1 error: app/views/common/version.txt: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging app/views/common/version.txt CONFLICT (content): Merge conflict in app/views/common/version.txt Failed to merge in the changes. Patch failed at 0001 new version, new branch When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort".

El version.txt ahora se ve así:

<<<<<<< HEAD:app/views/common/version.txt v1.4-alpha-02 ======= v1.4-alpha-01 >>>>>>> new version, new branch:app/views/common/version.txt

Entonces, lo arreglo y se ve así ahora:

v1.4-alpha-02

y luego traté de continuar: al principio intento un compromiso:

> git commit -a -m "merged" # Not currently on any branch. nothing to commit (working directory clean)

No hay suerte allí. Entonces, estaba tratando de agregar el archivo:

git add app/views/common/version.txt

Ninguna respuesta. No hay noticias son buenas noticias, supongo. Por lo tanto, trato de continuar:

> git rebase --continue Applying: new version, new branch No changes - did you forget to use ''git add''? When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort".

Es en este punto, después de dar vueltas con esto, que estoy golpeando mi cabeza fuera del escritorio.

¿Que está pasando aqui? ¿Qué estoy haciendo mal? ¿Alguien me puede aclarar?

EDITAR - para unutbu

Cambié el archivo como sugirió y recibo el mismo error:

Cambiar la aplicación / views / common / version.txt a

v1.4-alpha-01

En este punto de la rebase, recuerde que está resolviendo conflictos de combinación para mostrar la progresión de la rama no maestra .

Por lo tanto, en el rebase desde

A---B---C topic / D---E---F---G master

A*--B*--C* topic / D---E---F---G master

el conflicto que está resolviendo está en cómo crear A * en la rama de tema.

Entonces, después de hacer git rebase --abort , los comandos deberían ser

git checkout topic git rebase master < make edits to resolve conflicts > git add . git rebase --continue

Citando desde aquí: http://wholemeal.co.nz/node/9

¿Huh?!? No, no me olvidé de usar git add, lo hice ... como ... ¡hace 2 segundos!
Resulta que debido a que no hay cambios desde el parche, Git sospecha que algo salió mal. Git espera que se haya aplicado un parche, pero el archivo no se modificó.
El mensaje de error no es muy intuitivo, pero sí contiene la respuesta. Solo necesitamos decirle a rebase que se salte este parche. Tampoco es necesario corregir los marcadores de conflicto en el archivo. Terminará con la versión de archivo de la rama en la que está realizando el rebase.

$ git rebase --skip

El comportamiento que estás viendo no es lo que esperaría de una típica rebase con solo este conflicto. Considere usar una rama separada para hacer esta rebase (especialmente si ya ha enviado las confirmaciones de forma remota que está reenviando). Además, git mergetool puede ser útil para resolver conflictos y recordar emitir un git add .

En este ejemplo mínimo, la rebase funciona como se esperaba. ¿Puedes dar un ejemplo que muestre el comportamiento que estás viendo?

#!/bin/bash cd /tmp mkdir rebasetest cd rebasetest git init echo ''v1.0'' > version.txt git add version.txt git commit -m ''initial commit'' git checkout -b v4 echo ''v1.4-alpha-01'' > version.txt git add version.txt git commit -m ''created v4'' git checkout master git merge v4 echo ''v1.4-alpha-01-rc1'' > version.txt git add version.txt git commit -m ''upped version on master to v1.4-alpha-01-rc1'' git checkout v4 echo ''v1.4-alpha-02'' > version.txt git add version.txt git commit -m ''starting work on alpha-02'' git rebase master echo ''v1.4-alpha-02'' > version.txt git add version.txt git rebase --continue

Ese mensaje de error es el resultado de su git commit -a -m "merged" . Si solo arreglas el archivo, entonces ejecuta git add <file> , y git rebase --continue , debería funcionar bien. git rebase --continue está intentando hacer una confirmación, pero descubriendo que no hay cambios pendientes para confirmar (porque ya los cometiste).

Me encontré con un problema similar con una rebase. Mi problema fue causado porque uno de mis commits solo cambió un archivo, y cuando resolví, descarté el cambio introducido en este commit. Pude resolver mi problema omitiendo la confirmación correspondiente ( git rebase --skip ).

Puede reproducir este problema en un repositorio de prueba. Primero crea el repositorio.

$ mkdir failing-merge $ cd failing-merge $ git init Initialized empty Git repository in $HOME/failing-merge/.git/

Luego, ingrese el contenido original de version.txt en el maestro.

$ echo v1.4-alpha-02 > version.txt $ git add version.txt $ git commit -m initial [master (root-commit) 2eef0a5] initial 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 version.txt

Crea la rama v4 y cambia el contenido de version.txt .

$ git checkout -b v4 Switched to a new branch ''v4'' $ echo v1.4-alpha-03 > version.txt $ git add version.txt $ git commit -m v4 [v4 1ef8c9b] v4 1 files changed, 1 insertions(+), 1 deletions(-)

Regresa a master y cambia el contenido de version.txt para que haya un conflit durante la rebase.

$ git checkout master Switched to branch ''master'' $ echo v1.4-alpha-04 > version.txt $ git add version.txt $ git commit -m master [master 7313eb3] master 1 files changed, 1 insertions(+), 1 deletions(-)

Vuelve a la rama v4 e intenta volver a establecer la base. Falla con un conflit en version.txt como estaba planeado.

$ git checkout v4 Switched to branch ''v4'' $ git rebase master First, rewinding head to replay your work on top of it... Applying: v4 Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging version.txt CONFLICT (content): Merge conflict in version.txt Recorded preimage for ''version.txt'' Failed to merge in the changes. Patch failed at 0001 v4 When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". $ cat version.txt <<<<<<< HEAD v1.4-alpha-04 ======= v1.4-alpha-03 >>>>>>> v4

Resolvemos el conflicto seleccionando el contenido master de version.txt . Agregamos el archivo y tratamos de continuar nuestra rebase.

$ echo v1.4-alpha-04 > version.txt $ git add version.txt $ git rebase --continue Applying: v4 No changes - did you forget to use ''git add''? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort".

Falla ! Veamos qué cambios cree que hay en nuestro repositorio.

$ git status # Not currently on any branch. nothing to commit (working directory clean)

Ah ah, no hay cambio. Si lee en detalle el mensaje de error anterior, git nos informó de esto y le recomendó usar git rebase --skip . Nos dijo "Si no queda nada para el escenario, es probable que otra cosa ya haya introducido los mismos cambios, es posible que desee omitir este parche". Así que saltamos la confirmación y la rebase tiene éxito.

$ git rebase --skip HEAD is now at 7313eb3 master

git rebase --skip : tenga en cuenta que git rebase --skip completamente la confirmación que git intentó rebase. En nuestro caso, esto debería estar bien, ya que git se queja de que se trata de una confirmación vacía. Si crees que has perdido los cambios una vez completada la rebase, puedes usar git reflog para obtener el id. De confirmación de tu repositorio antes de la rebase, y usar git reset --hard para volver a tu depósito en ese estado (este es otro operación destructiva).