¿Cómo resolver un conflicto de combinación con composer.lock usando git flow?

Estoy trabajando en un proyecto de Laravel y uso git-flow para administrar mis cambios. Mi twig de desarrollo tiene dos compromisos antes de una twig de funciones que he completado recientemente llamada feature / registration-captcha . Quiero fusionar esta twig de características en la twig de desarrollo.

enter image description here

El compromiso más reciente que realicé y que luego se fusionó con la twig de desarrollo fue simplemente ejecutar la composer update para actualizar un package que tenía un error. Entonces, el file composer.lock ha sido modificado.

La característica característica / logging-captura de la twig consistía en agregar un package de captcha y la interfaz de usuario de captcha a una página de logging. Entonces, esto también modificó el file composer.lock .

Cuando estoy sentado en la twig de características intenté fusionar la confirmación, desde el Árbol de fonts, seleccionando Depósito> Flujo de Git> Característica de finalización , luego seleccionando las siguientes opciones en la window emergente de la function Finalizar :

enter image description here

Luego me presentan el siguiente post:

enter image description here

Esto da como resultado un file composer.lock con los conflictos de combinación que deben resolverse. Pensé que la mejor manera de abordar esto sería eliminar composer.lock y crear una nueva copy actualizada ejecutando la composer update composer update --lock o la composer update --lock , agregando el file composer.lock composer update --lock y composer update --lock el cambio. Después de hacer esto mis commits se ven así:

enter image description here

Cuando git status desde la línea de command, se muestra lo siguiente:

 c:\my-project (HEAD detached at 2a9ff12) λ git status rebase in progress; onto 3070450 You are currently rebasing branch 'feature/registration-captcha' on '3070450'. (all conflicts fixed: run "git rebase --continue") nothing to commit, working directory clean 

Así que pensé que lo correcto era ejecutar git rebase --continue , después de lo cual recibí el siguiente post:

 c:\my-project (HEAD detached at 2a9ff12) λ git rebase --continue Applying: add non captcha to registration page 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 prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". 

Si ejecuto el git status nuevamente, se me muestra el mismo post que la última vez que ejecuté el git status .

Entonces ahora me pregunto:

  • ¿Qué se supone que debo hacer aquí para terminar la rebase / fusión?
  • ¿Lo estoy haciendo todo mal?
  • ¿Debería manejar los conflictos que puedan popup al actualizar los packages de manera diferente?

¡Cualquier ayuda será enormemente apreciada, gracias!

¿Lo estoy haciendo todo mal?

Como git es muy flexible con respecto a los flujos de trabajo, siempre hay más de una forma de hacerlo. 😉

Lo que salió mal en este caso específico – si entiendo correctamente la secuencia de tus acciones – es que comenzaste la rebase antes de que la fusión finalizara, porque querías usarla para resolver el conflicto de fusión. Así es como terminaste en el estado de cabeza separada.

¿Debería manejar los conflictos que puedan popup al actualizar los packages de manera diferente?

Si se encuentra con un conflicto de fusión, se encuentra en el estado donde se inició la fusión, pero no se finalizó. Se puede anular (pero no hay fusión) o finalizar (resolver conflictos y confirmar cambios).

Con composer.lock , primero trataría de resolver manualmente el conflicto de fusión, ya que los conflictos deberían ser muy obvios: algunos packages se actualizaron y otro se agregó; el conflicto es tal vez un par de líneas modificadas en ambos lados. composer.lock es un file en formatting JSON, ya que tiene disponibles las versiones de ambas twigs que funcionan correctamente, esto debería ser fácil de corregir. Tal vez SourceTree ofrezca una herramienta de resolución de conflictos aquí (no la uso), pero esto también es posible en un editor de text ( git marca los bloques en conflicto ) o con herramientas como Meld y VimDiff y otras (que puede llamar git mergetool ) y presentarle las 3 o 4 windows de text: las versiones de las dos twigs, la window de resolución de conflictos con el estado actual (aquí realiza los cambios) y (opcional) la versión base de ambas twigs y para un lado a lado comparación. Guárdelo, pruébelo (la composer install le indicará si algo está mal con el file composer.lock , o el composer validate ). A continuación, agregue y confirme: git todavía sabe que la confirmación pertenece a la fusión.

Otro método de resolución de conflictos en este caso específico (los files no fueron editados manualmente sino por un progtwig y usted sabe lo que se hizo en ambas twigs) sería: mientras se encuentra en la fusión, presentado el conflicto, finalice la compilation de composer.lock desde el desarrollo (solo este file) y ejecute su command de compositor que agregó el nuevo package como lo hizo en la twig, agregue y confirme. El resultado es como si hubiera ejecutado la actualización y el package agregándola en secuencia.

¿Qué se supone que debo hacer aquí para terminar la rebase / fusión?

Si no hay otros cambios presentes en su workdir o cabeza separada, y develop también está en el estado en la descripción, comenzaría de nuevo con la combinación:

  • git rebase --abort si la rebase aún está en curso
  • git merge --abort if merge aún está en curso
  • pago y envío
  • fusionar twig de function de nuevo
  • resolver el conflicto de una de las maneras descritas
  • cometer la fusión (incluidos los conflictos que resuelven los cambios), empujar, etc.