Git series II – Comandos básicos

Como mencionamos en nuestra primera entrega del Git series, la consola de Git nos permite ejecutar comandos con muchísima más flexibilidad y usabilidad comparado con una GUI. Ante ello, nos dedicaremos a usar la consola.

Nota aparte

Si eres usuario de Linux y estás interesado en que el Shell te muestre el branch en el que te encuentras al entrar a un repo, puedes visitar este post para hacerlo. De esta manera, tu branch actual aparecerá al lado de tu path actual:

¿Cómo clonar un repositorio?

Para tener el repositorio remoto en tu ordenador personal, es importante clonarlo. Para ello, localizamos el enlace para clonar el repositorio. Para Gitlab:

Por simplicidad, usaremos la clonación con HTTPS:

git clone <LINK>

Por ejemplo:

git clone https://gitlab.com/lleon95/nsc-image-converter.git

Nos pedirá los credenciales:

• Usuario de Gitlab. Por ejemplo: lleon95
• Password de Gitlab.

Son los mismos credenciales con los que te registraste.

¿Cómo determinar en el branch que estoy?

Este es un punto muy necesario de aclarar. Antes de hacer cualquier commit, es necesario saber en cuál branch estamos ubicados. Para ello, usamos el comando:

git branch

Como resultado, nos aparecerán los branches, mientras que el actual aparecerá con un asterisco:

  develop
  feature/add-github-actions
* master

Para este caso, el branch actual es master.

¿Cómo creo un nuevo branch?

Antes que todo, es considero una mala práctica hacer commits directos al branch de master. Ante ello, crearemos un nuevo branch de ejemplo para ejecutar esta práctica.

Para crear un nuevo branch, debes ubicarte en el branch del que quieres salir (o donde estará la base del nuevo branch). Como vamos a salir de master, solamente crearemos el branch con:

git branch <new_branch>

Por ejemplo:

git branch mi_primer_branch

Este comando creará el branch «mi_primer_branch». Se puede ver la lista de branches con el nuevo branch con:

git branch

* master
  mi_primer_branch

¿Cómo me cambio de un branch a otro?

Después de crear el nuevo branch, vamos a querer movernos a dicho branch para comenzar a hacer commits. Para hacer esto, hacemos un checkout del branch.

git checkout <branch>

Usando el branch que creamos arriba:

git checkout mi_primer_branch

Verificamos que nos movimos al branch con:

git branch

  master
* mi_primer_branch

Note que el asterisco está ahora en «mi_primer_branch».

Agregar commits al repositorio local

Todos estos cambios que hemos realizado hasta el momento se encuentran en nuestro ordenador y no se han subido al repositorio remoto. Aprenderemos a enviar estos cambios al repositorio remoto en la siguiente sección.

Agregar cambios para hacer un commit

Un commit contiene los archivos que han cambiado. Supongamos que hemos creado/cambiado/eliminado un archivo llamado «README.md». El primer paso es agregar esos archivos que han cambiado en nuestro repositorio. Eso es possible mediante el comando ‘add’.

git add ./README.md

Este comando agrega los cambios del archivo README.md al próximo commit. Este paso debe hacerse para cualquier archivo que se cambie, agregue o elimine del repositorio. Siempre es útil saber cuales son los cambios usando el comando:

git status

Este comando desplegará una lista de untracked files y tracked files que han cambiado.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   README.md

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

	new_untracked.md

no changes added to commit (use "git add" and/or "git commit -a")

En el ejemplo, los cambios no staged son aquellos que se han modificado y ya existian en el repo. Los cambios que son untracked files son aquellos archivos que fueron agregados al repositorio pero que no existían previamente.

Para agregarlos, se usa el comando git add.

Crear un commit

Una vez agregados los cambios del repositorio, es tiempo de crear el commit. Para ello, usaremos el siguiente comando:

git commit -m "un mensaje ilustrativo"

Donde el texto un mensaje ilustrativo es un mensaje corto que describe los cambios de un commit. Usualmente, tiene la siguiente estructura:

• ¿Qué? En imperativo e infinitivo
• ¿Dónde? (opcional)
• ¿Por qué? (opcional)

Un ejemplo:

git commit -m "Agregar condición en la sesión del usuario para restricción por roles"

Con esto, el commit queda creado en el branch en el que estamos actualmente y podemos verlo a través del grafo con el comando:

git log --graph

Alguna consideraciones generales para los commits

Existen algunas buenas prácticas para los commits para facilitar la revisión de la historia y granuralizarla hasta donde tenga sentido lógico. A continuación se presenta una lista de recomendaciones:

• Mantener los commits de acuerdo a su función: no agregar cambios que no estén relacionados con el mensaje del commit. Si el commit dice: Agregar README al projecto; se espera que los cambios dentro del commit sean solamente la adición del README.
• Evitar los monster commits: los commits deben ser pequeños y tener un sentido lógico. Siempre se debe pensar en cómo tu yo del futuro puede familiarizarse con el historial del proyecto en 5 años en el futuro. Para ello, es siempre bueno granuralizar los cambios y que los commits tengan una sola responsabilidad.
• Ser consistente: dependiendo de la convención o el formato de los commits, es siempre bueno mantener la consistencia del mensaje del commit.
• Evitar agregar commits que rompan con el código: se debe garantizar que cada commit no interfiera con el código estable y que no lo rompa en la manera de lo posible. Ante ello, si uno agrega un nuevo módulo con una dependencia, siempre es bueno agregar el código del módulo y la dependencia en el mismo commit.

Subiendo los cambios al repositorio remoto (sincronizar)

Cada vez que se crea un nuevo branch o se crean una serie de commits, siempre es bueno sincronizar el repositorio remoto con el local para que los demás miembros del equipo tengan acceso a los cambios que realizaste. La sincronización usualmente se hace por branches y se realiza mediante el comando:

git push origin mi_primer_branch 

De lo anterior, se puede notar lo siguiente:

• origin: significa el origen del repositorio. Usualmente se refiere al alojamiento y es usualmente origin.
• mi_primer_branch: es el branch al que queremos sincronizar.

Algunas notas:

• Es bueno estar en el branch actual cuando queremos sincronizar. Si no, recuerda que checkout te permite cambiar el branch.
• Antes de dejar la computadora, siempre es bueno hacer una sincronización en caso de que algo adverso pase.
• Evitar sincronizar código sucio o roto.

Descargando los cambios del repositorio remoto

Siempre es bueno, antes de comenzar a trabajar, sincronizar nuestro repositorio local con el remoto. Para descargar los cambios que fueron agregados en tu ausencia. Para ello, hacemos pull de los cambios:

git pull origin mi_primer_branch

Siempre es bueno estar en el branch actual antes de sincronizar. La sintaxis es la misma que la de push.

Conclusión

En esta entrada vimos los comandos básicos y algunos tips de buenas prácticas. En la próxima entrada, veremos el Gitflow que nos permite paralelizar y ordenar nuestro repo.

¡Hasta la próxima!