Version Control on kenji.blog

【Comandos Git】Diferencias entre rebase y merge, y su uso correcto en la práctica

Sun, 13 Sep 2026 09:00:00 +0900

1. Introducción: ¿Por qué “merge o rebase” es un dilema eterno?

Git es un sistema de control de versiones indispensable en el desarrollo de software moderno. Cuando múltiples desarrolladores cambian simultáneamente una base de código, el poderoso modelo de ramas de Git demuestra su valía. Sin embargo, en el desarrollo en equipo, el debate sobre “si usar merge o rebase” es uno de los temas que siempre preocupa a los desarrolladores, desde principiantes hasta expertos.

En este artículo, desentrañaremos las diferencias en los mecanismos de git merge y git rebase, partiendo de la estructura interna de Git, el DAG (Grafo Dirigido Acíclico), y las propiedades matemáticas de los hashes de los commits. Luego, explicaremos a fondo cómo usar y diferenciar ambos en la práctica, acompañándolo con flujos de trabajo concretos. Al ir más allá de la simple introducción de comandos y comprender qué cálculos realiza Git en segundo plano, perderás el miedo a los conflictos y podrás construir un historial limpio y rastreable.

2. Estructura interna de Git: Hashes de commits y modelo de objetos

Para comprender cómo Git integra el historial, primero debemos saber cómo Git almacena los datos. Git no solo almacena las diferencias (parches) de los cambios en los archivos, sino que guarda una instantánea de todo el sistema de archivos en un momento dado.

2.1 Propiedades criptográficas de los hashes de los commits

Cada commit en Git se identifica de forma única por un número hexadecimal de 40 dígitos generado por la función hash SHA-1 (Secure Hash Algorithm 1) calculada a partir de su contenido. Un objeto commit consta de los siguientes elementos:

Puntero al objeto Tree: Una instantánea de la estructura de directorios y archivos (Blob) en ese momento.
Puntero al commit padre: El valor hash de uno o más commits padres (el primer commit no tiene padre, y un commit de fusión (merge) tiene dos o más padres).
Información del autor (Author): Quién escribió el código y cuándo.
Información del confirmador (Committer): Quién creó y aplicó el commit y cuándo.
Mensaje del commit: Texto que explica la intención del cambio.

Expresado matemáticamente, el valor hash $H(C)$ para un objeto commit $C$ se define de la siguiente manera:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Aquí, $\parallel$ representa la concatenación de datos. Debido a las propiedades de la función hash, incluso cambiar un solo carácter en el mensaje del commit, o tener un commit padre diferente, generará un valor hash completamente distinto. Es decir, los commits son inmutables (Immutable). Cuando se dice más adelante que rebase “reescribe el historial”, en realidad significa “crea nuevos commits con un contenido similar pero con valores hash diferentes”.

El tamaño del espacio de hashes es $2^{160}$, y la probabilidad $P$ de que ocurra una colisión (que diferentes commits tengan el mismo valor hash) se puede aproximar utilizando la teoría de la paradoja del cumpleaños (Birthday Paradox) (donde $n$ es el número de commits):

