Git (III). Guía Completa con lo Básico para Empezar

Muy buenas lector. Este es el tercer post de la serie sobre Git, el famoso sistema de control de versiones desarrollado por Linus Torvalds en 2007, y que a día de hoy podemos decir que se ha convertido en el estándar en el estándar de facto en su ambito.

Si has visto ya las dos primeras páginas de la serie, en esta tercera ya podrás pasar a la parte más práctica, y te ofreceré un detalle de los principales elementos que intervienen en el flujo de trabajo de Git, y los comandos mprescindibles que debes conocer en tu día a día para trabajar de forma ágil y eficiente. Personalmente me he iniciado hace poco a Git, por lo que en cierto modo estaremos haciendo el viaje juntos.

Tabla de contenidos:

Repositorios
Commits
Ramas
Merging de ramas
1. Hacer un merge entre dos ramas
Continuación

Repositorios

Cada vez que necesites gestionar un nuevo proyecto con Git, necesitas crear un repositorio de Git, que será basicamente el directorio de trabajo dentro del cual Git mantendrá un registro de todos los cambios en los ficheros contenidos en él (incluyendo subdirectorios).

Hay dos maneras de empezar a trabajar con un repositorio local de Git, pero en ambos casos el resultado final acabará siendo el mismo.

Creándolo de cero partiendo de un directorio en tu sistema de archivos local (cualquier directorio local puedes transformarlo en un repositorio local de Git).
Clonando un repositorio ya existente, típicamente de alguna plataforma como GitHub, lo que creará igualmente un directorio en tu sistema de archivos local, que en este caso ya estará configurado como repositorio de Git. En este caso, además, Git ya contará con todo el histórico de cambios previos realizados en el repositorio.

Puedes tener tantos repositorios de Git como necesites en tu maquina local (por lo general, cada proyecto requiere su propio directorio de trabajo), y Git gestionará cada uno de ellos de forma independiente. Lo que si es importante tener en cuenta es que, cuando un directorio local está configurado como repositorio de Git, todos los subdirectorios contenidos en él son igualmente parte del mismo.

Estéticamente, a nivel de sistema de archivos local, no hay ninguna diferencia aparente entre un directorio normal y uno que haya sido configurado como repositorio de Git, salvo por el hecho de la existencia de una carpeta oculta denominada .git, que se crea cada vez que se inicializa un nuevo repositorio, dentro del directorio en cuestión.

Esta carpeta es la clave de todo, puesto que es la que utiliza Git para almacenar todos los ficheros que necesita para funcionar, incluyendo los registros de cambios de version de los diferentes ficheros. Si la borraras por accidente, se perdería todo el histórico de cambios que haya almacenado Git hasta la fecha, por lo que, literalmente, este directorio perdería la entidad de repositorio de Git.

Hecha esta breve introducción sobre los repositorios, es el momento de pasar a la parte práctica sobre el uso de los mismos. En los próximos parrafos aprenderás a crear un repositorio de Git desde cero, a clonar uno ya existente en tu equipo local, y también, muy importante, a comprobar si un directorio en cuestión es, de hecho, un repositorio de Git.

Crear un Repositorio Local de Git

Si quieres empezar a gestionar un nuevo proyecto con Git, el primer paso es crear el directorio de trabajo que vaya a contener todos los ficheros del proyecto. Este será también el directorio que utilizarás para generar tu primer repositorio de Git.

Para crear tu nuevo directorio de trabajo desde la consola, primero debes situarte en la ruta en la que quieres situarlo, utilizando el comando cd. Una vez te encuentres ya en la ruta correcta, puedes crear el nuevo directorio utilizando mkdir, tal como te enseño en este ejemplo (debes sustituir <nombre-directorio> por el nombre que tu quieres darle, por ejemplo proyecto-git).

mkdir <nombre-directorio>

Hecho esto, lo siguiente será situarte dentro del directorio que acabas de crear, para establecerlo como directorio actual de trabajo.

cd <nombre-directorio>

Situado ya dentro del nuevo directorio de trabajo, ahora si es el momento de instanciar tu primer repositorio local de Git, con el comando que tienes debajo. Hecho esto, este directorio ahora será también un repositorio de Git.

