Yo recomiendo usar tags (tag tutorial)
Desde su rama principal ya haya terminado v1.0 añadir una etiqueta llamada v1.0.
git tag -a -m "Tagging release 1.0" v1.0
De esta manera usted siempre puede volver a una versión específica en cualquier momento llamando git checkout [tag_name]
Otra práctica común es el uso de ramas para trabajar en funciones hasta que sean estables.
git checkout -b [feature-branch]
que crea una nueva rama llamada lo que está en [feature-branch] y comprueba hacia fuera. Asegúrese de hacer esto desde donde desea comenzar a trabajar en la función (generalmente desde master).
Una vez estables, pueden fusionarse de forma segura en master. De master de ejecución:
git merge [feature-branch]
De esta manera su rama master siempre se mantiene en un estado de trabajo y sólo las finalizadas se añaden una vez listo. Esto le permitirá mantener una copia de trabajo de la aplicación en todo momento (idealmente de todos modos) para realizar pruebas, etc.
Puede utilizar las ramas para cada versión de la aplicación; sin embargo, usar etiquetas hace que no se pueda fusionar en otra versión de rama por accidente.
De acuerdo. Verifique sus archivos 1.0 build y dsym y agregue una etiqueta. Si en el futuro está trabajando en la versión 2.0 y descubre que necesita liberar algún cambio como 1.1, siempre puede crear un banch a partir de esa etiqueta.No es necesario crear una rama por publicación, pero es posible que desee fusionar su rama de desarrollo principal en una sola rama de publicación cada vez que realice una compilación ad hoc para que tenga un historial claro de código lanzado para pruebas frente a trabajos inestables en progreso. – Jonah
Bien, así que una vez que agregue la etiqueta 1.0, ¿cómo empiezo a trabajar en 1.1? ¿Establezco otra etiqueta? Confundido sobre este concepto –
Para continuar con el comentario de Jonah, solo quieres una rama para una versión si la mantienes por separado. Por ejemplo, si el maestro está trabajando hacia la versión 3.0 pero encuentra algunos errores en la versión 2.0, podría crear una rama de mantenimiento comenzando desde la etiqueta 2.0, eventualmente etiquetar la versión 2.1 y probablemente fusionar esa rama en su rama principal para obtener el correcciones de errores en la próxima versión 3 también. – Cascabel