# 🌿 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.