¿Buenas 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 saber cómo otros utilizan este flujo de trabajo en sus proyectos.

Cómo lo usamos: Nos bifurcamos antes de cada cambio, nos fusionamos con el maestro, nos comprometemos localmente y presionamos a nuestro repositorio de github. Luego, ssh en nuestro entorno de prueba y extraemos la rama maestra del repositorio github. Todavía no hemos comprendido el rebase , fetch o etiquetado .

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

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

¿Puede controlar los candidatos o entornos de lanzamiento (pruebas, desarrollo, producción) dentro de un repositorio de git? o necesitas multiples?

Si la solución es tirar, ¿puedes tirar una etiqueta específica?

Answer 1

Básicamente, puede funcionar muy bien con una " central " Repositorio GitHub.

• Las etiquetas son punteros inmutables, se pueden usar (y empujar) en cualquier momento, para ser revisadas en cualquier entorno de prueba o producción. Eso permite que se lleve a cabo una validación, pero generalmente no sirve para el desarrollo.
• Tirar de una rama significa que puedes hacer algunas evoluciones dentro de esa rama (debido a algunas correcciones de errores y ajustes para hacer una vez que el código está en un entorno de producción) y empujarlo hacia atrás para que el repositorio del otro desarrollador pueda retirarse y tomar en cuenta.

Entonces, depende de lo que esté haciendo en esos servidores: solo validación (con un estado aceptado o rechazado), o también desarrollos adicionales.
En todos los casos, una etiqueta con una convención de nomenclatura adecuada es agradable para realizar un seguimiento de confirmaciones específicas en el historial, pero las sucursales son necesarias cada vez que es necesario aislar un esfuerzo de desarrollo.

Answer 2

Lea el libro Pro Git . Puedes leer las páginas de manual de git durante un año y aún no lo entiendes: tratar de aprender git mediante la lectura de páginas de manual es como intentar aprender un nuevo idioma mediante la lectura de un diccionario, se puede hacer. El libro le enseñará algunos flujos de trabajo que puede tener con git, y qué comandos de git usar y en qué contexto usarlos.

Answer 3

En GitHub, utilizo una cuenta para mi empresa, que es donde " blessed " el código vive; Luego mantengo una bifurcación personal, donde trabajo en cosas que todavía no son bastante estables. En mi máquina local, manejo ambos en un repositorio, de modo que el maestro es el código bendito (y se envía a la cuenta de la empresa), mientras que todas las demás sucursales son para mi horquilla. Aquí hay 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 permisos de confirmación para el repositorio de la empresa, solo puedo combinar (o seleccionar) las confirmaciones de una rama a otra y enviarlas a la ubicación adecuada. Ahora, los repositorios separados ciertamente no son necesarios, pero dado que este es un proyecto de código abierto, me gusta mantener el " oficial " Repo libre de ramas aleatorias creadas por mis tangentes. Una vez que llegue al punto en el que obtendrá la versión, 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 archivos comprimidos de los archivos. en cada etiqueta, muy adecuado para desplegar una versión específica a una máquina que no necesita el historial completo.

Deberías leer el blog de github; han tenido algunas publicaciones agradables que describen su flujo de trabajo de implementación, que por supuesto involucra mucho a git.