¿Mejores prácticas de flujo de trabajo con git y github?

Question

He estado usando git y github con mi pequeño equipo de desarrolladores para nuestros proyectos. No puedo evitar pensar que no lo estamos haciendo bien. Me interesa escuchar cómo otros usan este flujo de trabajo dentro de sus proyectos.

cómo la usamos: Nos rama antes de cada cambio, se funden de nuevo en el maestro, se comprometen a nivel local y empuje a nuestro repositorio GitHub. Luego entramos en nuestro entorno de prueba y sacamos la rama principal del repositorio github. Todavía no hemos captado rebase, fetch o tagging por el momento.

Cómo me gustaría usarlo: me gustaría ser capaz de ssh en los diferentes servidores y tirar de una versión específica etiquetada como "fase 1" en el servidor. ¿Es esto posible, o necesitaría dos repositorios github diferentes?

se supone que git pull una rama específica en los servidores web o crear un nuevo alias para git push a?

¿Se puede controlar la liberación de candidatos o entornos (prueba, desarrollo, producción) dentro de un repositorio de git? o necesitas múltiples?

Si tirar es la solución, ¿puedes sacar un tag específico?

Answer 1

Básicamente, puede funcionar muy bien con un repositorio "central" de GitHub.

• Etiquetas siendo punteros inmutables, que se puede utilizar (y de difusión) en cualquier momento, con el fin de ser desprotegido a cualquier prueba o entorno de producción. Eso permite que se lleve a cabo cierta validación, pero por lo general no sirve para el desarrollo.
• Tirando de una rama significa que puede hacer algunas evoluciones dentro de esa rama (debido a algunas correcciones y ajustes que hacer una vez que el código está en un entorno de producción) y empujarla hacia atrás para el resto del repositorio del desarrollador para que retroceda y tome en cuenta.

así que depende de lo que está haciendo en esos servidores: única validación (con un estado aceptado o rechazado), o también los nuevos acontecimientos.
En todos los casos, una etiqueta con una convención de nomenclatura adecuada es útil para realizar un seguimiento de confirmaciones específicas en el historial, pero las ramas son necesarias cada vez que necesita aislar un esfuerzo de desarrollo.

Answer 2

En GitHub, utilizo una cuenta para mi empresa, que es donde vive el código "bendito"; Luego mantengo un fork personal, donde trabajo en cosas que aún no son del todo estables. En mi máquina local, manejo ambos en un repositorio, de modo que el maestro es el código bendito (y lo empuja a la cuenta de la empresa), mientras que todas las otras ramas son para mi tenedor. Aquí está parte de mi .git/config:

[remote "origin"] 
     fetch = +refs/heads/*:refs/remotes/origin/* 
     url = git@github.com:xiongchiamiov/fourU.git 
[branch "hacking"] 
     remote = origin 
     merge = refs/heads/hacking 
[branch "editor"] 
     remote = origin 
     merge = refs/heads/editor 
[branch "problem-utils"] 
     remote = origin 
     merge = refs/heads/problem-utils 
[branch "tests"] 
     remote = origin 
     merge = refs/heads/tests 

[remote "trunk"] 
     fetch = +refs/heads/*:refs/remotes/trunk/* 
     url = git@github.com:xyztextbooks/fourU.git 
[branch "master"] 
     remote = trunk 
     merge = refs/heads/master 

Ya que tengo cometer permisos para la cesión temporal de la empresa, que sólo puede fusionarse (o cereza-escoge) comete de una rama a otra, y empujarlo hasta la apropiada ubicación. Ahora, los repos separados no son necesarios, pero como este es un proyecto de código abierto, me gusta mantener el repositorio "oficial" libre de ramas creadas por mis tangentes. Una vez que alcanza el punto donde obtendrá el control de versiones, habrá una rama 0.x, con etiquetas para cada versión (0.1, 0.1.1, 0.2, etc.), lo cual es particularmente ventajoso porque github crea automáticamente los archivos de tar de los archivos. en cada etiqueta, muy adecuado para bajar una versión específica a una máquina que no necesita el historial completo.

Debería leer el blog github; Han tenido algunas buenas publicaciones que describen su flujo de trabajo de implementación, que por supuesto implica git.

Answer 3

Lea el Pro Git book. Puedes leer páginas de git man durante un año y todavía no lo entiendes: intentar aprender git leyendo páginas man es como tratar de aprender un nuevo idioma leyendo un diccionario, se puede hacer. El libro le enseñará un puñado de flujos de trabajo que puede tener con git, y qué comandos de git usar y en qué contexto usarlos.