Solicitud de gitlab para fusionar la rama A en desarrollo (3 confirmaciones detrás) ¿debo preocuparme?

Al crear una solicitud de fusión en gitlab, a menudo recibo un mensaje: Solicitud para fusionar la rama A en desarrollo ([x] se compromete detrás) ¿qué quiere decirme gitlab? ¿Debo preocuparme o necesito arreglar algo (qué)?

Después de un tiempo un solicitud de fusión está abierto en un proyecto, es normal que la versión de la rama que está tratando de fusionar quede obsoleta debido a que otras personas fusionan sus propios cambios.

Gitlab lo ayuda al mostrar cuánto la versión de la sucursal que actualizó está detrás de la sucursal remota.

Estar detrás no supondrá ningún obstáculo para el acto de fusionarse, pero es una práctica común para rebase sus confirmaciones en la parte superior de la rama en la que se está fusionando. Esto hará que su solicitud de fusión se actualice colocando sus confirmaciones cronológicamente después de las que ya están en esa rama. Ese enfoque facilita el trabajo de la persona responsable de la fusión porque el mismo autor ya ha resuelto cualquier conflicto que hubiera ocurrido.

Para hacer un rebase siguiendo el escenario que propusiste sería así:

# Add a remote named `upstream` pointing to the original repository
git remote add upstream https://gitlab.example.com/example/your_project.git

# Fetch the latest commmits from `upstream`
git fetch upstream

# Checkout our branch-A
git checkout branch-A

# Rebase our branch on top of the `upstream/develop` branch
git rebase upstream/develop

# If needed fix any conflicts that may have appeared and then `git rebase --continue`  

# Push the changes to the branch of your merge request
git push --force origin branch-A

Nota: El --force la bandera es necesaria cuando presiona porque está reescribiendo el historial de confirmación de origin/branch-A. De documento de git:

[–force] puede hacer que el repositorio remoto pierda confirmaciones; utilícelo con cuidado.

Si ve un mensaje ‘detrás de X confirmaciones’, gitlab indica que la rama en la que se está fusionando se ha movido desde el punto donde se bifurcó.

Cuando revisa las diferencias en gitlab, pueden parecer confusos, lo que posiblemente sugiera que está a punto de deshacer los cambios que se implementan en confirmaciones posteriores en la rama de destino.

Si quiere estar seguro de que está viendo exactamente los cambios que realizará la fusión, lo más seguro es actualizar la rama que desea fusionar fusionando primero en la rama de destino…

# fetch the latest code on all branches
git fetch

# checkout your working branch (if you're not already on it)
git checkout branch-A

# merge in the target branch
git merge origin/develop

Solucione los conflictos que puedan surgir, luego comprométalos:

# stage changes & commit
git add .
git commit

# push changes to origin
git push

Si ahora actualiza la página de solicitud de fusión en gitlab, el mensaje ‘detrás’ desaparecerá y las diferencias reflejarán solo los cambios que ha realizado.

Esto es mucho más seguro que reorganizar su rama, ya que no requiere un --force empujar. También significa que la cronología de la línea de tiempo de git coincide con lo que realmente sucedió, por lo que si está tratando de rastrear un problema en el futuro, no se dejará engañar por una reescritura de la historia.

La desventaja es que el historial de confirmaciones puede verse un poco más desordenado.

Además de la respuesta de @alejdg, para evitar esto

[–force] puede hacer que el repositorio remoto pierda confirmaciones; utilícelo con cuidado.

También podrías usar --force-with-lease que es mas seguro que --forcesi se insertan otras confirmaciones entre su rebase y tu push --force más información

Además de las respuestas anteriores, generalmente hago lo siguiente para reorganizar mi sucursal local y presionar. Por lo general, tendré un origen remoto agregado al repositorio local de git, si soy un colaborador.

git pull
git checkout <your-branch>
git rebase origin/<remote-branch>
git push --force origin <your-branch>

Esta es la comprensión de un principiante de lo que está pasando. Encontrará respuestas en git con un nivel más alto de “redacción git”. Pero así es como encontré mis pasos a través de la jungla de git. 😉 Espero que ayude a algún otro principiante.

Comience revisando su rama principal (aquí desarrollar):

git checkout develop
git pull --all

Luego cambie a su nueva rama-A (en la que se ha trabajado en paralelo con otras confirmaciones que ya están fusionadas en “desarrollar”).

Puede elegir cada compromiso por separado para ser más cauteloso (recomendado) o volver a basar encima de todos los compromisos anteriores de ese último MR.

También, en general, busque stash y stash applyentonces no necesita ninguna confirmación, es mucho más fácil.

git checkout branch-A
git stash #(if you do not use commit, stash is recommended)
git rebase -i develop

-i significa interactivo, lo que significa que deberá cambiar las cosas en un editor emergente.

(Si no usa -ino obtiene el editor, que también debería estar bien desde entonces, la misma configuración se usará automáticamente, pero eso es solo en este caso, en otros casos, es posible que realmente lo necesite, por lo que parece bueno acostumbrarse ese editor).

Este “editor de tareas pendientes” se abre con las confirmaciones que llevaron al último MR para “desarrollar” (que es como el principal en su caso).

Deja el pick delante de todas las confirmaciones en ese “todo-editor”, este es el valor predeterminado de todos modos, y cambie solo el último a edit en lugar de pick ya que su nuevo compromiso será editado por todos los compromisos que haga a continuación, no por los otros compromisos. Su nueva confirmación deberá estar encima del MR de la rama “desarrollar”, y todas las demás confirmaciones seleccionadas deben ser las anteriores al último MR con “desarrollar”.

Parece que:

Luego escriba y cierre ese editor y ahora verá todos los conflictos de la primera “selección” cuando busque

git diff

o mejor, ingrese a codium/vscode y acepte solo el código actual o entrante en cada conflicto (los archivos y carpetas con conflictos están marcados en rojo, y en el archivo, use la flecha hacia arriba/abajo para encontrar los conflictos).

Entonces:

git rebase --abort

No git commit o git push durante rebaseen su lugar, utiliza --abort y comience a reorganizar nuevamente, o use git rebase --continue si está seguro de lo que está haciendo y no necesita verificar los resultados intermedios. push puede dañar su árbol de confirmación, commit --amend cambiará las confirmaciones anteriores, y commit creará nuevos compromisos a partir de los antiguos.

Rebase no es para esto. cuando usas rebasedesea volver al punto de partida al final y solo entonces puede git commit --amend y git push -f si es necesario.

De todos modos. Continuando con el trabajo:

Repita los pasos anteriores para cada confirmación, la siguiente sería la segunda elección. La tercera confirmación ya es la confirmación de “edición”. Si llega a eso, repita nuevamente los pasos anteriores, y cuando ya no haya conflictos:

git add .
git stash apply #(or if you use commit: git commit --amend)
git push -f

Y ha configurado su nueva rama además del trabajo que estaba en su último “desarrollo” MR.

*En mi caso, la rebase en el “desarrollo” también me llevó a la confirmación de MR del propio MR de “desarrollo” anterior. Terminé agregando una confirmación duplicada de ese MR, que estaba mal. Esto sucede si usted – incorrectamente – commit --amend en una confirmación de MR existente que ya está fusionada. Por lo tanto, tenía una confirmación más antes de mi última confirmación, por lo que tenía dos confirmaciones en lugar de una encima del “desarrollo”.

Por lo tanto, mejor no uses commit, sino stash / stash apply en cada confirmación seleccionada.*