Flujo de Trabajo Paso a Paso

Cada vez que tomes una tarea, sigue este ciclo:

1. Actualizar tu entorno local

git checkout dev
git pull origin dev

2. Crear tu rama de trabajo

git checkout -b feature/mi-nueva-tarea

3. Desarrollar y hacer commits

Commits atómicos y descriptivos. Un commit = un cambio lógico.

git add .
git commit -m "feat: añade validación al formulario de login"

4. Sincronizar con el trabajo de otros

Antes de subir, asegúrate de no tener conflictos:

git pull origin dev

5. Subir tu rama al remoto

git push origin feature/mi-nueva-tarea

6. Crear un Pull Request

En GitHub, abre un PR de tu rama feature/... hacia dev.

Pro-tips

• Commits semánticos: Usa prefijos (feat:, fix:, docs:, refactor:) para un historial limpio.
• Conflictos: Son normales. Git solo dice “los dos tocasteis esto, decide tú”. Habla con el compañero y elige la solución correcta.

---

Problema común: mi rama de feature “apunta a dev”

Qué está pasando

Algunas extensiones de Git en VS Code (como GitLens o la integración nativa de Source Control) pueden crear una rama nueva de forma que el upstream queda configurado como dev. Esto hace que, al hacer git push, Git intente empujar tus commits directamente a dev en lugar de a tu rama feature/....

Esto va en contra del flujo de trabajo porque nunca se debe hacer push directo a dev.

Cómo detectarlo

Ejecuta:

git branch -vv

Si ves algo como esto:

* feat/mi-rama                1234567 [dev] mensaje del último commit

Significa que tu rama local tiene configurado dev como upstream.

Cómo solucionarlo

Opción A: quitar el upstream incorrecto y empujar a tu propia rama

# Desvincular de dev
git branch --unset-upstream

# Empujar a tu propia rama en el remoto
git push origin feat/mi-rama

Opción B: cambiar el upstream a tu rama del remoto

git branch --set-upstream-to=origin/feat/mi-rama feat/mi-rama

Opción C: empujar explícitamente indicando origen y destino

git push origin feat/mi-rama:feat/mi-rama

Cómo evitarlo al crear ramas

Cuando crees una nueva rama, hazlo explícitamente desde la terminal:

git checkout dev
git pull origin dev
git checkout -b feature/mi-nueva-tarea

Y luego empuja siempre con:

git push -u origin feature/mi-nueva-tarea

La opción -u (o --set-upstream) configura el upstream correcto a tu propia rama, no a dev.

Restringir push directo a dev en GitHub

Para evitar que esto ocurra por error, configura un ruleset en GitHub. La interfaz actual usa Rulesets en lugar de la antigua “Branch protection rules”:

1. Ve al repositorio en GitHub.
2. Abre Settings → Rules → Rulesets.
3. Haz clic en New branch ruleset.
4. En Ruleset Name, escribe un nombre descriptivo, por ejemplo: PR required to dev.
5. En Enforcement status, deja Active.
6. En Bypass list, deja vacío salvo que quieras permitir a ciertos usuarios o roles saltarse las reglas (normalmente nadie).
7. En Target branches, haz clic en Add target y configura:
   • Include by pattern: escribe dev.
   • También puedes añadir main si quieres proteger ambas.
8. En Rules, activa al menos:
   • Restrict deletions
   • Require pull request before merging
   • Require approvals (al menos 1)
   • Block force pushes
   • Restrict who can push to matching branches
     • Añade solo a los administradores o al equipo que deba poder hacer push directo en casos excepcionales.
9. Guarda los cambios con Create.

Con este ruleset activo, incluso si alguien intenta hacer git push origin dev, GitHub rechazará la operación.

Comando para verificar tu configuración actual

git remote show origin

Esto muestra las ramas locales, sus upstreams y las ramas del remoto.