git init

A simple vista no verás ningún cambio en el directorio, pero si analizas los ficheros ocultos que contiene, cosa que puedes hacer con el comando que te dejo justo debajo, verás que ha aparecido la carpeta oculta .git. de la que te he hablado antes.

ls -a

Esta acción solo necesitas hacerla al prinicipo, durante la creación del repositorio, y aplica también a todos los subdirectorios contenidos dentro.

Clonar un Repositorio Remoto de Git en un Directorio Local

En el primer paso has visto como crear un repositorio local de cero. Aún así, si lo que quieres es empezar a trabajar con un proyecto existente, ya sea porque quieres contribuir en él, o simplemente porque lo quieres tomar como punto de partida para un proyecto tuyo, tienes la opción de clonar el repositorio de ese proyecto.

Para ello, el repositorio debe ser accesible publicamente en alguna plataforma como GitHub, GitLab o Bitbucket. Si este es el caso, verás que la propia plataforma ya te da la opción de clonarlo, y te suministra una URL. Con ello, ahora solo debes situarte en la ruta que quieres que contenga este nuevo repositorio local, y ejecutar el siguiente comando, sustituyendo <url> por la URL que corresponda.

git clone <url>

Con este te aparecerá un nuevo directorio en tu equipo, y que ahora podras gestionar como repostitoio local de Git. La diferencia con respecto al caso anterior es que, en este caso, además de incluirse todos los ficheros propios del proyecto, tendrás también el histórico de todos los cambios que han habido desde que se creó el repositorio.

Comprobar si un Directorio está configurado como Repositorio de Git

Como he comentado antes, el hecho de instanciar un repositorio de Git partiendo de un direcctorio de trabajo afecta también a todos sus subdirectorios. Esto es importante tenerlo en cuenta, para evitar, por error, instanciar un nuevo repositorio de Git dentro de otro.

Así, para evitar sustos, lo más fácil es que, antes de instanciar un nuevo repo de Git, compruebes que el directorio en el que te encuentres no esté configurado ya como repositorio de Git, aunque sea a nivel de directorio padre. Esto puedes hacerlo con este comando:

git status

Al ejecutarlo, si obtienes una salida como la que te muestro a continuación, significa que ese directorio no está configurado como repositorio de Git, por lo que podrías instanciar tu nuevo repositorio ahí sin problemas.

fatal: not a git repository (or any of the parent directories): .git

Si, por contra, te aparece una salida del estilo de lo que te copio debajo, entonces significa que tu directorio actual ya es parte de un repositorio de Git. El mensaje concreto dependera del estado actual de Git en este repositorio, como verás un poco más adelante.

On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

En los próximos parrafos te explicaré como interacturar con Git dentro de este o cualquier otro repositorio.

Commits

Los commits son la forma en que Git organiza el histórico de cambios dentro de un repositorio, y son la pieza central en el flujo de trabajo de Git. Un repositorio de un proyecto medianamente grande puede contener facilmente miles y miles de commits, ordenados de forma secuencial, uno tras otro. Cada commit debe entenderse como un snapshot con los últimos cambios publicados en el repositorio desde el commit anterior.

En el proceso de publicación de un commit intervienen tres áreas fundamentales que debes entender a la perfección, porqué aparecerán de forma recurrente de ahora en adelante.

El directorio de trabajo, que es el directorio local del que parte el repositorio de Git, y va aplicando todos los cambios que hagas en cualquiera de sus archivos en tiempo real, al igual que cualquier otro directorio.
El área de preparación o de staging, que es una zona de almacenamoento temporal en la que debes incluir los archivos con cambios que quieres incluir en el próximo commit, para que estos también pasen a formar parte del repositorio.
El repositorio en sí, que únicamente va registrando los cambios realizados en los ficheros a través de los sucesivos commits que se vayan publicando. La versión de los archivos que figure en el repositorio es la que será común para todas las personas que tienen acceso al repositorio.

Cada commit contiene un identificador único consistente en un hash de 40 dígitos, aunque a menudo se presenta en un formato reducido con los 7 primeros dígitos.

