¿Cómo usar github, ramas y lanzamientos automáticos para la gestión de versiones? [cerrado]

Ahora entiendo la mayoría de los conceptos básicos de Git / Github, sin embargo, todavía tengo problemas para comprender el panorama general.

Estas son algunas cosas que he logrado hacer funcionar hasta ahora:

• Push commits
• Trabajar con ramas
• Integre Github con Travis CI, un sistema de integración continua
• A través de Travis CI, construya automáticamente en cada commit para master y coloque el lanzamiento como un ZIP en Github bajo lanzamientos.

Sin embargo, hasta ahora solo he trabajado en versiones alfa / beta de proyectos, por lo que nunca he visto versiones versionadas en la práctica todavía.

Por lo tanto, quiero aprender más sobre el control de versiones, mantener versiones separadas, revisar las versiones, etc.

¿Cómo me aseguraría de que sucedan las siguientes cosas:

• Tener diferentes versiones de mi proyecto, por ejemplo, la versión 1.1.0 y 2.0.0
• Tener la capacidad de impulsar las revisiones en las versiones, colocar la versión a 1.1.1 o 2.0.1, etc.
• Haga que un sistema de integración continua compile esa versión automáticamente en commit y, si tiene éxito, publique una versión para esa versión específica.

Dudo entre las siguientes opciones:

• ¿Necesito usar etiquetas para cada versión? Si es así, ¿cómo puede un sistema de integración continua crear versiones automáticamente?
• ¿Debo crear ramas para cada versión? Si es así, ¿eso no crearía una tonelada completa de ramas (como una rama 1.1 y 2.0, las revisiones van a esa rama, por supuesto)
• ¿Cómo especificaría el número de versión? ¿Está bien tener un archivo de configuración que especifique el número de versión, o hay formas más inteligentes de evitarlo? En este caso, sería un proyecto Java, si eso importa.

Deberías mirar git-flow . Es un modelo de ramificación excelente (y popular).

Resumen de flujo de Git

Derivación

Los troncos principales que se quedan para siempre son developy master. mastercontiene su última versión y developsu última copia de desarrollo "estable".

Los contribuyentes crean featuresucursales (con el prefijo feature/convencional) a partir de develop :

$ git checkout -b feature/my-feature develop

y hotfixramas (prefijadas hotfix/por convención) fuera de master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

Estas ramas son "desechables", lo que significa que tienen una vida útil corta antes de volver a fusionarse con los troncos principales. Están destinados a encapsular pequeñas piezas de funcionalidad.

Ramas de acabado

Cuando un contribuyente termina con una featurerama, la fusionan nuevamente en develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Cuando terminan con una hotfixrama, la fusionan de nuevo en ambas mastery developla revisión continúa:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Este es el aspecto de integración continua.

Lanzamientos

Cuando esté listo para comenzar a empaquetar una versión, cree una releaserama desde su rama "estable" develop(igual que crear featureramas). Luego coloca el número de versión en una etiqueta (que se describe a continuación).

El uso de releaseramas separadas le permite continuar desarrollando nuevas características developmientras corrige errores y agrega toques finales a la releaserama.

Cuando esté listo para finalizar el lanzamiento, fusiona la releaserama en ambos mastery develop(al igual que a hotfix) para que todos sus cambios se lleven adelante.

Etiquetado

Cuando crea una releaserama o una hotfixrama, coloca el número de versión de manera apropiada en una etiqueta. Con vainilla git, se ve así:

$ git tag -a <tag-name> -m <tag-description>

Entonces también deberá insertar las etiquetas (por separado) en su repositorio remoto:

$ git push --tags

Por lo general, es mejor usar versiones semánticas en las que sus versiones toman la forma major.minor.hotfix. Los golpes mayores son incompatibles con versiones anteriores, mientras que los golpes menores y de revisión no son incompatibles con versiones anteriores (a menos que esté en beta 0.x.x).

Fusionando

Como viste anteriormente, git-flow te anima a fusionar ramas con el siguiente comando:

$ git merge --no-ff <branch-name>

La --no-ffopción le permite mantener todo el historial de su rama sin dejar un montón de ramas en la confirmación actual del repositorio (por lo que no se preocupe, no tendrá una rama para cada versión).

También te animamos a tirar con

$ git pull --rebase

Por lo tanto, no agrega muchos commits de fusión inútiles.

Puede configurar git para hacer ambas cosas de forma predeterminada en su .gitconfig. Aunque te dejaré mirar eso;)

Versiones de navegación

Cuando alguien busca una versión específica de su base de código, puede verificar la etiqueta por su nombre:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

O, si alguien está navegando en github, también hay una pestaña "etiquetas" en el menú desplegable "ramas".

Usando la extensión git-flow (recomendado)

Mi forma favorita de usar este modelo es con la extensión de flujo git para git.

( Editar: Louis ha recomendado la bifurcación AVH que funciona mejor git describey podría estar más activa ahora. Gracias Louis).

La extensión automatiza todas las partes desordenadas (como usar merge --no-ffy eliminar ramas después de la fusión) para que pueda continuar con su vida.

