GIT, y ahora que hago?

Hace ya un tiempo que empezamos a trabajar con GIT y como suele pasar despues de todo cambio positivo, cuesta entender por qué no haciamos esto antes.

Claro, todo esto suena muy lindo, pero no fue tan fácil desde el principio. "Veamos de qué se trata" dijimos y nos encontramos con: repository, local repository, init, clone, stage, commit, pull, push, fetch, merge, rebase, squash, branch, check out, tag, cherry pick… Si, "ya estamos mareados" pensamos, y sólo conocíamos los nombres de estas, que son algunas de las acciones que se pueden hacer con GIT y efectivamente se usan casi todas en lo cotidiano de un equipo de trabajo.

Una vez tomada la decisión, no quedaba otra opción que aprender lo más rápido posible. Buscar información clara y sobre todo en castellano no fue sencillo. Toda la documentación estaba en inglés y por si fuera poco, parecía dedicada a un experto más que a alguien que intentaba aprender cosas básicas como nosotros. Si bien hoy se puede encontrar documentación bastante más clara, decidimos aportar nuestro granito de arena, redactando un breve comentario con las características más usadas.

Repositorio remoto y otro local

Un repositorio de git se puede pensar como una carpeta que contiene información de las modificaciones que se fueron haciendo en el contenido del mismo organizada en comits y ramas, generalmente este repositorio se genera en alguna plataforma online, para poder compartirla facilmente como GitHub, Bitbucket, etc. De ahora en más nos referiremos al mismo como repositorio origen.

Un repositorio local de git no es más que una carpeta en nuestra computadora donde almacenamos nuestro código y una carpeta .git que guarda toda la información del repositorio principal además de una referencia al repositorio origen. Tambien podemos generar un "repositorio origen" dentro de una carpeta en forma local y trabajar con el mismo. La configuración mas común es generar un repositorio en forma online como ya mencionamos y varias copias, distribuidas en los equipos que colaborarán con nuestro proyecto.

Init

Esta acción se utiliza para generar un nuevo repositorio. No es el comando más usado, ya que sólo la usaríamos en dos situaciones.

1. Vamos a crear en repositorio origen en nuestro equipo. 
2. Vamos a generar un repositorio local y luego agregar manualmente la referencia al repositorio origen.

El primer punto puede realizarse ejecutando 'git init --bare' aunque ya discutimos por qué no es lo más común. Mientras que el segundo que cuenta con dos pasos puede resumirse usando el comando que veremos a continuación.

Clone

Lo más común es que varias personas trabajen en un mismo proyecto, por lo que generalmente se crea un repositorio público, al que todos tengan acceso y un repositorio local en cada puesto de desarrollo. El primero se genera usando ‘git init --bare’ o en plataformas online como vimos en el punto 1 del bloque anterior. En el punto 2 hicimos referencia a este comando que copia el repositorio origen a los puestos que van a colaborar en el proyecto ‘git clone’. Este comando genera un repositorio local con una copia exacta del repositorio origen en una ubicación especificada.

El comando generico para esto es ‘git clone origen destino’, donde origen es el path o url del repositorio origen a referenciar y destino el path donde queremos almacenar nuestra copia.

Fetch y Pull

Ambos comandos son utilizados para actualizar nuestro repositorio local con los datos del repositorio origen. El primero Fetch ‘git fetch –all’ actualiza sólo la carpeta .git, con lo cual podemos saber qué cambios hubo sobre el repositorio origen, pero no podemos interactuar con ellos ya que nuestro entorno de trabajo no fue modificado. Es como tener una foto del estado actual. Mientras que con el segundo ‘git pull’ se actualiza todo el repositorio, tanto la carpeta .git como nuestro directorio de trabajo y todos los archivos contenidos por el mismo. Después de ejecutar este comando, no sólo conocemos el estado del repositorio remoto, sino que somos capaces de interactuar con todos los cambios realizados por cualquier colaborador en el repositorio principal.

Hasta este momento sabemos cómo generar un repositorio, mantenerlo actualizado y sincronizado con un repositorio origen o remoto. Supongamos ahora que hicimos una modificación al proyecto y queremos que los demás lo puedan ver. Para esto tenemos que seguir una serie de pasos que se comentan a continuación.

Stage y Commit

Lo primero es generar un paquete con nuestras modificaciones y agregar una descripción del trabajo realizado, todo esto se conoce como 'commit'.
Después de modificar uno o más archivos, los mismos se encuentran en un estado ‘Dirty’ o sucio y para que formen parte de un commit, tienen que pasar por una etapa de stage, cuando hacemos esto estamos generando una imagen de estos archivos y esta información se almacena en la carpeta .git. Supongamos que agregamos un archivo test.txt a nuestro directorio de trabajo, antes de generar un comit ejecutamos 'git add test.txt' con lo cual agregamos este archivo al area de stagging.

Todavía la historia de nuestro repositorio no se modificó, para esto debemos confirmar los cambios que fuimos sumando al area de stagging y agregar un mensaje. Esto se conoce como 'commit' y ejecutando 'git commit -m "mensage"' lo generamos.

Ahora si, después de confirmar los cambios y agregar el mensaje, podemos ver como la historia de nuestro repositorio, se modifica y aparece el nuevo commit.

Push

Lo que nos falta hacer es compartir nuestro trabajo con el resto de los participantes del proyecto y para esto nuestros commits deben publicarse al repositorio origen. Para lograrlo es que usamos el comando ‘push’. Esta es la única acción de las realizadas hasta el momento que modifica el contenido del repositorio remoto.
Simplemente ejecutando ’git commit origin master’ logramos que nuestros commits viajen hasta el repositorio origen, modificando la historia del proyecto que todos ven. Una vez hecho esto, el ciclo vuelve a comenzar.

Este es un acercamiento básico a GIT que esperemos ayude a clarificar algunas dudas, Si bien comentamos las acciones basicas que funcionarían bien en un proyecto con un solo desarrollador, el proceso puede complicarse al agregar participantes

Otras entradas de nuestro blog sobre este tema:

Git submodulos anidados


Puente entre TFS y Git

Obtener version de Git tag desde CCNET

Empezando en Git ...

Git, paquetes Nuget y caracteres de fin de linea

Twittear Seguir a @3p_ar