Un commit debes generarlo tu mismo de forma selectiva, cada vez que haya nuevos cambios a nivel de directorio de trabajo, y quieras que estos pasen a quedar registrados a nivel de repositorio. El proceso de publicación de un commit generalmente pasa por tres fases diferentes, tal como verás a continuación.

Comprobar Ficheros Actualizados en tu Directorio de Trabajo

A medida que vayas trabajando de forma local con los archivos del repositorio, se creará una divergencia entre el estado que figura a nivel de directorio de trabajo (que funciona en tiempo real), y el que refleja el repositorio (que vendrá determinado por el último commit publicado). Para que estos nuevos cambios queden registrados a nivel de repositorio, deberás incluirlos en un nuevo commit.

El primer paso en el proceo de preparación de un commit es conocer cuales son esos archivos que presentan divergencias. Esto puedes con el siguiente comando que ya conoces de antes:

git status

En el output que te generará, ahora debes fijarte en la tercera fila. Si te aparece algo como nothing to commit, significa que no hay cambios entre directorio de trabajo y repositorio.

On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Si, por contra, te aparece una salida como la que te muestro debajo, significa que los ficheros listados aquí han sufrido cambios en tu directorio local, y, por lo tanto, son susceptibles de incluir en un próximo commit.

On branch master

Untracked files:
  (use "git add <file>..." to include in what will be committed)
      <archivo1> <archivo2> <archivo3>

nothing added to commit but untracked files present (use "git add" to track)

Ahora, el siguiente paso previo a la publicación del commit es incluirlos en el área de staging.

Añadir Ficheros Actualizados en el Área de Staging

En el área de staging es donde debes añadir los archivos que quieres incluir con el próximo commit, para que su versión se equipara con la que consta en el repositorio. Aunque hayas hecho cambios en varios archivos, no tienes porqué añadirlos todos.

Para añadir uno o varios archivos en el área de staging debes utilizar el siguiente comando, sustituyendo <archivo> por el nombre real de cada uno de los archivos que quieres incluir (separados por un espacio).

git add <archivo>

Aunque con el comando anterior puedes controlar de forma selectiva los ficheros que te interesen añadir, si lo que quieres es incluir directamente todos los archivos con cambios en el área de staging, lo más rápido es sustituir el nombre de los archivos por un punto, como ves aqui:

git add .

Todos los ficheros incluidos en el área de staging, ahora, cuando en el siguiente paso publiques el commit, van a quedar actualizados a nivel de repositorio.

Publicar un Commit con los Cambios Añadidos al Área de Staging

Ahora que ya has agrupado los cambios que desees publicar con el próximo commit en el área de staging, solo falta publicar el commit en si.

La forma tradicional de publicar un commit es mediante la orden que te dejo a continuación. Al ejecutar este comando, Git te abrirá el editor de código por defecto que tengas configurado en Git, para que escribas el nombre del commit. Hecho esto, el commit ya estará publicado.

git commit

Si no quires tener que indicar el nombre del commit en un paso separado, también puedes hacerlo en el mismo comando, tan solo debes añadir el parametro -m al comando anterior, seguido el nombre del commit entrecomillado. Personalmente, esta es la forma que suelo utilizar más a menudo (salvo que quieras indicar un parrafo como mensaje).

git commit -m "<Nombre del commit>"

Una vez publicado el commit, se limpiara el área de staging, y el repositorio pasará a incluir la versión más actualizada de esos ficheros (hasta que hagas nuevos cambios en más ficheros, y el ciclo vuelva a comenzar).

Ver Histórico de Commits de la Rama Actual

Cuando lleves ya tiempo trabajando en un proyecto, o en caso de que hayas clonado un repositorio externo, es normal que quieras consultar el histórico de commits que han sido publicados.

La forma clasica de hacer esto es mediante el comando que te dejo a continuación, que te mostrará un listado resumido de todos los commits

git log

En proyectos grandes, cuando quieras analizar el histórico reciente, facilmente te puedes encontrar con la necesidad de analizar varias decenas de commits. Si este es el caso, te puede insteresar mostrarlos en un formato más resumido, para poder ver más commits de un mismo vistazo. Para ello, tan solo debes añadir el parámetro --oneline al comando anterior.