$$ P(\text{colisión}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

Esta probabilidad es extremadamente baja, por lo que en la práctica es casi imposible que los hashes de los commits de Git colisionen.

3. Teoría de grafos y DAG: Modelo matemático del historial de Git

El historial de commits de Git se modela como un “Grafo Dirigido Acíclico (Directed Acyclic Graph, DAG)” en la teoría de grafos.

3.1 ¿Qué es un DAG (Grafo Dirigido Acíclico)?

En un grafo $G = (V, E)$, $V$ es el conjunto de commits (vértices), y $E$ es el conjunto de aristas dirigidas que indican la relación padre-hijo entre los commits. En Git, la dirección de la arista va “del commit hijo al commit padre”. Esto se debe a que un nuevo commit mantiene un puntero a los commits pasados.

graph BT
A["Commit A (Inicial)"]
B["Commit B"]
C["Commit C (Principal)"]
D["Commit D (Característica)"]
E["Commit E (Fusión)"]
B --> A
C --> B
D --> B
E --> C
E --> D

La característica principal de un DAG es que “no existen ciclos”. Gracias a esto, los algoritmos que retroceden en el historial de commits no caen en bucles infinitos y pueden llegar con seguridad al final (el commit inicial).

3.2 Ordenación topológica y orden del historial

Cuando se muestra el historial con comandos como git log de Git, el DAG se ordena como una lista unidimensional mediante el algoritmo de ordenación topológica (Topological Sort). Para cualquier arista dirigida $u \to v$ en el DAG ($u$ es hijo de $v$), se reordenan para que $u$ aparezca antes que $v$ en la lista.

4. Mecanismos y tipos de git merge

El comando más básico para integrar cambios de ramas es git merge. Sin embargo, Git selecciona automáticamente diferentes estrategias de fusión según el estado actual.

4.1 Fusión Fast-Forward (–ff)

Si la rama de destino de la integración (ej: main) es un ancestro directo de la rama de origen (ej: feature), Git ejecuta una fusión “Fast-Forward (avance rápido)”. Es una operación que no crea un nuevo commit, sino que simplemente avanza el puntero de la rama.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

La fusión Fast-Forward mantiene el historial lineal, pero tiene la desventaja de que se pierde el contexto de “qué grupo de commits se agruparon como el desarrollo de una sola característica (feature)”.

4.2 Fusión Non-Fast-Forward (–no-ff)

Si se especifica explícitamente git merge --no-ff, siempre se creará un nuevo “commit de fusión (merge commit)”, incluso en situaciones donde es posible hacer un Fast-Forward. Un commit de fusión es un commit especial que tiene dos padres.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Trabajo Principal 1"
merge feature type: NORMAL

La ventaja de este método es que la existencia y la historia de la rama de la característica quedan claramente registradas en el DAG. Cuando ocurre un problema, al ejecutar git revert -m 1 <hash del commit de fusión>, es posible deshacer (revertir) de forma segura toda la característica a la vez.

4.3 Algoritmo de fusión de 3 vías (3-Way Merge)

Cuando las ramas de destino y origen tienen sus propios commits únicos, Git ejecuta una fusión de 3 vías. En este momento, Git explora el DAG y encuentra el “ancestro común más bajo (Lowest Common Ancestor, LCA)” de las dos ramas.

La complejidad temporal $T_{\text{LCA}}$ del algoritmo para encontrar el LCA se puede ejecutar en tiempo lineal con respecto al número de vértices $|V|$ y aristas $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git compara 3 estados: “el estado del LCA”, “el estado de la rama actual” y “el estado de la otra rama”, y si los cambios no entran en conflicto, genera automáticamente un commit de fusión.

5. Mecanismo de git rebase y reconstrucción del historial

Mientras que git merge “integra” el historial, git rebase “reconstruye (reemplaza)” el historial.

5.1 Los movimientos detrás de Rebase

El comportamiento interno al hacer rebase de la rama feature a la rama main (git rebase main) es el siguiente:

Encontrar el ancestro común (LCA) entre la rama feature y la rama main.
Guardar las diferencias de los commits desde el LCA hasta la punta de la rama feature en un área temporal.
Mover el puntero de la rama feature a la punta de la rama main.
Aplicar (Cherry-Pick) secuencialmente las diferencias guardadas sobre la nueva base (la punta de main), una por una, y generar nuevos commits.

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (Principal)"]
B --> D["Commit D (Característica Antigua)"]
D -.-> E["Commit D' (Nueva Característica)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

Lo importante aquí es que el commit $D'$ generado por el rebase tiene un commit padre diferente al del commit original $D$, por lo que tiene un valor hash completamente distinto (consulta la definición de la función hash $H(C)$ mencionada anteriormente).

5.2 Rebase Interactivo (Interactive Rebase)

El uso de git rebase -i (o --interactive) permite manipular el historial de commits a tu antojo. Esta es la herramienta más poderosa para organizar el historial local.

pick : Utiliza el commit tal cual
reword : Modifica solo el mensaje del commit
edit : Pausa para modificar el contenido del commit
squash : Fusiona este commit con el commit anterior y combina sus mensajes
fixup : Igual que squash, pero descarta el mensaje de este commit
drop : Elimina el commit por completo

Desde un punto de vista matemático, si una rama tiene $N$ commits, el número de variaciones (permutaciones) del historial lineal que se pueden generar reordenando el rebase, $P$, es:

$$ P = N! $$

Git otorga a los desarrolladores la libertad de $N!$ formas, lo que permite mantener el historial en un estado lógico y hermoso.

6. La regla de oro del Rebase (The Golden Rule of Rebase)

Aunque rebase es extremadamente poderoso, existe una regla absoluta.

“Nunca debes hacer rebase en historiales públicos que ya se han compartido” (Never rebase public history)

6.1 ¿Por qué no debes hacer rebase en el historial público?

Git es distribuido. Los commits que has empujado (push) a origin/main también han sido clonados (duplicados) en los repositorios locales de otros desarrolladores. Si reescribes el historial haciendo rebase a commits que ya han sido empujados y los sobrescribes forzadamente con git push --force, ¿qué pasará?

El DAG local de otros desarrolladores y el DAG remoto se bifurcarán fundamentalmente. Cuando otros desarrolladores ejecuten git pull, Git intentará fusionar por la fuerza grupos de commits con historias diferentes, lo que causará una gran cantidad de conflictos y commits duplicados (mismos cambios pero con diferentes hashes), sumiendo el repositorio en el caos.

La regla de oro es hacer rebase “solo en ramas locales que aún no se han compartido con nadie”.

7. Resolución de conflictos y git rebase –continue

Si varias personas modifican la misma parte del mismo archivo, se producirá un conflicto. El proceso de resolución de conflictos es diferente entre merge y rebase.

7.1 Resolución de conflictos en Merge

En el caso de git merge, la resolución del conflicto ocurre solo una vez. Justo antes de crear el commit de fusión final, se corrigen todos los conflictos a la vez.

7.2 Resolución de conflictos en Rebase

En el caso de git rebase, debido a su naturaleza de reaplicar los commits uno por uno, pueden ocurrir conflictos en cada commit.

Cuando ocurre un conflicto durante el rebase, Git pausa el proceso. El flujo de resolución es el siguiente:

Abre tu editor o IDE (como VS Code) y corrige manualmente los marcadores de conflicto (<<<<<<<, ======, >>>>>>>).
Agrega los archivos modificados al índice (index):
1

git add <archivo modificado>
Sin crear un commit, reanuda el proceso de rebase:
1

git rebase --continue

Si deseas cancelar el rebase por completo y volver al estado original, ejecuta el siguiente comando:

1

git rebase --abort

(※ Si no necesitas resolver un conflicto y quieres omitir ese commit en particular, usa git rebase --skip)

8. Uso correcto en la práctica (Práctica de flujo de trabajo)

Entonces, en un entorno de desarrollo real, ¿cómo deberíamos diferenciar el uso de merge y rebase? Aquí presentamos el enfoque más estándar y seguro.

8.1 【Escenario 1】 Organización del historial de trabajo local (Uso de Rebase)

Supongamos que durante el desarrollo en una rama de característica (feature), se han acumulado muchos commits pequeños (“corrección de error tipográfico”, “guardado temporal”, etc.). Antes de enviar un Pull Request (PR), usas un rebase interactivo para organizar estos en unidades significativas.

1
2
3


# Ejecutar estando en la rama feature
git rebase -i HEAD~5
# (Se abre el editor, usas squash y fixup para limpiar el historial)

Esto permite crear un historial de commits hermoso y donde la intención sea clara para los revisores.

8.2 【Escenario 2】 Seguimiento de la rama main más reciente (Uso de Rebase)

Si el desarrollo se alarga y los cambios de otras personas se siguen fusionando en la rama main, tu rama feature quedará desactualizada. En este caso, haces un rebase de tu rama feature sobre la última main para seguirla.

1
2
3
4
5


# Obtener la última información de main
git fetch origin

# Mover la rama feature a la cima del main más reciente
git rebase origin/main

Esto hace que el historial sea lineal y previene conflictos en fusiones posteriores. Además, evita que se generen commits de fusión innecesarios (“Merge branch ‘main’ into feature”).

8.3 【Escenario 3】 Integración de una característica completada (Uso de Merge)

El desarrollo en la rama feature ha terminado y finalmente es la fase de integración en la rama main. Aquí se usa git merge --no-ff (es equivalente a elegir “Create a merge commit” en un Pull Request en GitHub, etc.).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Implementación de la función de inicio de sesión de usuario"
git push origin main

De esta manera, en el DAG de la rama main queda un nodo en la historia (un commit de fusión) que indica “aquí se fusionó una característica completa”. Al mirar el historial más tarde, será más fácil seguir el código por unidad funcional.

9. Conclusión (Resumen)

En las operaciones de Git, los enfoques extremos como “resolver todo con Merge” o “hacer todo lineal con Rebase” tienen sus propias ventajas y desventajas.

La mejor práctica en el entorno laboral es un enfoque híbrido: “Organizar bellamente el historial privado local con rebase, y preservar el contexto en el historial público de integración con merge –no-ff”.

Local (Espacio de trabajo personal): Usar rebase para eliminar commits inútiles, seguir la línea principal más reciente y mantener un historial lineal.
Global (Espacio de trabajo compartido): Usar merge --no-ff para registrar la existencia de ramas de características como commits de fusión en el DAG, facilitando la reversión y el rastreo.

Al comprender los fundamentos arquitectónicos y matemáticos, como la estructura del DAG y el mecanismo de las funciones hash, los comandos de Git se elevan de la simple memorización al “diseño intencional del historial”. Siguiendo la regla de oro del rebase, seleccionemos el comando óptimo según la situación y construyamos un historial de commits limpio que sea fácil de leer y mantener para todo el equipo.

Colección de errores comunes y comandos de solución para principiantes de Git (resolución de conflictos, etc.)

Sat, 12 Sep 2026 17:00:00 +0900

Colección de errores comunes y comandos de solución para principiantes de Git (resolución de conflictos, etc.)

1. Introducción: ¿Por qué cometemos errores en Git?

En el desarrollo de software, Git se ha convertido en algo tan indispensable como el aire o el agua. Sin embargo, para muchos principiantes (y a veces incluso para los expertos), Git puede parecer una “caja negra mágica y aterradora”. Los commits desaparecen, subes un montón de cambios en la rama equivocada o mensajes de error de conflictos que nunca has visto antes llenan la pantalla… Cuando caes en estas “trampas de Git”, el progreso de tu trabajo se detiene por completo y, en el peor de los casos, te invade el miedo de haber destruido el código fuente.

¿Por qué Git es tan difícil y propenso a inducir errores? La razón principal es que “usamos comandos superficiales de memoria sin entender lo que está sucediendo dentro de Git”. Git se basa en una filosofía de diseño robusta como un Sistema de Control de Versiones Distribuido (DVCS), pero su interfaz (CLI) no siempre es intuitiva.

En este artículo, clasificaremos los “errores comunes” que los principiantes de Git encuentran frecuentemente en el trabajo en múltiples casos y proporcionaremos los comandos específicos para resolver cada uno de ellos. Sin embargo, no será una simple lista de comandos (hoja de trucos). Profundizaremos en “por qué ocurre ese error” y “cómo se mueven los datos dentro de Git cuando ejecutas ese comando” a lo largo de más de 10,000 caracteres, incluyendo la estructura del directorio .git, el trasfondo matemático del algoritmo Diff que se ejecuta en segundo plano y diagramas usando Mermaid.

Cuando termines de leer este artículo hasta el final, te liberarás del sentimiento de que “Git da miedo” y, en cambio, estarás seguro de que “no hay un compañero más confiable que Git”. Entonces, sumerjámonos en el profundo mundo de Git.

2. El abismo de Git: Entendiendo la estructura interna del directorio `.git`

El primer paso para facilitar la resolución de muchos problemas es saber cómo Git guarda los datos. La carpeta oculta .git que se encuentra en el directorio raíz de tu proyecto es el corazón de Git. Git no es un sistema que simplemente registra las diferencias (parches) de los archivos en orden, sino que gestiona los datos como un flujo de instantáneas (snapshots).

2.1 Modelo de objetos: Blob, Tree, Commit

Git utiliza principalmente 3 objetos para representar el estado del repositorio. Estos objetos se guardan en .git/objects.

Blob (Binary Large Object) Es el objeto que guarda el contenido del archivo en sí. La información como el nombre del archivo y los permisos no se incluyen aquí. Es puramente una secuencia de bytes comprimida con zlib y se identifica mediante un valor hash SHA-1 (un número hexadecimal de 40 caracteres).
Tree Es el objeto que representa la estructura del directorio. Un objeto Tree contiene punteros (valores hash SHA-1) a otros objetos Tree (subdirectorios) y objetos Blob (archivos), así como sus nombres de archivo y permisos de acceso. Desempeña un papel similar a un directorio de UNIX.
Commit Contiene un puntero al objeto Tree de nivel superior de todo el repositorio en un momento dado, metadatos (autor, fecha y hora del commit, mensaje del commit) y un puntero al commit inmediatamente anterior (commit padre).

graph TD
Commit1["Commit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 La verdadera naturaleza de HEAD y las referencias (Refs)

Al trabajar con Git, verás frecuentemente la palabra HEAD. Esto es una referencia simbólica (Symbolic Reference) que apunta a la rama (o commit) que tienes actualmente verificada (checked out). Si abres el archivo .git/HEAD con un editor de texto, verás una cadena como esta:

1

ref: refs/heads/main

Esto significa que “el estado actual se encuentra en la punta de la rama main”. Y si abres .git/refs/heads/main, verás escrito un hash SHA-1 de 40 caracteres, que apunta al objeto Commit más reciente. Una rama de Git es simplemente un puntero ligero (un archivo) que apunta a un commit específico. Solo con saber este hecho, el miedo de que “si elimino la rama, se borrarán todos los archivos” desaparece.

3. Descifrando Git con matemáticas: El algoritmo Diff y las funciones hash

Cuando Git detecta un conflicto o muestra la diferencia entre archivos, se están ejecutando algoritmos avanzados internamente.

3.1 Algoritmo Diff de Myers

El algoritmo de detección de diferencias predeterminado de Git es un algoritmo ideado por Eugene W. Myers. Cuando hay dos archivos de texto $A$ y $B$, el problema de encontrar la “secuencia mínima de ediciones (inserciones y eliminaciones)” para convertir $A$ en $B$ se puede modelar como un problema de la ruta más corta en la teoría de grafos.

Sean las longitudes de las cadenas $N$ y $M$ respectivamente, y la suma sea $V = N + M$. En el algoritmo de Myers, se busca la distancia de edición (Edit Distance) $D$. La complejidad temporal de este algoritmo se expresa con la siguiente fórmula:

$$ \mathcal{O}(V \cdot D) $$

Aquí, si la diferencia entre los archivos es pequeña (es decir, $D$ es pequeña), el algoritmo se ejecuta a una velocidad muy alta $\mathcal{O}(V)$. Sin embargo, si los archivos son completamente diferentes, $D \approx V$, y la complejidad temporal en el peor de los casos es $\mathcal{O}(V^2)$.

3.2 Patience Diff e Histogram Diff

El algoritmo de Myers es excelente, pero cuando se cambia significativamente el orden de funciones o clases, puede generar diferencias que no son intuitivas (no tienen sentido) para los humanos. Para solucionar esto, Git implementa Patience Diff e Histogram Diff.

Patience Diff se centra en las “líneas únicas que aparecen solo una vez en ambos archivos” y encuentra la subsecuencia común más larga (Longest Common Subsequence: LCS) de esas líneas. Si el número de elementos únicos es $U$, el cálculo de LCS se puede resolver con la siguiente complejidad computacional:

$$ \mathcal{O}(U \log U) $$

Cuando sientas que la resolución de un conflicto es difícil, una opción es usar git diff --histogram o especificar este algoritmo en la estrategia de fusión (git merge -s recursive -X histogram).

3.3 SHA-1 y la probabilidad de colisiones

Git gestiona todos los objetos con valores hash SHA-1. El tamaño del espacio hash es $2^{160}$. Si aproximamos la probabilidad de colisión de hash $p$ (que contenidos diferentes tengan el mismo valor hash) usando la paradoja del cumpleaños (Birthday Paradox), el número de objetos $k$ necesarios para que la probabilidad de colisión sea del 50% es el siguiente:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

Este es un número astronómico, y la probabilidad de que ocurra una colisión involuntaria en el desarrollo de software normal es prácticamente cero. Por lo tanto, Git funciona confiando en el valor hash como una “ID única absoluta”.

4. Estudio de caso 1: ¡He hecho un commit en la rama equivocada!

【Situación】 Sin darte cuenta de que estabas trabajando en la rama main, escribiste mucho código para una nueva función y, para colmo, hiciste un git commit. ¡Se suponía que debías crear una rama llamada feature/login y trabajar allí!

Solución: `git reset` y crear una rama

En Git, los commits son objetos independientes y las ramas son solo punteros. Por lo tanto, puedes resolver esto al instante con la operación de “crear una nueva rama y luego retroceder el puntero de la rama actual”.

1
2
3
4
5
6
7
8
9


# 1. Crear una nueva rama que apunte al commit actual (el commit hecho por error)
$ git branch feature/login

# 2. Retroceder el puntero de la rama main al commit anterior (HEAD~1)
# Usando --keep, puedes restablecer de forma segura manteniendo los cambios no confirmados (uncommitted) en el directorio de trabajo.
$ git reset --keep HEAD~1

# 3. Cambiar a la rama correcta
$ git checkout feature/login

Ilustración: ¿Qué pasó internamente?

Visualicemos el movimiento de los punteros de rama en este momento usando gitGraph de Mermaid.

gitGraph
commit id: "Initial commit"
commit id: "Bugfix"
commit id: "Mistaken Commit" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Al principio, main y HEAD apuntaban a “Mistaken Commit”, pero con git branch feature/login, se crea un nuevo puntero allí. Luego, con git reset, solo el puntero main vuelve a la posición “Bugfix”. No se ha eliminado ningún objeto en sí.

5. Estudio de caso 2: ¡Quiero deshacer un commit que ya ha sido empujado (pushed)!

【Situación】 Cometiste un código lleno de errores escrito durante la madrugada impulsado por la tensión y, además, lo publicaste en el repositorio remoto con git push origin main. Te das cuenta de un error crítico y palideces.

Solución 1: `git revert` para anular la historia (Recomendado y Seguro)

En el desarrollo en equipo, está estrictamente prohibido alterar el historial de commits ya empujados con comandos como git reset. Incoherencias surgirán con los repositorios locales de otros desarrolladores. El enfoque correcto es “crear un nuevo commit inverso que anule por completo los cambios del commit equivocado”. Esto es git revert.

1
2
3
4
5
6
7


# Crear un commit que anule el último commit
$ git revert HEAD
[main 7f3a8b2] Revert "Mensaje del commit equivocado"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Empujar al remoto
$ git push origin main

gitGraph
commit id: "Commit A"
commit id: "Commit B (Mistake)"
commit id: "Revert Commit B" type: REVERSE

La historia sigue avanzando y solo el estado del código vuelve a su estado anterior.

Solución 2: Alterar la historia con `git push --force-with-lease`

Si acabas de empujar a una rama que solo tú estás usando, alterar la historia es aceptable.

1
2
3
4
5
6
7


# Restablecer el commit localmente y arreglarlo
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# Sobrescribir forzadamente el historial del remoto
$ git push origin feature/login --force-with-lease

--force-with-lease es un push forzado seguro para evitar el accidente de sobrescribir el trabajo de otra persona por error.

6. Estudio de caso 3: Quiero cambiar a otra rama mientras trabajo (La magia de Stash)

【Situación】 Estás implementando una nueva función en la rama feature/A, pero el código fuente está a medias y ni siquiera compila. De repente, tu jefe te ordena: “¡Hay un error urgente en el entorno de producción en la rama main, arréglalo ahora mismo!”.

Solución: Guardar los cambios con `git stash`

git stash es un comando que guarda los cambios no confirmados (uncommitted) en un área temporal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Guardar los cambios en los que estás trabajando
$ git stash push -m "WIP: feature A partially implemented"

# 2. Ahora es posible cambiar a la rama main
$ git checkout main
# ... (Realizas el trabajo de corrección de errores urgentes, commit, push) ...

# 3. Volver a la rama original cuando termines
$ git checkout feature/A

# 4. Restaurar los cambios guardados
$ git stash pop

Cuando ejecutas git stash, Git crea internamente dos objetos de commit especiales y los guarda en una referencia llamada refs/stash. Es decir, al fin y al cabo, un Stash también es “un commit temporal sin nombre”.

7. Estudio de caso 4: El aterrador estado de “Detached HEAD”

【Situación】 Querías comprobar el código de un punto específico en el pasado y ejecutaste git checkout 9f8a7b6. Entonces apareció el mensaje You are in 'detached HEAD' state.. Hiciste un commit así sin más, pero cuando cambiaste de rama, ¡el commit desapareció!

El mecanismo de Detached HEAD

Normalmente, HEAD apunta a una rama como refs/heads/main. Sin embargo, si verificas (checkout) directamente un commit específico, HEAD apuntará directamente al objeto del commit. A esto se le llama Detached HEAD (HEAD separado o desprendido).

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C"]
C --> D["Commit D"]
BranchMain["Rama: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Incluso si apilas commits en este estado, ninguna rama seguirá esos nuevos commits. En el momento en que cambies a otra rama, los nuevos commits se perderán.

Solución: Guardar como una nueva rama

Se soluciona creando una nueva rama en el lugar donde te encuentras actualmente.

1
2


# Crear una nueva rama en la posición actual de HEAD y cambiar a ella
$ git checkout -b feature/recovered-work

8. Estudio de caso 5: Resolución de conflictos en Merge y Rebase

【Situación】 Ejecutaste git merge o git rebase y apareció el mensaje CONFLICT (content), y el proceso se interrumpió.

La diferencia entre Merge (Fusión) y Rebase (Reestructuración)

Merge (Fusión) Realiza una fusión a tres bandas (3-way merge) utilizando los últimos commits de las dos ramas y un ancestro común, creando un commit de fusión.
Rebase (Reestructuración) Guarda temporalmente los commits de la rama actual y los vuelve a aplicar en la punta del objetivo. La historia se vuelve lineal.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Método de resolución de conflictos

En los archivos donde ocurrió un conflicto, se insertan marcadores como los siguientes:

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

El procedimiento de resolución es extremadamente simple.

Eliminar los marcadores y corregir con el código correcto.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Añadir el archivo resuelto al área de preparación (staging). git add tiene el papel de “decirle a Git que has resuelto el conflicto”.
1

$ git add index.js

Completar el proceso.

1
2
3
4
5


# En el caso de merge
$ git commit -m "Resolve merge conflict in index.js"

# En el caso de rebase
$ git rebase --continue

Si entras en pánico, siempre puedes cancelar con $ git merge --abort o $ git rebase --abort.

9. Estudio de caso 6: ¡El historial de commits es un desastre! `git rebase -i`

【Situación】 Se han generado muchos commits pequeños como “Corrección de error tipográfico”, “Corrección de nuevo”, “Añadir prueba”, etc. Si fusionas a main tal como está, el historial se ensuciará.

Solución: Rebase interactivo

Al usar git rebase -i (interactive), puedes cambiar el orden de los commits pasados, combinar múltiples commits en uno (squash) o modificar el mensaje de un commit.

1
2


# Organizar los últimos 3 commits
$ git rebase -i HEAD~3

Se abrirá un editor y se mostrará lo siguiente:

1
2
3


pick 1a2b3c4 Corrección de error tipográfico
pick 2b3c4d5 Corrección de nuevo
pick 3c4d5e6 Añadir prueba

Lo reescribes de la siguiente manera:

1
2
3


pick 1a2b3c4 Implementación de la función X
squash 2b3c4d5 Corrección de nuevo
squash 3c4d5e6 Añadir prueba

Cuando lo guardes y cierres, estos 3 commits se integrarán hermosamente en uno solo.

10. Estudio de caso 7: ¡No sé cuándo se introdujo el error! `git bisect`

【Situación】 Hay un error en la rama main actual, pero todo era normal en el lanzamiento de hace un mes. Quieres identificar en qué commit se introdujo el error, ¡pero hay más de 100 commits y es imposible hacerlo manualmente!

Solución: Identificar el error mediante búsqueda binaria

Git tiene una herramienta incorporada para encontrar el commit donde se introdujo un error utilizando una búsqueda binaria matemática (Binary Search). La complejidad temporal es $\mathcal{O}(\log N)$, por lo que, aunque haya 1000 commits, se puede identificar con unas 10 pruebas.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Iniciar la búsqueda
$ git bisect start

# El commit actual tiene el error (bad)
$ git bisect bad

# Hace un mes (por ejemplo, el hash era a1b2c3d) era normal (good)
$ git bisect good a1b2c3d

# Git revisará (checkout) automáticamente el commit intermedio, así que ejecutas tu prueba
# Si la prueba es exitosa:
$ git bisect good
# Si la prueba falla:
$ git bisect bad

Simplemente repitiendo esto, Git te dirá exactamente “Este es el primer commit defectuoso (Bad commit)”. Cuando termines, vuelve al estado original con $ git bisect reset.

11. La red de seguridad definitiva: `git reflog`

La técnica final para cualquier “metedura de pata” en Git es git reflog. Git registra todo el historial de operaciones locales (historial de movimientos de HEAD) durante un período de tiempo determinado. Incluso si has borrado una rama o has hecho un restablecimiento (reset) incorrecto, puedes encontrar el hash pasado con git reflog y restaurarlo simplemente haciendo git reset --hard allí.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Conclusión

Hemos explicado con gran detalle los errores comunes en los que suelen caer los principiantes de Git, los mecanismos de Git detrás de ellos y cómo resolverlos. Commits en la rama equivocada, anular commits ya empujados, aprovechar Stash, sobrevivir a Detached HEAD y resolver conflictos. Lo importante en todo esto es imaginar “qué objetos y punteros está manipulando Git en segundo plano”.

La diferencia de los archivos se calcula mediante un riguroso algoritmo Diff expresado en fórmulas matemáticas, y la integridad de la historia está garantizada por funciones hash criptográficas. Si entiendes esta hermosa filosofía de diseño, te darás cuenta de que Git no es en absoluto una “caja negra incomprensible”, sino el escudo más fuerte para proteger firmemente tu código fuente.

La próxima vez que pienses “¡Metí la pata!”, en lugar de entrar en pánico y cerrar la terminal, respira hondo y escribe git status. Git siempre te ofrecerá pistas para la recuperación.

Version Control on kenji.blog

【Comandos Git】Diferencias entre rebase y merge, y su uso correcto en la práctica

1. Introducción: ¿Por qué “merge o rebase” es un dilema eterno?

2. Estructura interna de Git: Hashes de commits y modelo de objetos

2.1 Propiedades criptográficas de los hashes de los commits

3. Teoría de grafos y DAG: Modelo matemático del historial de Git

3.1 ¿Qué es un DAG (Grafo Dirigido Acíclico)?

3.2 Ordenación topológica y orden del historial

4. Mecanismos y tipos de git merge

4.1 Fusión Fast-Forward (–ff)

4.2 Fusión Non-Fast-Forward (–no-ff)

4.3 Algoritmo de fusión de 3 vías (3-Way Merge)

5. Mecanismo de git rebase y reconstrucción del historial

5.1 Los movimientos detrás de Rebase

5.2 Rebase Interactivo (Interactive Rebase)

6. La regla de oro del Rebase (The Golden Rule of Rebase)

6.1 ¿Por qué no debes hacer rebase en el historial público?

7. Resolución de conflictos y git rebase –continue

7.1 Resolución de conflictos en Merge

7.2 Resolución de conflictos en Rebase

8. Uso correcto en la práctica (Práctica de flujo de trabajo)

8.1 【Escenario 1】 Organización del historial de trabajo local (Uso de Rebase)

8.2 【Escenario 2】 Seguimiento de la rama main más reciente (Uso de Rebase)

8.3 【Escenario 3】 Integración de una característica completada (Uso de Merge)

9. Conclusión (Resumen)

Colección de errores comunes y comandos de solución para principiantes de Git (resolución de conflictos, etc.)

Colección de errores comunes y comandos de solución para principiantes de Git (resolución de conflictos, etc.)

1. Introducción: ¿Por qué cometemos errores en Git?

2. El abismo de Git: Entendiendo la estructura interna del directorio .git

2.1 Modelo de objetos: Blob, Tree, Commit

2.2 La verdadera naturaleza de HEAD y las referencias (Refs)

3. Descifrando Git con matemáticas: El algoritmo Diff y las funciones hash

3.1 Algoritmo Diff de Myers

3.2 Patience Diff e Histogram Diff

3.3 SHA-1 y la probabilidad de colisiones

4. Estudio de caso 1: ¡He hecho un commit en la rama equivocada!

Solución: git reset y crear una rama

Ilustración: ¿Qué pasó internamente?

5. Estudio de caso 2: ¡Quiero deshacer un commit que ya ha sido empujado (pushed)!

Solución 1: git revert para anular la historia (Recomendado y Seguro)

Solución 2: Alterar la historia con git push --force-with-lease

6. Estudio de caso 3: Quiero cambiar a otra rama mientras trabajo (La magia de Stash)

Solución: Guardar los cambios con git stash

7. Estudio de caso 4: El aterrador estado de “Detached HEAD”

El mecanismo de Detached HEAD

Solución: Guardar como una nueva rama

8. Estudio de caso 5: Resolución de conflictos en Merge y Rebase

La diferencia entre Merge (Fusión) y Rebase (Reestructuración)

Método de resolución de conflictos

9. Estudio de caso 6: ¡El historial de commits es un desastre! git rebase -i

Solución: Rebase interactivo

10. Estudio de caso 7: ¡No sé cuándo se introdujo el error! git bisect

Solución: Identificar el error mediante búsqueda binaria

11. La red de seguridad definitiva: git reflog

12. Conclusión

2. El abismo de Git: Entendiendo la estructura interna del directorio `.git`

Solución: `git reset` y crear una rama

Solución 1: `git revert` para anular la historia (Recomendado y Seguro)

Solución 2: Alterar la historia con `git push --force-with-lease`

Solución: Guardar los cambios con `git stash`

9. Estudio de caso 6: ¡El historial de commits es un desastre! `git rebase -i`

10. Estudio de caso 7: ¡No sé cuándo se introdujo el error! `git bisect`

11. La red de seguridad definitiva: `git reflog`