En resumen: La mejor práctica es diversificar, fusionar con frecuencia y mantener siempre sincronizado .

Existen convenciones bastante claras sobre cómo mantener su código en una rama separada de la rama maestra:

1. Está a punto de realizar una implementación de un cambio importante o disruptivo
2. Está a punto de para realizar algunos cambios que pueden no ser utilizados
3. Quiere experimentar con algo que no está seguro de que funcione
4. Cuando se le dice que se ramifique, es posible que otros tengan algo que hacer en el maestro

La regla general es que después de la ramificación, debe mantenerse sincronizado con el maestro. rama. Porque eventualmente necesitarás fusionarlo de nuevo con master. Para evitar un enorme y complicado lío de conflictos al volver a fusionar, debe comprometerse con frecuencia, fusionar a menudo.

Buenas prácticas a seguir

Un modelo exitoso de ramificación de Git de Vincent Driessen tiene buenas sugerencias. Si este modelo de ramificación le atrae, considere la extensión de flujo para git . Otros han comentado sobre el flujo .

Prácticas de etiquetado

Como ya sabe, Git le brinda identificadores de confirmación como 1.0 -2-g1ab3183 ¡pero esas no son etiquetas! El etiquetado se realiza con git tag, y las etiquetas que se crean usando git tag son la base para los identificadores de confirmación que crea git describe. En otras palabras, en Git no etiqueta ramas. Está etiquetando confirmaciones. Es correcto decir que la etiqueta es solo un puntero anotado a una confirmación.

Veamos un ejemplo práctico que lo demostró,

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

Permita que «s commit» S «sea apuntado por la etiqueta» v1.0 «. Esta confirmación está tanto en la rama «maestra» como en la rama «prueba». Si ejecuta " git describe " sobre la confirmación » Una «(parte superior de la rama» maestra «) obtendría algo como v1.0-2-g9c116e9. Si ejecuta " git describe " encima de la confirmación «B» (también conocida como la rama de «prueba») obtendrá algo como v1.0-2-g3f55e41, ese es el caso de la configuración predeterminada de git-describe. Tenga en cuenta que este resultado es ligeramente diferente. v1.0-2-g9c116e9 significa que estamos en la confirmación con el ID SHA-1 ordenado de 9c116e9, 2 confirmaciones después de la etiqueta v1.0. ¡No hay etiqueta v1.0-2!

Si desea que su etiqueta aparezca solo en la rama «master», puede crear una nueva confirmación (por ejemplo, solo actualizar default / fallback información de versión en GIT-VERSION-FILE) después del punto de bifurcación de la bifurcación «prueba». Si etiqueta confirmaciones en la rama «prueba» con p. Ej. «v1.0.3` solo sería visible desde» prueba «.

Referencias

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

Comentarios

• 1.0-2-g1ab3183 es un identificador construido por git describe a partir de la información disponible de git, pero llamarlo identificador de git es demasiado. Git identifica mediante hash SHA; las etiquetas y las ramas son construcciones humanas que git realiza de manera útil. Como tal, crea una etiqueta cuando crees que algún ser humano algún día deseará encontrar un marcador conveniente para una confirmación.
• una maravillosa ilustración de la multidimensionalidad en el universo git. hermosa. gracias
• Vale la pena observando que muchos proyectos no necesitan algunos de los carriles que se muestran en este diagrama. Algunos proyectos solo necesitan lo que ' se llama desarrollo y funcionalidad aquí. Esto suele ser cierto para las aplicaciones web que se pueden implementar a voluntad.
• Incluso el autor de git flow ya no lo recomienda para muchos tipos de proyectos, como el desarrollo web. Mucha gente cree que es mucho más complejo de lo que necesitan la gran mayoría de proyectos, lo que hace que su ejecución sea problemática y fácil de equivocarse.En el otro extremo del espectro, algunos equipos de defensores de profesionales avanzados usan ' desarrollo basado en troncales ', que casi nunca usa sucursales, y entregar proyectos exitosos como ese. Para algo intermedio, considere " anti-gitflow '

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

Debe agregar una etiqueta para marcar una versión publicada. Si luego necesita corregir errores en esa versión, debería crear una rama en la etiqueta.

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

Comentarios

• oh … y supongo que quiere decir que la rama se fusiona en otra rama, como master. HEAD se mueve cada vez que hago un pago, ¿verdad?
• HEAD generalmente apunta a una rama (a menos que ' esté en modo HEAD separado), entonces HEAD se mueve con la rama a la que apunta