2010-06-29 33 views
5

Así que he estado usando git por primera vez, y hay un escenario que no sé cómo resolver.Administrar una rama de versión en Git

Tengo una aplicación web simple (solo html, css y js), y quiero producir versiones regulares que se puedan rastrear con un número de versión. Esto es fácil de hacer con git tag. Pero el problema es que para mis lanzamientos quiero hacer algunas cosas adicionales, como minificar las secuencias de comandos js y actualizar las páginas html para señalarlas. Además, necesito un .gitattribute en la versión que ignore los scripts js no minificados, de modo que git archive produzca la salida más pequeña posible.

Lo que he hecho es crear una sucursal releases. Esta rama incluye la mencionada .gitattributes, y las páginas html modificadas. Cada vez que quiero una nueva versión, cambio a esta rama, fusiono los cambios de la versión maestra, luego termino la versión y la etiqueto con un número de versión. Parece funcionar como yo quiero, pero no estoy seguro de cómo se supone que debe hacerse.

Mi pregunta para los usuarios de git más experimentados es ¿cómo se maneja este caso normalmente?

+0

No veo si hay una alternativa. Deberá minnificar los nuevos archivos js y css en la rama de publicación. –

Respuesta

3

La solución rama es una buena, pero para la gestión de la liberación, que también podría almacenar simplemente una "liberación" en un repositorio externo (como un Maven uno, por ejemplo, u otro repositorio git declarado como un submódulo)

La cosa con la administración de versiones es:

  • que no necesita una historia detallada para cada archivo (ya que esos archivos son acumulación de archivos de orígenes)
  • necesita esos archivos "liberación" a ser " empaquetado "como el mins js.

Por estas razones (compilación y embalaje), no necesariamente tiene que mantenerlos en el mismo repositorio que el utilizado para las fuentes (con su historial detallado y múltiples ramas).
Simplemente no produce la versión de lanzamientos al mismo ritmo que lo hace para las fuentes: el ciclo de vida de desarrollo es bastante diferente al de la versión.

+0

es cierto, aunque me gusta la conveniencia de tener acceso al código que produjo cada versión. –