Git Workflow lleva a twigs no sincronizadas en Bitbucket

Aunque soy bastante nuevo en Git, lo elijo y, básicamente, todo funciona de la manera que quiero que funcione. Acabo de encontrarme con un problema relacionado con Git, Bitbucket y el a menudo citado "Modelo de ramificación de Git exitoso".

Tengo una copy local de mi proyecto web y desarrollo localmente con Mamp Pro. Como dije, me oriento en el " Un model exitoso de ramificación de Git ", porque parece estar bien pensado y se menciona a menudo en muchos artículos de Git en la web.

Cuando termino con una revisión o una nueva característica, presiono Bitbucket y, a su vez, se está ejecutando un POST Hook que creo y administro con FTPloy ( http://ftploy.com/ ).

Ahora, cuando quiero hacer una revisión porque algo no funciona en el website, sigo así, suponiendo que el Máster y el Encuentro estén sincronizados y actualizados:

$ git checkout -b hotfix-5.0.20 master 

Luego soluciono el problema y lo comprometo. El modo de ramificación Successfull ahora dice que la solución primero debe fusionarse nuevamente en el maestro. Cambié el flujo de trabajo aquí, porque preferiría primero fusionar de nuevo en Desarrollo y luego presionarlo porque esto a su vez actualiza dev.domain.com, que es mi entorno de ensayo que se ejecuta en el server de la vida real. Quiero hacerlo así para poder verificar si todo está realmente arreglado (y no romper nada más).

Entonces hago esto:

 $ git checkout dev Switched to branch 'dev' $ git merge --no-ff hotfix-5.0.20 Merge made by recursive. (Summary of changes) $ git push origin dev 

Luego verifico todo en Dev y si todo está bien lo haré:

 $ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-5.0.20 Merge made by recursive. (Summary of changes) $ git push origin master 

A continuación, eliminaré la twig de la revisión.

Ahora, aquí viene lo que me está tirando:

Cuando voy a Bitbucket después de hacer los pasos anteriores y hago clic en "Sucursales", Bitbucket me dice que la Rama de Desarrollo es un Compromiso detrás y un Compromiso por delante. Cuando hago clic en Dev Branch y lo sincronizo con Master, Bitbucket crea un nuevo Commit y combina Dev con Master. Cuando ingrese a la última confirmación, no se mostrarán los cambios de código, por lo que básicamente es una confirmación vacía.

Luego tengo que acceder a mi directory local de Git y desde allí todo está sincronizado y actualizado nuevamente.

Ahora, como dije, soy bastante nuevo para Git, pero tengo la sensación de que algo anda mal. No quiero hacer esta synchronization manual y tirar después de cometer cada vez y si me olvido de hacerlo terminaré con twigs sin synchronization (al less en Bitbucket).

¿Es probable que la solución sea tan fácil como ramificarse en Dev al principio, en lugar de Master?

¡Esperamos sus opiniones y muchas gracias de antemano!

Saludos, Marc

Editar / actualizar

Bien, acabo de tratar de seguirlo con precisión, pero salió con el mismo resultado. Estoy bastante seguro de que debo ser yo quien hace algo mal. Por favor, tengan paciencia conmigo en esto. Ahora hice esto:

 $ git checkout -b hotfix-5.0.21 master 

Hice mis cambios, los cometí.

 $ git checkout master $ git merge --no-ff hotfix-5.0.21 

Entonces

 $ git checkout development $ git merge --no-ff hotfix-5.0.21 

Entonces

 $ git branch -d hotfix-5.0.21 

Y finalmente

 $ git push 

Bitbucket ahora muestra el que está detrás, uno más adelante … 🙁

Si observa su repository, verá que el command de fusión creó dos confirmaciones.

Una confirmación fue cuando fusionó la revisión en dev. Otro fue cuando fusionó el hotfix en master. Como tienes dos compromisos diferentes , BitBucket no está sincronizado.

Debería crear una bifurcación de hotfix fuera de master (lo hizo), probarla de forma independiente y luego volver a fusionarla en master. Cuando testings fusionando de nuevo en dev, estás probando en lo que podría ser una base de código diferente. Una vez que esté seguro de que el hotfix funciona para su código de producción, impleméntelo y busque aplicar el arreglo al desarrollo.

La única exception a esto que nvie especifica es si existe una twig de versión.

Es posible que también desee consultar usando git-flow para administrar este process por usted.