Tutoriales

Git es un sistema de gestión de versiones, como SVN o CVS, con algunas características que lo diferencian

Es distribuido. Mientras SVN o CVS, están orientados a tener un repositorio central sobre el que todos modifican, Git esta orientado a que cada cliente tiene su propio repositorio y sincroniza con uno central, o con alguno intermedio o con otro usuario. Esto da mucha flexibilidad a tu flujo de trabajo.
SVN o CVS son sistemas mas maduros que Git, con lo que existen mas clientes para todos los sistemas, y es mas fácil encontrar información concreta sobre estos. Sin embargo gracias al uso de Git para el desarrollo del kernel de Linux, ahora esta empezando a tener cierto auge.

Lo primero es o primero, y en este caso es instalar todas las herramientas necesarias para trabajar con Git, en mi caso trabajo exclusivamente desde la terminal, así que solo tengo que descargar los paquetes principales de la página de Git, dependiendo del sistema operativo en el que trabajemos.

Iniciando el repositorio:

La estructura general de un árbol de repositorios de Git, suele estar compuesta por un numero indeterminado de clientes que gestionan cada uno su propio repositorio, y que en algún momento ponen en común su trabajo con otro repositorio superior y común de Git. Para empezar a trabajar con ese repositorio superior y común, si ya existiera, deberíamos ejecutar algo como:

git clone protocolo://rutadelservidor/rutadelrepositorio

Pongo “protocolo://” por que git puede trabajar tanto con FTP, como con FTTP, como con RSYNC, o con el que yo trabajo normalmente SSH. Una vez ejecutado este comando, tendremos una copia del repositorio superior, o común en nuestro sistema, en la carpeta donde lo hayamos ejecutado, es decir, en nuestro repositorio privado. Se generaran todos los archivos necesarios, tanto los propios del servidor Git, como los archivos del proyecto en el que estemos trabajando.

Modificando el proyecto:

Una vez tenemos los archivos a nuestra disposición, podemos añadir nuevos archivos al proyecto, podemos eliminarlos del proyecto, o bien, cambiar los existentes. Para añadir nuevos ficheros al repositorio debemos ejecutar:

git add nombredelfichero-o-directorio

Para eliminar los archivos, es algo similar:

git rm nombredelfichero-o-directorio

Una vez hemos añadido, eliminado, o modificado un fichero ya existente en el proyecto, podemos ejecutar el comando:

git status

Este comando nos mostrará cuales son los archivos que se han modificado, añadido o eliminado en la carpeta del proyecto, pero que están pendientes de ser grabados en el repositorio privado. Es decir, para guardar en el repositorio privado los cambios, debemos ejecutar algo como:

git commit -a -m “mensaje descriptivo de esta versión que se esta subiendo”

Una vez ejecutado este comando, nuestro repositorio privado debe tener la ultima versión que existe en nuestro sistema de los archivos. Pero siempre hablando de nuestro repositorio privado. Si ahora ejecutáramos un “git status” deberíamos comprobar que no queda nada por actualizar o añadir.

Sincronizando con el repositorio público:

Una vez que tenemos una versión que queremos compartir con el resto de los usuarios del sistema debemos sincronizar con el repositorio público. Ya que es un repositorio público, pueden darse errores, como por ejemplo que dos personas hayan modificado la misma linea del mismo archivo, y Git no sepa con exactitud cual es la correcta. Para evitar esto, el flujo de sincronización es invertido con respecto a lo que seria lo “natural”. Es decir, seria algo como:

Obtengo versión pública -> Soluciono errores de mezclado -> Actualizo versión pública

Para obtener la versión pública, debemos ejecutar algo como:

git pull [alias del repositorio] [nombre de la rama]

Pues eso, podemos configurar para obtener de varios repositorios diferentes, aunque no es lo común. Ademas de obtener de varios repositorios, podemos obtener de varias ramas, dentro de cada repositorio. El tema de las ramas no lo voy a tratar hoy, así que simplemente pensaremos que existe una sola rama que se llama “master”. La rama “master” se crea por defecto en Git. Tanto, la rama por defecto, como el repositorio por defecto pueden configurarse en el archivo de configuración del repositorio de git, de forma que podríamos trabajar simplemente con un “git pull” a secas si lo tenemos todo bien configurado.

Una vez obtenida la información del repositorio público, Git nos alertará en el caso de existir discordancias entre las versiones, y no nos dejara publicar hacia el servidor público hasta que las resolvamos. Una vez resueltas las discordancias, debemos hacer un commit, tal y como explicamos antes, y para terminar y subirlo al servidor público, debemos ejecutar un:

git push [alias del repositorio][nombre de la rama]

Si todo ha ido bien, el servidor público de Git debe tener nuestra versión del proyecto como la ultima versión.

Resumiendo:

El flujo natural de trabajo que yo sigo es el siguiente:

Al iniciar a trabajar: git pull para obtener la ultima versión de todas.
Editas, añades(git add) o eliminas(git rm) los archivos que sean.
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Sincronizas con tu servidor privado con un: git commit -a -m “mensaje”
En el caso de querer actualizar el servidor público:
Obtenemos la ultima version de nuevo: git pull
Resolvemos las incoherencias entre las versiones
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Hacemos un commit a nuestro repositorio local
Sincronizamos hacia el servidor público con: git push.

No soy ningún experto en Git, y he obviado muchas cosas, como las ramas (branchs) o mas información sobre la configuración de los repositorios remotos (origenes). Puedes consultar muchísima mas información, y mucho mas correcta y precisa en las páginas de información de Git. Y si observas que cualquier cosa es incorrecta o puede ser explicada de mejor forma, no te cortes y compártelo en los comentarios.