git log --oneline

Ambas formas son perfectamente válidas para revisar el histórico de commits del proyecto, pero personalmente acabo haciendo mucho más uso de la segunda, ya que se me hace mucho más comoda de leer (aunque no presente tanta información, es suficiente).

Ramas

Todo lo visto hasta aqui esta muy bién, pero la gracia de Git es justamente el hecho de poder seguir varias líneas de desarrollo en paralelo. Y esto es justamente lo que te permite el sistema de ramificaciones de Git, y de una manera particularmente potente, rápida y eficiente.

Una rama de Git no es más que una línea de desarrollo formada por una sucesión de commits. Por defecto, cuando se inicia un nuevo repositorio, con la publicación del primer commit se crea la que se conoce como la rama master, que es la rama principal del proyecto.

A partir de ahí, a medida que el proyecto siga evolucionando, puede llegar un momento en el que quieres trabajar en una característica concreta, pero que no quieres incluir en la rama principal hasta que no este finalizada, para no entorpecer el flujo de trabajo de la misa. Ahí es cuando te interesa ramificar el proyecto.

Git utiliza un puntero denominado HEAD para identificar la rama en la que se encuentra, y que por defecto apunta siempre al último commit de la rama en cuestión. Cuando se crea una rama nueva, Git crea un nuevo apuntador móvil para el mismo commit actual, pero que ya formará parte de esta nueva rama.

En proyectos grandes es muy fácil que coexistan varias ramas y subramas, y la lógica de uso de las mismas puede obedecer a una gran variedad de critérios.

Realizada esta breve introducción sobre el uso de las ramas, vamos a por la parte práctica. Antes, sin embargo, te dejo la referencia oficial de Git, por si quieres profundizar más en los funcamentos teóricos de las ramificaciones.

Git SCM. Ramificaciones

Crear una Nueva Rama

Con la creación de una nueva rama, lo que sucede por debajo es que se crea un nuevo apuntador del mismo commit en el que estas, de manera que, partiendo de este mismo commit, se podrán seguir dos caminos, en función del apuntador en el que estés situado.

Puedes crear un nueva rama con el comando que tienes a continuación, sustituyendo <nombre de la rama> por el nombre que quiras darle.

git branch <nombre de la rama>

¡Ojo! El comando anterior solo te crea la rama, pero no hace que saltes a ella. Tu referencia HEAD sigue apuntando a la rama actual, de forma que, si publicases un nuevo commit ahora, este extendería la rama actual, no la nueva que acabas de crear.

Saltar a otra Rama

Si quieres publicar un commit a una rama diferente de la actual, tanto si es una rama ya creada de antes, como si la acabas de crear ahora, primero tienes que situarte en ella.

Para saltar a una rama en particular tan solo debes ejecutar el comando de Git que de indico a continuación, sustituyendo <nombre de la rama> por el nombre de la rama en cuestión.

git switch <nombre de la rama>

Existe un atajo con el que podrás, en un mismo paso, crear una nueva rama partiendo del commit actual, y, a la vez, saltar automáticamente a ella. Esto lo puedes hacer añadiendo el parámetro -c al comando anterior. Con esta acción lo que haces es saltar a la rama indicada, y, en caso de que no exista, crearla antes.

git switch -c <nombre de la rama>

Cuando Git hace un salto rama, lo que ocurre por debajo es que la referencia HEAD se situa en el último commit de la rama indicada, para que el próximo que publiques quede registrado tras este en dicha rama. Si la rama la acabas de crear, el commit será el mismo que el de la rama actual, pero con la referencia de la nueva rama.

Ver Ramas Utilizadas en tu Repositorio Actual

Aunque, de un inicio, la unica rama que existirá es la principal, para repositorios con los que lleves tiempo trabajando, o en los que contribuya mas gente, es habitual la existencia de varias ramas.

Con el comando que tienes debajo podrás conocer, en todo momento, que ramas existen en un momento dado en tu repositorio local, destacando además con un * la rama en la estés situado en este momento.

