Se encuentra usted aquí

Usar un sistema de control de versiones, como Git, trae consigo un universo de posibilidades, pero es especialmente brillante cuando se trata de colaborar con tus compañeros de trabajo, o proyecto. Hoy en día es impensable, por ejemplo, encontrarte con un proyecto de Software Libre que no use Git, SVN o Mercurial.

Si no has usado Git antes y quieres aprender, no te pierdas el tutorial sobre cómo usar Git, paso a paso, con un ejemplo del mundo real. En este artículo vamos a empezar por donde lo dejamos allí.

Clonar un repositorio y subir los cambios

Descargarte el contenido de un repositorio no podría ser más sencillo. Basta con usar el comando git clone <dirección del respositorio> <directorio de destino>. En mi caso, he subido los ficheros de este tutorial a GitHub, un servicio gratuíto para tus repositorios Open Source (luego hablaremos de los privados). Voy a clonarlo en un directorio llamado "git-tutorial" en mi escritorio, para que veas lo fácil que es:

$ git clone https://github.com/piradoiv/git-tutorial.git git-tutorial

Haciendo uso de Git clone

Como puedes ver, se ha descargado los ficheros. Es más, se ha descargado todo el historial de cambios, como puedes ver ejecutando el comando git log:

Comando Git log

Puedes moverte por el log usando los atajos de VIM, J para bajar, K para subir, CTRL + F página siguiente, CTRL + B página anterior. Si escribes una Q, saldrás de esa pantalla. También puedes usar el comando gitk para ver el historial de cambios de una manera visual, como ya mencionamos en el tutorial anterior.

Ahora nos encontramos con un problema. Al no ser el dueño del repositorio, ni tener permisos para editarlo, no podrías subir tus cambios por mucho que quisieras. Compruébalo tú mismo:

$ git push origin master

Con el comando push, enviamos los cambios, origin es el repositorio de destino al que los pretendemos enviar y, finalmente, master sí que te sonará, es la rama principal de desarrollo. En lugar de master, podríamos enviar cualquier otra rama, o todas a la vez usando la opción --all.

Demostración de la autenticación con Git push

Por supuesto, si eres el amo y señor de tu repositorio, o tienes permisos de escritura en el repositorio de un compañero, no tendrás problemas en subir tus cambios.

Colaborando mediante Pull request

"¿Y cómo diantres puedo colaborar con un proyecto Open Source si está cerrado a las modificaciones?". Tanto GitHub como BitBucket utilizan el llamado Pull Request. Pero antes de nada, ¿qué significa pull?.

$ git pull

Usando Git pull en un repositorio que ya está actualizado

Este comando descarga todos los cambios que se hayan subido al servidor y que nosotros no nos hayamos descargado todavía. Por ejemplo, si yo hiciese un cambio ahora en la rama master y tú hicieses git pull, sincronizarías tu rama con la del repositorio principal. En caso de conflicto (has editado una linea que yo he editado también), automáticamente Git crearía una rama especial para que los resuelvas (elegir con cuál de las dos lineas nos quedamos) y fusionar los cambios de nuevo con la rama con la que estábamos trabajando.

Mediante los Pull Request, trabajamos de una manera diferente:

  1. Clonas el repositorio entero que quieres modificar
  2. Creas una nueva rama para los cambios que quieres hacer
  3. Subes tu nueva rama de desarrollo a tu repositorio clonado
  4. Le envías la petición a la persona encargada de mantener el repositorio final, para que fusione los cambios con la rama principal.

El Software Libre se nutre de las miles (o millones) de mini-aportaciones que se hacen día a día en cada proyecto.

Manos a la obra, crea una cuenta en GitHub y haz un Fork de mi repositorio. "¿Un qué?"

Tenedor, Fork en Inglés

© Foto, Wikipedia

En inglés, Fork significa Tenedor, y le da un significado visual a la acción de extender el repositorio con nuestras aportaciones, y las de los demás. Cada punta del tenedor representa clones del repositorio inicial, en el que se están haciendo modificaciones que serán enviadas de vuelta mediante Pull Requests.

Así que, adelante, forkea mi repositorio, clónalo en tu ordenador, haz cambios en una rama nueva y súbelos de vuelta a GitHub, mediante git push.

$ git push origin <el-nombre-de-tu-rama>

Creando el fichero README

En lugar de vim README, usa el editor de textos que quieras. Luego, envía tus cambios a tu repositorio:

Git push del fichero README

Ahora puedes visitar tu repositorio de GitHub, te mostrará un mensaje avisándote que has subido una nueva rama y te sugiere que le eches un vistazo, comparándola y creando un Pull Request.

GitHub compare & pull request

Haz click en el botón y rellena el formulario:

Formulario Pull Request

Perfecto, envía el Pull Request, se generará una página similar a ésta:

Revisión del Pull Request

En caso de que todo vaya bien, el Pull Request mostrará el mensaje "This pull request can be automatically merged", porque no tendrá ningún conflicto. En caso contrario, tendrás que corregirlos previamente para que el dueño del repositorio pueda fusionar los cambios.

Repositorios privados

Si tus proyectos son privados, tienes la opción de irte a una opción de pago en GitHub ($7/mes por 5 repositorios privados), o probar BitBucket, que ofrece repositorios privados sin límite. Los dos servicios tienen sus pros y sus contras. Personalmente uso BitBucket para mis proyectos personales privados y GitHub para los que son Open Source.

En ambos casos, puedes asignar permisos de sólo lectura, lectura y escritura o administración para cada miembro al que le quieras dar acceso y también soportan los Pull Requests por igual. En cuanto a las estadísticas, las de GitHub son geniales, pero el registro de commits de BitBucket se lleva la palma, a mi gusto:

Log de commits de BitBucket

Te recomiendo que pruebes los dos y uses el que prefieras (o ambos, como yo).

Cuando tus compañeros no quieren aprender a usar Git

Si tienes la suerte de contar con compañeros que usen Git (y lo usen bien), ¡felicidades!. En caso contrario, todavía puedes seguir usando Git a nivel personal, mientras ellos trabajan viviendo al límite.

En estos casos, lo que hago es crear una rama a partir de la de develop que se llame, por ejemplo, ftp-update. Sincronizo por FTP todos los cambios que han subido los compañeros y envío un commit general:

$ git commit -am "Sincronizar los cambios por FTP"

Luego ya puedo seguir trabajando normalmente. Créeme que en más de una ocasión he podido rescatar cambios que se consideraban "perdidos", al ser demasiado viejos. ¿Te suena esa típica sección que "ya no necesitaremos nunca más" y que al par de meses tienes que volver a añadir a vida o muerte?. Siempre estará contigo en el repositorio de cambios.

Que tus compañeros no usen Git, no te limita a ti a no usarlo. Puede que parezca que estás haciendo un trabajo extra, pero créeme cuando te digo que vale la pena cada segundo que has invertido. Además, llegado el momento del desastre, puedes anunciar que pudiste rescatar esas lineas de código gracias a que usas un control de versiones. En este punto le puedes remitir al tutorial Aprende a usar Git con este ejemplo real ;-)

¿Alguna duda?, ¡sígueme en Twitter y te la respondo!

Comentarios

Añadir nuevo comentario

Plain text

  • No se permiten etiquetas HTML.
  • Las direcciones de las páginas web y las de correo se convierten en enlaces automáticamente.
  • Saltos automáticos de líneas y de párrafos.