Tengo dos ramas:

  • maestra
  • desplegar

Cuando algo se inserta en implementar , el sistema de compilación implementa automáticamente los cambios. por lo que, por lo general, el trabajo se realiza en varias ramas, se fusiona en master y luego, cuando llega el momento de implementar , master se fusiona en deploy y las cosas funcionan.

Dado que deploy realmente no tiene nada más que fusiones regulares de master , estaba pensando en intentar usar rebase en lugar de fusionar.

Mi entendimiento es este:

git checkout master
git rebase deploy

Y .. no pasa nada

Esta es la salida:

$ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
$ git rebase deploy
Current branch master is up to date.

Obviamente, la función funciona y no entiendo algo :) ¿Qué me estoy perdiendo?

Tal vez esta no sea la forma correcta de lograr mi objetivo; En resumen, estoy tratando de que sea así: el jefe de deploy ahora apunta al jefe de maestro .

git
1
Thomas 8 oct. 2019 a las 22:23

1 respuesta

La mejor respuesta

Suponiendo que deploy nunca se compromete directamente y solo recibe fusiones de master ...

Justo después de haber fusionado una nueva función (E - F - G - H) y antes de implementarla, su repositorio se ve así.

  B - C   E - F - G - H
 /     \ /             \
A ----- D ------------- I [master]
        [deploy] 

Puedes usar git log --graph --decorate para ver esta estructura en tu propio repositorio, pero invertida verticalmente.

Observe cómo deploy en D está directamente detrás de master en I. Cuando fusiona el maestro en la implementación no hay necesidad de una fusión, por lo que Git hace un "avance rápido" y simplemente mueve el deploy etiqueta a la misma confirmación que master.

git checkout deploy
git merge master

  B - C   E - F - G - H
 /     \ /             \
A ----- D ------------- I [master] [deploy]

master y deploy ahora apuntan a la misma confirmación.

Cuando intentas rebasar master encima de deploy, el rebase funciona, pero no hay nada que hacer.


Como nota al margen, hay poca necesidad de una rama deploy en este flujo de trabajo ya que deploy es siempre un antepasado directo de master. Dado que solo está moviendo una etiqueta alrededor de las fusiones existentes, sería más sencillo usar una etiqueta para marcar la confirmación para implementar.

# Move the deploy tag to master.
git tag -f deploy master

Esto también hace que deshacer las implementaciones sea mucho más fácil. Digamos que la última característica está rota. Mientras lo arregla, puede volver a mover la etiqueta a una confirmación previa conocida.

# Roll back deployment to commit ABC123
git tag -f deploy ABC123

Puede utilizar etiquetas numeradas, con marca de tiempo o versionadas para realizar un seguimiento de las versiones y publicar las más altas.

git tag v1.2.3 master

# Get the newest version
git tag --sort=-v:refname | head -1
2
Schwern 8 oct. 2019 a las 19:49