755 lines
8.4 KiB
Markdown
755 lines
8.4 KiB
Markdown
# 🌿 Guía Completa para Crear y Manejar un Branch en Git
|
|
|
|
|
|
|
|
Romper `main` directamente sigue siendo una tradición muy popular en desarrollo de software.
|
|
|
|
Git existe precisamente para evitar ese tipo de tragedias.
|
|
|
|
|
|
|
|
En esta guía usaremos un caso real como hilo conductor: una agencia que lleva un **proyecto por cada cliente**, y necesita crear una rama nueva cada vez que empieza a trabajar en la funcionalidad de un cliente específico (por ejemplo, `cliente-acme`).
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "inicio"
|
|
|
|
commit id: "version estable"
|
|
|
|
branch cliente-acme
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "dashboard acme"
|
|
|
|
commit id: "ajustes acme"
|
|
|
|
checkout main
|
|
|
|
merge cliente-acme id: "merge acme a main"
|
|
|
|
branch cliente-globex
|
|
|
|
checkout cliente-globex
|
|
|
|
commit id: "reporte globex"
|
|
|
|
checkout main
|
|
|
|
merge cliente-globex id: "merge globex a main"
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 🗺️ Flujo general del proceso
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
flowchart TD
|
|
|
|
A[git status] --> B{Hay cambios sin guardar?}
|
|
|
|
B -- Si --> C[git add . + git commit]
|
|
|
|
B -- No --> D
|
|
|
|
C --> D[git checkout main]
|
|
|
|
D --> E[git pull]
|
|
|
|
E --> F["git checkout -b cliente-acme"]
|
|
|
|
F --> G[git branch para confirmar]
|
|
|
|
G --> H[Trabajar y hacer commits]
|
|
|
|
H --> I[git checkout main]
|
|
|
|
I --> J["git merge cliente-acme"]
|
|
|
|
J --> K[git push]
|
|
|
|
K --> L["git branch -d cliente-acme"]
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 1️⃣ Verifica el estado actual del proyecto
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git status
|
|
|
|
```
|
|
|
|
|
|
|
|
Esto te muestra:
|
|
|
|
|
|
|
|
- Archivos modificados
|
|
|
|
- Archivos en stage
|
|
|
|
- Archivos sin seguimiento
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 2️⃣ Guarda tus cambios importantes
|
|
|
|
|
|
|
|
Si tienes cambios importantes, crea un commit antes de crear el branch:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git add .
|
|
|
|
git commit -m "Version estable antes de nueva funcionalidad"
|
|
|
|
```
|
|
|
|
|
|
|
|
✅ Esto crea un punto seguro al cual regresar.
|
|
|
|
|
|
|
|
### 📦 Alternativa: usar stash
|
|
|
|
|
|
|
|
Si todavía no quieres hacer commit:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git stash
|
|
|
|
```
|
|
|
|
|
|
|
|
Luego podrás recuperarlos con:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git stash pop
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 3️⃣ Ve a la rama principal
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout main
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 4️⃣ Descarga lo último del repositorio
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git pull
|
|
|
|
```
|
|
|
|
|
|
|
|
Esto sincroniza tu proyecto local con el remoto.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 5️⃣ Crea la nueva rama
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout -b nombre-de-la-rama
|
|
|
|
```
|
|
|
|
|
|
|
|
### 📌 Ejemplo con proyecto por cliente
|
|
|
|
|
|
|
|
Supongamos que la agencia empieza a trabajar en el dashboard del cliente **Acme**:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout -b cliente-acme
|
|
|
|
```
|
|
|
|
|
|
|
|
Si más adelante empieza otro proyecto, para el cliente **Globex**:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout -b cliente-globex
|
|
|
|
```
|
|
|
|
|
|
|
|
De esta forma cada cliente tiene su propio espacio de trabajo aislado, sin afectar el código de los demás.
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main estable"
|
|
|
|
branch cliente-acme
|
|
|
|
branch cliente-globex
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 6️⃣ Verifica que estás en la nueva rama
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git branch
|
|
|
|
```
|
|
|
|
|
|
|
|
La rama actual aparecerá marcada con un `*`.
|
|
|
|
|
|
|
|
### 📌 Ejemplo
|
|
|
|
|
|
|
|
```text
|
|
|
|
main
|
|
|
|
* cliente-acme
|
|
|
|
cliente-globex
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 7️⃣ Trabaja normalmente y guarda cambios
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git add .
|
|
|
|
git commit -m "Agrega dashboard de ventas para Acme"
|
|
|
|
```
|
|
|
|
|
|
|
|
Puedes repetir este paso tantas veces como necesites mientras avanzas en el proyecto del cliente:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git add .
|
|
|
|
git commit -m "Ajusta colores y logo segun manual de marca de Acme"
|
|
|
|
```
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main estable"
|
|
|
|
branch cliente-acme
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "dashboard ventas"
|
|
|
|
commit id: "ajustes de marca"
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 8️⃣ Regresa a main cuando todo funcione
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout main
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 9️⃣ Une la nueva funcionalidad a main
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git merge cliente-acme
|
|
|
|
```
|
|
|
|
|
|
|
|
### 📌 Ejemplo del resultado
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main estable"
|
|
|
|
branch cliente-acme
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "dashboard ventas"
|
|
|
|
commit id: "ajustes de marca"
|
|
|
|
checkout main
|
|
|
|
merge cliente-acme id: "entrega a Acme lista"
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 🔟 Sube los cambios al repositorio remoto
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 1️⃣1️⃣ Elimina la rama si ya no la necesitas
|
|
|
|
|
|
|
|
Una vez que el trabajo del cliente ya fue entregado y fusionado a `main`, puedes borrar la rama para mantener el repositorio limpio:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git branch -d cliente-acme
|
|
|
|
```
|
|
|
|
|
|
|
|
Si Git no te deja borrarla porque detecta cambios sin fusionar, y estás seguro de que quieres eliminarla de todos modos:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git branch -D cliente-acme
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 🧠 Recomendaciones importantes
|
|
|
|
|
|
|
|
✅ Nunca trabajes directamente sobre `main`
|
|
|
|
✅ Haz commits pequeños y claros
|
|
|
|
✅ Usa nombres descriptivos para tus branches (por ejemplo, `cliente-acme`, no `rama1`)
|
|
|
|
✅ Verifica siempre con `git status` antes de cambiar de rama
|
|
|
|
✅ Si manejas varios clientes a la vez, mantén una rama por cliente para evitar mezclar entregas
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main"
|
|
|
|
branch cliente-acme
|
|
|
|
branch cliente-globex
|
|
|
|
branch cliente-initech
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "avance acme"
|
|
|
|
checkout cliente-globex
|
|
|
|
commit id: "avance globex"
|
|
|
|
checkout cliente-initech
|
|
|
|
commit id: "avance initech"
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## ❓ ¿Siempre hay que hacer merge a main?
|
|
|
|
|
|
|
|
No. El `merge` a `main` solo tiene sentido si `main` representa algo que **todos los clientes comparten**. Si los cambios son exclusivos de un cliente y no deben mezclarse con nada más, tienes otras opciones.
|
|
|
|
|
|
|
|
### Opción 1: La rama del cliente vive sola (sin merge a main)
|
|
|
|
|
|
|
|
Trabajas y subes esa rama directamente, sin tocar `main`:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout -b cliente-acme
|
|
|
|
# ... trabajas y haces commits ...
|
|
|
|
git push origin cliente-acme
|
|
|
|
```
|
|
|
|
|
|
|
|
`main` se queda intacto, y `cliente-acme` existe como una línea de desarrollo independiente para siempre (o hasta que ya no la necesites).
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main estable"
|
|
|
|
branch cliente-acme
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "dashboard acme"
|
|
|
|
commit id: "ajustes acme"
|
|
|
|
```
|
|
|
|
|
|
|
|
Aquí `cliente-acme` nunca se vuelve a juntar con `main`.
|
|
|
|
|
|
|
|
### Opción 2: main es solo una plantilla base
|
|
|
|
|
|
|
|
Si cada cliente parte de una base común (por ejemplo, la plantilla del proyecto), tiene sentido traer cambios **de main hacia el cliente** cuando la plantilla mejora, pero no al revés:
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout cliente-acme
|
|
|
|
git merge main
|
|
|
|
```
|
|
|
|
|
|
|
|
Esto trae las mejoras de la plantilla al proyecto del cliente. Es al revés del flujo normal: en vez de `cliente-acme → main`, es `main → cliente-acme`.
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "plantilla v1"
|
|
|
|
branch cliente-acme
|
|
|
|
checkout main
|
|
|
|
commit id: "plantilla v2 mejorada"
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "avance acme"
|
|
|
|
merge main id: "trae mejoras de plantilla"
|
|
|
|
```
|
|
|
|
|
|
|
|
### Opción 3: Cada cliente es su propio repositorio o deploy
|
|
|
|
|
|
|
|
Si el código de cada cliente es tan distinto que ni siquiera comparte historial útil con los demás, muchas agencias usan directamente **una rama por cliente que se despliega tal cual**, sin merges entre ellas. En este caso `main` queda solo como referencia general, o incluso no se usa en ese repo.
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
gitGraph
|
|
|
|
commit id: "main (referencia)"
|
|
|
|
branch cliente-acme
|
|
|
|
branch cliente-globex
|
|
|
|
checkout cliente-acme
|
|
|
|
commit id: "deploy acme"
|
|
|
|
checkout cliente-globex
|
|
|
|
commit id: "deploy globex"
|
|
|
|
```
|
|
|
|
|
|
|
|
> 💡 Elige la opción según qué tan relacionado esté el trabajo entre clientes: si comparten código base, usa la Opción 2; si son totalmente independientes, la Opción 1 o la Opción 3.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 🚨 Comandos útiles extra
|
|
|
|
|
|
|
|
### Ver historial de commits
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git log --oneline
|
|
|
|
```
|
|
|
|
|
|
|
|
### Ver diferencias de archivos
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git diff
|
|
|
|
```
|
|
|
|
|
|
|
|
### Salir del visor de git diff / git log
|
|
|
|
|
|
|
|
Presiona:
|
|
|
|
|
|
|
|
```text
|
|
|
|
q
|
|
|
|
```
|
|
|
|
|
|
|
|
### Ver todas las ramas, incluidas las remotas
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git branch -a
|
|
|
|
```
|
|
|
|
|
|
|
|
### Cambiar de una rama de cliente a otra rápidamente
|
|
|
|
|
|
|
|
```bash
|
|
|
|
git checkout cliente-globex
|
|
|
|
```
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## 🎯 Resultado esperado
|
|
|
|
|
|
|
|
Tu flujo ideal, aplicado al caso de proyectos por cliente, debería verse así:
|
|
|
|
|
|
|
|
```text
|
|
|
|
main
|
|
|
|
├── cliente-acme
|
|
|
|
│ └── commits del proyecto Acme
|
|
|
|
│ └── merge a main
|
|
|
|
├── cliente-globex
|
|
|
|
│ └── commits del proyecto Globex
|
|
|
|
│ └── merge a main
|
|
|
|
└── cliente-initech
|
|
|
|
└── commits del proyecto Initech
|
|
|
|
└── merge a main
|
|
|
|
```
|
|
|
|
|
|
|
|
Un proceso ordenado, con una rama independiente por cada cliente, y `main` siempre reflejando el estado estable y entregado del trabajo. |