¿Git para la configuration del server del juego?

Me preguntaba si git es adecuado para esto. Así que aquí está el escenario:

Estamos pensando en alojar un server de juegos. Sin embargo, no es el caso simplemente de download files y ejecutar el server. Necesita ser cuidadosamente configurado y mantenido. También tiene capacidades de scripting. Además, habrá bastantes "desarrolladores" que contribuirán a este proyecto y desearían tener todos los files del server sincronizados en su máquina local para la testing. Así que supongo que git sería una gran herramienta aquí.

El problema es que ninguno de nosotros ha usado git anteriormente y tiene poca o ninguna experiencia con otros repositorys. Así que me es bastante difícil imaginar cómo debería funcionar todo.

Entonces, ¿debe haber una copy (o una twig) de los files que se llaman estables y estos files son utilizados por el server del juego? Otra twig sería para desarrollar. Supongo que cualquier function de un desarrollador de scripts o configuraciones debe ir a esta twig de testing.

Ahora, lo que parece ser un problema aquí es que estas dos twigs deberían estar disponibles en el disco duro, ambas al mismo time. Y me confundo un poco aquí. ¿Debería haber dos repositorys separados? ¿Uno para ejecutar un server estable y otro para probar? Y luego, cada vez que el repository de testings parece lo suficientemente estable, ¿debería llevar estos cambios al repository estable?

Cualquier ayuda o pensamiento son apreciados.

Sugeriría no usar GIT. Git es un sistema de control de fuente descentralizado que necesita algo de experiencia.

¿Puedo sugerir una solución más simple, como usar subversión en su lugar? con Subversion, tienes 1 repository central, y todos tus desarrolladores copyrán el código desde allí y volverán a fusionarse cuando terminen de editar los files.

No te molestes en crear twigs para comstackciones específicas por el momento. Solo use un repository fuente centralizado hasta que usted y su equipo se sientan cómodos con el control de la fuente. Solo entonces, revise su process de desarrollo y decida cómo proceder.

La split prematura del repository de origen en twigs suele dificultar la reconciliación posterior.

No hay ninguna razón por la cual no puedas usarlo para mantener los files de configuration, etc.

Sin embargo, ten cuidado si también estás almacenando files binarys grandes en el repository de git. Git rastrea el historial de TODOS los files que alguna vez han estado en el repository (incluso si han sido eliminados). Por lo tanto, no es particularmente eficiente en el uso del espacio con datos binarys; sin embargo, el text es mejor (como los files de configuration)

Estoy de acuerdo con que la subversión es mucho más fácil de entender si es la primera vez que trabaja con un sistema de control de origen. Hay muchos sitios que alojarán su proyecto de forma gratuita, sourceforge y codeplex son ejemplos, o si desea alojar el server usted mismo, puedo recomendar el server de VisualSVN, lo usamos en el trabajo, es fácil de configurar y mantener y es gratis ya que VisualSVN solo cobra por las licencias de Visual Studio. También estoy de acuerdo con la bifurcación, trate de no complicar demasiado las cosas cuando empiece, solo necesitará un repository para comenzar, dentro de eso debe crear su proyecto con todas las carpetas y files debajo de él. Debe acordar con todos los miembros del equipo bajo qué circunstancias se comprometerán los cambios con el proyecto. Esto dependerá del estado en que necesite mantener el proyecto. Por ejemplo, si necesita poder ir al repository en cualquier momento para recuperar los files y configurar el server del juego, entonces las reglas deben reflejar esto. Si aún no lo has hecho, debes tener en tus manos una buena herramienta para operaciones de diff / merge. Usamos Winmerge, que es gratuito y lleva a cabo la mayoría de las tareas básicas, existen herramientas comerciales que admiten una funcionalidad más avanzada como Beyond Compare y Araxis merge, he utilizado ambas y son buenas. También sugiero que revises TortoiseSVN, es un cliente que te ayuda a realizar cambios y recuperar actualizaciones del server SVN.

Con respecto a Branching si en algún momento decide agregar un gran set de cambios durante un largo período de time, debería considerar la posibilidad de ramificar el proyecto. No tome esta decisión a la ligera, ya que puede ser un gran trabajo fusionar la twig de nuevo en el maletero. Una vez que se ha familiarizado con SVN y se siente cómodo con los conceptos, es fácil migrar a GIT si siente que las características adicionales que ofrece beneficiarían al equipo.

Mi recomendación es ir con git siempre. Tiene varias ventajas para la subversión, y puede recogerlo en una semana.

Los tutoriales de github.com son un excelente lugar para comenzar.