Mejor flujo de trabajo con Git & Github

Question

Estoy buscando algunos consejos sobre cómo estructurar correctamente el flujo de trabajo para mi equipo con Git & GitHub.

Somos convertidores de svn recientes y es un poco confuso cómo debemos configurar nuestro flujo de trabajo diario.

Aquí hay un pequeño trasfondo: me siento cómodo con la línea de comandos y mi equipo es bastante nuevo pero puede seguir los comandos de uso. Todos estamos trabajando en el mismo proyecto con 3 entornos (desarrollo, puesta en escena y producción). Somos una mezcla de desarrolladores & diseñadores por lo que algunos utilizan la GUI de GIT y algunos la CLI.

Nuestra configuración en SVN fue algo como esto:

• Tuvimos una rama para el desarrollo, puesta en escena y la producción.
• Cuando las personas confiaban en el código, lo hacían y luego lo fusionaban en la puesta en escena.
• El servidor se actualizaría y en un día de publicación (semanal) haríamos un diff y empujaríamos los cambios al servidor de producción.

Ahora configuré esas sucursales y obtuve el proceso con el servidor en ejecución, pero es el flujo de trabajo lo que me está confundiendo.

Parece excesivo que cada vez que alguien haga un cambio en un archivo, creen una nueva rama, confirmen, fusionen y eliminen esa rama. Por lo que he leído, podrían hacerlo en una confirmación específica (usando el hash), ¿tengo ese derecho? ¿Es esta una manera aceptable de hacer las cosas con Git?

Cualquier consejo sería muy apreciado.

Answer 1

Puede copiar su flujo de trabajo de svn verbatim. Git puede hacer todo lo que svn puede (¡pero puede hacer más que eso!). Pero su flujo de trabajo podría mejorarse a pesar del CVS utilizado.

Si desea mantener un número mínimo de sucursales (que en caso de que sea nuevo en git simplificaría las cosas) en el flujo de trabajo que ha descrito, sugiero tener (en lugar de una rama de desarrollo) tres por ramas -Developer: desa-john, desa-mary, etc:

devel-john >--\ 
       \ 
devel-mary >------> staging ---> production 
      /
devel-peter >-/ 

Esto es conveniente: todos los cambios de desarrollo serían empujados al repositorio central (que a menudo es una buena cosa, incluso para GIT) sin conflictos y se fusionaron en cualquier momento por cualquiera que esté dispuesto/obligado a hacer la fusión (por ejemplo, en la rama de etapas).

Answer 2

Dependiendo de su flujo de trabajo, puede tener algunas ramas 'importantes' en su repositorio central (es decir, en github) que las personas pueden clonar localmente. Estos corresponderían a 'estable', 'beta', 'desarrollo', etc. Un buen artículo sobre un posible conjunto de sucursales es this.

Una vez hecho esto, puede dejar que las personas usen su propia estrategia. Prefiero mantener las ramas temáticas para proyectos importantes y tener una llamada 'soluciones rápidas' para cosas rápidas que necesito hacer. Si tiene un equipo trabajando en un proyecto principal que desean mantener en una sucursal separada separada del repositorio principal, puede dejar que lo hagan sin ninguna intervención. Si las personas prefieren tener muchas ramas pequeñas para probar cosas, etc., también pueden hacerlo.

Como para probar e integrar automáticamente en la producción desde la etapa, puede configurar los ganchos de git para hacer eso o tener un sistema en funcionamiento que lo hará por usted a intervalos regulares e informar problemas.

Answer 3

Las ideas a tener en cuenta cuando se trabaja con un DVCS son:

• distribución: incluso si usted tiene un centro de GitHub, el revelador no se limitan a publicar (push) sólo para que GitHub repo. Pueden fork the repo y publicar en su propia versión (mientras se extraen del repositorio central oficial de GitHub - llamado "upstream").
  La ventaja es que pueden reescribir el historial (reset, rebase --onto, rebase -i, ...) tantas veces como lo deseen, al final, realizarán una solicitud de extracción, permitiendo que un integrador administre sus cambios.

• uno de publication: en su propio repo local, puede configurar tantas ramas como usted desee (no uno por cada modificación del archivo, por supuesto, pero para cualquier nueva tarea o conjunto de tareas que debe desarrollar).
  Pero también puede establecer ramas públicas que serán empujadas ("publicadas") a su repositorio remoto.
  Ver esta pregunta en Git workflow, y también artículos de JC Hamano en las ramas remotas:
  o Fun with remote branches (1)
  o Fun with remote branches (2)
  La frase "Cuando las personas estaban seguros con el código de cometerían y lo combinan con la puesta en escena" no debe aplicarse con un DVCS: comprométase temprano, comprométase a menudo, pero presione ("publicar") solo cuando lo desee.

Answer 4

También hay algunos flujos de trabajo de proyectos descritos en el ProGit book que muestran los comandos de Git desarrolladores usarán para seguir al día.

No es un modelo bien considerado Git ramificación descrito en http://nvie.com/git-model

Answer 5

Great post on GitHub Workflow por uno de GitHub creadores de Scott Chacon y autor del mencionado Pro Git book: P