Git rebase & squashing
Tags: git
Published: 2021-02-07 12:08:27

---
title: Git rebase & squashing
published: true
description: Guía básica de rebase & squash
tags: Git
cover_image: https://vabadus.es/images/cache/thumb_listado/images/articulos/5c9deef127c7d783462103.png
---
La semana del 1ro de Febrero fue muy importante para mí dado que la empresa Double Point confió en mis aptitudes para desempeñarme como Frontend Developer, lo cual agradezco muchísimo y estoy muy contento.

Pero más allá de todo lo que implica un nuevo trabajo, esta semana mi líder Mati me enseñó algo muy importante relacionado a Git, lo cual me parece fundamental a la hora de trabajar en equipo y mantener la calidad en los commits: **git rebase**.

_Hago un apartado y sugiero que tengan instalada la extensión de VSCode llamada GitLens, que nos será de utilidad en un rato_

Cuando vemos que una tarea nos está llevando determinado tiempo y cantidad de commits, es cuando vamos a considerar llamar a un gran amigo como es **git rebase**. Podemos decir que **git rebase** es como la unificación de un commit padre con sus commits hijos. Haciendo **git log**, veamos el siguiente historial de commits:

![alt text](https://i.postimg.cc/50xnQfnQ/git-rebase-1.png "Consola de cmder que mostra un historial de commits")

Aquí nosotros estamos utilizando:
- Tres ramas: **master > develop > feature/replace**
- La más afectada es **feature/replace** con cuatro commits, la cual en principio es nuestra tarea y la modificamos a medida que hacemos cambios pequeños.

Ahora nos vamos a concentrar en el primero de los commits de la rama **feature/replace**: _feat: se implementó la lógica con el método replace_

En este caso, la estructura del commit padre es simple: _[tipo]:[descripción]_

_Si nunca han trabajado con tipos de commits, háganse una idea que puede ser algo como "**style**: cambios de background al body" o "**fix**: se corrigió la función getUser() que devolvía null", por poner ejemplos sencillos_

Sabiendo de que mantenemos nuestro commit padre o commit principal con esta estructura, cada nuevo commit que hagamos **pre** rebase, lo pueden guardar como más les guste o convenga **porque no es algo que nuestres compañeres vayan a ver**. Todo se va a quedar en: _feat: se implementó la lógica con el método replace_  

##¡Hagamos rebase!

_En este caso_ el comando final que vamos a utilizar para hacer rebase es **git rebase -i HEAD~4**. Explico:
- El parámetro **-i**: es para que al hacer un rebase de varios commits te lleve a un editor donde podes decidir que hacer con cada commit
- **HEAD~4**: con esto le decimos que sobre la rama actual queremos seleccionar los últimos 4 commits (commit principal y sus tres hijos). En caso de haber más cantidad de commits hijos, se debe cambiar el número.

Ejecutando esto, el VSCode se abrirá automáticamente (gracias a la extensión _GitLens_) y obtendremos una ventana como esta:

![alt text](https://i.postimg.cc/Pqhqgqt7/git-rebase-2.png "Ventana de Visual Studio Code dando la opción de hacer rebase")

**¡Perfecto!** Ya casi está. Ahora vamos a seleccionar **squash** para poder unificar los commits. Después de eso, click al botón de **start rebase**.

![alt text](https://i.postimg.cc/HLq1qZ4k/git-rebase-3.png "Ventana de Visual Studio Code con la opción de squash")

Por último, se nos abrirá esta ventana donde básicamente nos dice que podemos ignorar ciertos commits si los comentamos con un **#**
![alt text](https://i.postimg.cc/ZRwF9g7T/git-rebase-4.png "Últimos cambios del rebase en Visual Studio Code")

Dejamos descomentado sólo el commit principal y el que verán los demás integrantes del equipo. Finalizamos guardando con **Ctrl + S**

![alt text](https://i.postimg.cc/sDxyZhXy/git-rebase-5.png "Finalizando el rebase en Visual Studio Code")

##Conclusión
**git-rebase** puede ser un arma extremadamente poderosa y útil para nuestro día a día, permitiéndonos hacer tantos commits como queramos para luego emprolijar y unificar todo en uno.

###Pro tips:
- Santiago Santana, Software Specialist: _"Debemos **evitar** hacer rebase de commits pusheados en una rama que vean otros miembros del equipo, dado que no podrán pullear ni mergear por el cambio de historia"_