En resumen: la mejor práctica es ramificarse, fusionarse a menudo y mantener siempre sincronizados .

Existen convenciones bastante claras acerca de mantener su código en ramas separadas de la rama maestra:

1. Está a punto de realizar una implementación de un cambio importante o disruptivo
2. Está a punto de realizar algunos cambios que podrían no ser utilizados
3. Desea experimentar en algo en lo que no está seguro de que funcione
4. Cuando se te dice que te extiendas, otros pueden tener algo que hacer en el maestro

La regla general es que después de la bifurcación, debes mantenerte sincronizado con la rama maestra. Porque eventualmente necesitas fusionarlo de nuevo para dominarlo. Con el fin de evitar una gran confusión de conflictos complicados al volver a fusionarse, debe comprometerse a menudo, fusionarse con frecuencia.

Buenas prácticas a seguir

Un modelo exitoso de bifurcación Git por Vincent Driessen tiene buenas sugerencias Si este modelo de bifurcación le atrae, considere la extensión de flujo a git . Otros han comentados sobre el flujo .

Prácticas de etiquetado

Como ya sabes, Git te da identificadores de compromiso como 1.0-2-g1ab3183, ¡pero esos no son etiquetas! El etiquetado se realiza con la etiqueta git, y las etiquetas que se crean utilizando la etiqueta git son la base de los identificadores de confirmación que crea git describe. En otras palabras, en Git no etiquetas ramas. Estás etiquetando confirmaciones. Es correcto decir que la etiqueta es solo un puntero anotado a un compromiso.

Veamos el ejemplo práctico que lo demostró,

                        /-- [v1.0]
                       v
---.---.---.---S---.---A     <-- master
                         \ 
                           \-.---B     <-- test

Vamos a confirmar que la 'S' esté marcada por la etiqueta 'v1.0'. Esta confirmación está tanto en la rama 'maestra' como en la rama 'prueba'. Si ejecuta " git describe " en la parte superior del commit 'A' (arriba de la rama 'master') obtendrías algo como v1.0-2-g9c116e9 . Si ejecuta "git describe" encima de la confirmación 'A' (también conocida como la rama 'prueba') obtendría algo como v1.0-2-g3f55e41 , ese es el caso con la configuración predeterminada de git-describe. Tenga en cuenta que este resultado es ligeramente diferente. v1.0-2-g9c116e9 significa que estamos comprometidos con el ID SHA-1 ordenado de 9c116e9 , 2 confirmaciones después de la etiqueta v1.0 . No hay una etiqueta v1.0-2 !

Si desea que su etiqueta aparezca solo en el 'maestro' de la rama, puede crear un nuevo compromiso (por ejemplo, solo actualizar la información de la versión predeterminada / alternativa en GIT-VERSION-FILE) después del punto de bifurcación de la rama 'prueba'. Si etiqueta confirmaciones en la rama de 'prueba' con, por ejemplo, 'v1.0.3' solo sería visible desde 'prueba'.

Referencias

He encontrado muchos, muchos blogs y publicaciones útiles para aprender. Sin embargo, los que están ilustrados profesionalmente son raros. Por lo tanto, me gustaría recomendar una publicación - Un modelo de bifurcación de Git exitoso por @nvie. He tomado prestada su ilustración :)

Se usa una rama si tiene 2 versiones diferentes de repositorio al mismo tiempo. Una etiqueta es una forma de marcar un punto en el tiempo en su repositorio.

Debes agregar una etiqueta para marcar una versión lanzada. Si luego necesitas hacer correcciones de errores en esa versión, crearías una rama en la etiqueta.

Solo desea eliminar las ramas que se han fusionado de nuevo en HEAD [o en alguna otra rama].