Conceptos básicos de Git: ramas, fusiones y solicitudes de extracción

Git realiza un seguimiento de instantáneas de su proyecto a lo largo del tiempo. Una rama es un puntero móvil a una confirmación. Fusión combina historiales (a menudo después de la revisión). Una solicitud de extracción (o solicitud de fusión) es la capa social: analice las diferencias, ejecute CI y luego integre. Esta lección conecta el modelo mental con las órdenes cotidianas.

Widgets en esta lección: git-graph muestra una topología real; úselo para ver por qué ocurren conflictos de fusión en la unión. Pipeline es la ruta de bytes desde su editor hasta el control remoto compartido. Explorador de código anota los comandos que escribirás diariamente. Tabla comparativa explica las compensaciones entre fusión y rebase. Código con pestañas contiene recetas para sincronización y recuperación.

Visual: rama de características y confirmación de fusión

Antes de los comandos, mire fijamente el gráfico: principal se movió de c1 → c2, luego función/inicio de sesión agregó c3 encima de c2. La fusión trajo c3 a principal como c4. Si dos personas editaran las mismas líneas desde c2, Git se detendría en la fusión con un marcador de conflicto; su trabajo es producir el archivo combinado correcto.

Del árbol de trabajo al remoto

Sus archivos se encuentran en el directorio de trabajo. `git add` coloca una instantánea en el índice (puesta en escena). `git commit` registra esa instantánea en el repositorio local. `git push` envía confirmaciones a un remoto (por ejemplo, origen) para que los compañeros de equipo puedan extraerlas.

Pasos del proceso: Editar es un caos sin compromiso; solo tú lo ves. Staging es la vista previa de la siguiente confirmación (`git diff --cached`). Commit congela el historial localmente (sin conexión). Push publica; Hasta entonces, las copias de seguridad y la CI no ven su trabajo. PR agrega revisión + verificaciones automatizadas antes de que la confirmación de fusión llegue a principal.

Anatomía de los comandos comunes.

Explorador de código: cada línea es un momento de enseñanza; haga clic en orden. Prefiera `git switch` para cambios de rama en el Git más nuevo; `checkout` todavía aparece en documentos más antiguos.

Fusionar vs rebase (cuando esté listo)

Ambos integran su función con main. Merge agrega una confirmación de fusión (como c4 en el gráfico). Rebase reproduce tus confirmaciones como nuevas confirmaciones además de la principal; el historial parece lineal pero reescribe los SHA. Nunca rebases las ramas públicas en las que los compañeros de equipo han basado el trabajo.

Utilice esta tabla cuando elija integrar una estrategia en entornos de relaciones públicas o localmente: fusionar preserva la verdad, rebase embellece la narrativa.

	Unir	Rebase
Gráfico histórico	Mantiene la burbuja de bifurcación y fusión: muestra honestamente el trabajo paralelo	Secuencia lineal: las confirmaciones de funciones aparecen después del último registro principal principal: git log --oneline
Colaboración	Seguro cuando varias personas tocan la misma rama: no se reescribe el historial	Peligroso si otros retiraran sus antiguos SHA: coordine o evite
Resolución de conflictos	Una resolución de conflicto de fusión en el momento de la fusión	Potencialmente un conflicto por confirmación repetida: más granular pero tedioso
Uso típico	Predeterminado GitHub/GitLab "Crear confirmación de fusión"	git pull --rebase antes de empujar; rebase interactivo para aplastar reparaciones

Lista de verificación de solicitud de extracción

Actualizar rama de funciones desde principal

bash

git fetch origin
git checkout feature/login
git merge origin/main
# or: git rebase origin/main

Práctica: cree un repositorio de prueba en GitHub/GitLab, abra dos clones, simule dos desarrolladores y resuelva un conflicto de fusión deliberado; nada enseña a Git como la resolución real de conflictos.

Antes de pedir una revisión