8.4 KiB
🌿 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).
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
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
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:
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:
git stash
Luego podrás recuperarlos con:
git stash pop
3️⃣ Ve a la rama principal
git checkout main
4️⃣ Descarga lo último del repositorio
git pull
Esto sincroniza tu proyecto local con el remoto.
5️⃣ Crea la nueva rama
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:
git checkout -b cliente-acme
Si más adelante empieza otro proyecto, para el cliente Globex:
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.
gitGraph
commit id: "main estable"
branch cliente-acme
branch cliente-globex
6️⃣ Verifica que estás en la nueva rama
git branch
La rama actual aparecerá marcada con un *.
📌 Ejemplo
main
* cliente-acme
cliente-globex
7️⃣ Trabaja normalmente y guarda cambios
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:
git add .
git commit -m "Ajusta colores y logo segun manual de marca de Acme"
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
git checkout main
9️⃣ Une la nueva funcionalidad a main
git merge cliente-acme
📌 Ejemplo del resultado
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
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:
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:
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
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:
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).
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:
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.
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.
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
git log --oneline
Ver diferencias de archivos
git diff
Salir del visor de git diff / git log
Presiona:
q
Ver todas las ramas, incluidas las remotas
git branch -a
Cambiar de una rama de cliente a otra rápidamente
git checkout cliente-globex
🎯 Resultado esperado
Tu flujo ideal, aplicado al caso de proyectos por cliente, debería verse así:
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.