Por ejemplo, con la extensión, puede crear una rama de características como esta:

$ git flow feature start my-feature-name

y terminar así

$ git flow feature finish my-feature-name

Los comandos para las revisiones y versiones son similares, aunque usan el número de versión en lugar del nombre de una rama, de esta manera:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

Git flow luego crea la etiqueta de versión para usted y le recuerda amablemente que suba la versión en cualquier configuración o archivos de manifiesto (lo que podría hacer con un administrador de tareas como grunt).

Espero que ayude :) No estoy seguro exactamente cómo lo integraría todo con su configuración de Travis CI, pero supongo que los githooks lo llevarán allí.

¿Necesito usar una etiqueta para cada versión?

No, no necesitas usar etiquetas en absoluto. Si desea etiquetar cada versión, está bien, o si desea etiquetar cada vez que se construye su sistema CI, también puede hacerlo. Esencialmente, las etiquetas solo le dan un nombre fácil de usar a la confirmación, para que pueda extraerla fácilmente y verla más tarde.

¿Debo crear ramas para cada versión?

¡Seguro! La ramificación es barata / gratuita en Git, por lo que aprovecho cada oportunidad que tengo. También puede fusionar y eliminar ramas con bastante rapidez. Si siente que tiene muchas ramas, siempre puede reducirlas más tarde con una fusión selectiva. Hay una gran cantidad de esquemas de ramificación de Git disponibles también si desea utilizar un esquema probado y verdadero.

¿Cómo especificaría el número de versión?

Las etiquetas son generalmente la forma en que especifica el número de versión, ya que pertenece a git. Si está hablando sobre cómo versionar un proyecto, o la mejor manera de hacerlo, tendrá que investigar un poco, ya que es una pregunta basada en una opinión justa. Algunos proyectos permanecen en Beta para siempre, otros incrementan las versiones de números enteros como si estuvieran pasando de moda (Mirándote Chrome)

¿Necesito usar etiquetas para cada versión?

Si por "versión" te refieres a un conjunto de archivos que componen una versión o un candidato de versión, entonces recomiendo etiquetar cada versión. Si necesita consultar la versión 1.2.7 en el futuro, ¿desea buscar el hash de commit o simplemente usar el número de versión?

Además, si usa git describepara registrar información de compilación en algún lugar (como lo hago yo), el uso de etiquetas le permite proporcionar una salida mucho mejor.

Si es así, ¿cómo puede un sistema de integración continua crear versiones automáticamente?

Un sistema de integración continua podría generar versiones independientemente de cómo utilice las etiquetas. Podría decirle que cree una versión sobre la base del hash de commit. Las etiquetas te hacen la vida más fácil.

¿Debo crear ramas para cada versión? Si es así, ¿eso no crearía una tonelada completa de ramas (como una rama 1.1 y 2.0, las revisiones van a esa rama, por supuesto)

No veo la ramificación como una cosa "por versión". Tengo un par de proyectos donde mis versiones son confirmaciones en la masterrama. No necesito nada más complicado que esto por ahora porque ninguno de los proyectos está en la etapa estable y no hay necesidad de soportar versiones anteriores a largo plazo. Pero digamos que lanzo 1.0, 1.1, 1.2, luego lanzo 2.0 y todavía tengo que admitir la serie 1.0 con correcciones de seguridad, etc. Entonces ciertamente tendría una rama para poner los lanzamientos de mantenimiento para la serie 1.x .

¿Cómo especificaría el número de versión? ¿Está bien tener un archivo de configuración que especifique el número de versión, o hay formas más inteligentes de evitarlo? En este caso, sería un proyecto Java, si eso importa.

Tener una única fuente para su número de versión, como un archivo de configuración, es la mejor manera, ya que evita errores de dedo gordo que de otro modo podrían ocurrir si tiene que actualizar los números en varios lugares. Estoy hablando de ... hmm ... experiencia embarazosa. Lanzas 1.3 solo para descubrir que el software aún informa que es la versión 1.2. ¡Uy!

En otra respuesta, mxdubois te recomendó gitflow. Si decide usar gitflow, le recomiendo usar la edición AVH . La versión original ya no se mantiene activamente. Una diferencia notable es que la edición AVH realiza fusiones de lanzamiento que permiten git describetrabajar de manera inteligente. La versión original realiza la fusión de una manera que se disparagit describe .

Escaneando tu lista, veo la versión como tu foco, así que ...

Una forma de mantener versiones es con ramas y fusión (o rebase).

Así que tienes:

master

entonces creas una rama

v1

luego agrega más cambios a

master(diff1)

entonces creas una rama

v3

luego agrega más cambios a

master(diff2)

Ahora:

Para actualizar la Versión 2, ahora haz

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Para actualizar la versión 3

git checkout v3
git merge master

Lo anterior es para actualizaciones al por mayor.

Sin embargo, es probable que sea más probable que desee seleccionar cambios específicos para los que hay

git cherry-pick

Más información sobre la selección de cerezas en http://git-scm.com/docs/git-cherry-pick