Git

Usaremos el modelo fork/pull de trabajo colaborativo con sistemas de control de versión distribuidos. Los tutoriales relevantes de GitHub son:

1. Cómo configurar git para usarlo con GitHub
2. Cómo hacerle fork a un repositorio de GitHub
3. Cómo enviar una petición de pull

El proyecto Diaspora (una especie de Facebook open-source y distribuido) utiliza esta misma metodología para trabajar. Tienen un documento donde especifican su manera de trabajar con git y GitHub, que es ese modelo fork/pull que mencioné. Evidentemente ese documento contiene información que es específica para ese proyecto, pero la idea es la misma. Crean un fork del repositorio central, lo clonan a la máquina donde van a trabajar, crean un branch, trabajan ahí, y cuando quieran cometer sus cambios al repositorio central para que todos los podamos ver, hacen un pull request. Yo lo recibo e integro.

[Nota: Como git es un sistema distribuido, todos los repositorios en principio van a ser equivalentes: no es que si yo no estoy no van a poder enviar sus cosas ni compartirlas a través de git. Sus copias del repositorio funcionan igual que la mía. Pero como yo soy el que integra, yo puedo encargarme de reunir el trabajo de todos y manejar la rama principal del repositorio original. -Manuel]

Trabajar de esta manera es por muchísimas razones preferible a trabajar enviando archivos por e-mail:

• Toda la información estará siempre disponible para todo el equipo en todo momento, y si no tienen acceso a Internet, igual tienen copias locales en sus máquinas de todos los archivos.
• Es muy sencillo ver archivos viejos que ya no estamos usando o volver a una versión vieja de un archivo o de un proyecto completo. Así, si hacemos un desastre con el código tratando de hacer algún cambio profundo o implementando algo nuevo, podemos simplemente deshacer los cambios y volver a cualquier punto de la historia del repositorio con muchísima facilidad.
• No hay que buscar en todos los e-mails enviados al grupo para encontrar un archivo: todo estará en un mismo sitio y hacer búsquedas es fácil; al final un repositorio es simplemente un directorio con archivos.
• Como todos tendremos el trabajo de los demás, se motiva el trabajo colaborativo e incremental, y así evitamos perder tiempo haciendo las mismas cosas muchas veces.
• Como cada quién tendrá una copia independiente y completa del repositorio, no existe la posibilidad de que se dañe accidentalmente el trabajo de los demás, y tampoco se dependerá de una sola persona que administre un repositorio central.

git es especialmente bueno para manejar archivos de código, pero puede contener cualquier clase de archivo y es igual de útil con archivos como documentos, imágenes o cualquier otra cosa. Lo ideal sería que todo el mundo ponga ahí todo lo que hagan. También está este wiki para comunicarnos. Con este wiki, el archivo de Google Spreadsheets y el repositorio git, tenemos las mejores herramientas de comunicación y cooperación que pudiéramos querer (salvo quizás por Google Wave, pero bueno, eso ya murió).