git branch

La en la que estés es en la que se registrará el próximo commit que publiques.

Renombrar una Rama

Aunque seguramente no es muy habitual, puede suceder que, tras haber creado una rama y haber empezado a trabajar en ella, el enfoque de la misma cambie, y su nombre ya no sea un buen reflejo de la misma.

En estos casos, puedes cambiar el nombre de la rama tan solo situandote a ella, y ejecutando el siguiente comando, que basicamente cambia el nombre de la rama actual en la que te encuentres, por el que especifiques tras el parametro -m.

git branch -m <nombre de la rama>

Uno de los casos más tipicos en los que el cambio de nombre de una rama puede ser interesante es si trabajas con repositorios de GitHub, puesto que por convenio, GitHub utiliza el nombre main para identificar a la rama principal. Si quieres utilizar el mismo critério para tu repositorio local, con el comando que te dejo a continuación podrás renombrar la rama principal de tu repositorio local, de master a main.

git branch -m master main

El hecho de renombrar una rama aquí solo tiene efecto a nivel del repositorio local en el que te encuentres, pero si quieres que, por defecto, Git empieze a nombrar a su rama principal como main en todos los repositorios que crees a partir del momento, puedes hacerlo mediante un ajuste a nivel de configuración global, tal como te muesto aqui.

Merging de Ramas

Llegado el momento, una vez finalizada esta línea de desarrollo en paralelo, si te interesa implementar los cambios que has estado implementando ahí con la línea principal de desarrollo, lo que se hace es realizar un merge entre ambas ramas.

En el momento de realizar una fusión entre dos ramas, pueden darse estas tres situaciones que te detallo a continuación:

Si a la hora de hacer el merge de una rama, que denominaremos secundaria, con la rama actual en la que te encuentres, no han habido nuevos commits en esta rama, desde el momento de la bifurcación en que se creó la secundaria, el merge es lo que se denomina un fast-forward. Esto significa que todos los commits de la rama secundaria se añadirán tal cual en la rama actual, y esta acabara apuntando al último commit publicado en la rama secundaria.
Si, por contra, a la hora de hacer el merge, si que hay commits publicados en la rama actual desde el momento de la bifurcación, pero no hay cambios que entren en conflicto entre ambas ramas, el merge consistirá en la publicación de un commit automático que unirá de nuevo las dos ramas, y que basicamente añadirá los cambios de la rama secundaria a la rama actual.
Si estamos en una situación como la anterior, pero en este caso si que hay cambios conflictivos entre las dos ramas, en el momento del merge Git alertará de ello, y serás tu que manualmente tendrás que abrir los ficheros que contengan los cambios conflictivos, para arreglarlos.

Visto esto, veamos como ponerlo en práctica.

Hacer un Merge de dos Ramas

Cuando se hace un merge, realmente se trasladan los cambios que se han publicado en un a rama concreta, a la rama actual en la que te encuentres en este momento. Por ello, antes de hacer el merge, primero debes asegurarte de estar situado a la rama de referencia, que es la que seguirá existiendo tras el merge.

A partir de ahí, para efectuar el merge, tan solo debes ejecutar el siguiente comando, sustituyendo <nombre de la rama> por el nombre de la rama concreta que quieres fusionar con la actual.

git merge <nombre de la rama>

Hecho esto, en función de si hay cambios que entren en conflicto entre ambas ramas, tal como has visto más arriba, es posible que necesites acceder a los ficheros afectado para solventa los conflictos. Si este es el caso, tras aplicar las correcciones, necesitarás añadir los ficheros en el area de staging y publicar un nuevo commit, que es el que unirá las dos ramas.

Continuación

En esta guía habrás podido conocer los elementos más principales con los que opera Git, y los comandos mas importantes que debes dominar a la perfección para empezar a trabajar con Git.

Existen, sin embargo, muchas otras acciones que es interesante que conozcas, y que te explicaré en la próxima página de esta serie sobre Git. Debajo te dejo la lista completa con todos los páginas de esta série, y que iré ampliando conforme las vaya teniendo publicadas.

¡Un saludo y hasta la próxima!