Pulsa ESC para cerrar · Ctrl+K para abrir
Inicio › Software › CONTROL DE VERSIONES › Artículo

Git y GitHub en Equipo:
Guía Interactiva de Flujos Colaborativos con VS Code

Pedro Pagán Pallarés 01 Mar, 2026
Git GitHub VS Code Colaboración Ramas
Git y GitHub - Flujo colaborativo con VS Code

Elige cómo quieres seguir esta guía:

Escenario 0 de 6 completados

Conoce al equipo

En este tutorial, trabajaremos con un equipo de 3 desarrolladores que colaboran en un proyecto desde VS Code. Cada uno tiene su propio flujo pero todos comparten el repositorio en GitHub.

A
Ana Lead Developer
B
Bruno Backend Dev
C
Carlos Frontend Dev

1. Clonar y configurar el repositorio

Lo primero que hace cada miembro del equipo

Cada desarrollador clona el repositorio de GitHub a su máquina local y configura su identidad de Git. En VS Code, esto se puede hacer tanto desde el terminal integrado como desde la interfaz gráfica.

# Configurar identidad (solo la primera vez)
$ git config --global user.name "Ana García"
$ git config --global user.email "ana@empresa.com"

# Clonar el repositorio
$ git clone https://github.com/equipo/proyecto.git
$ cd proyecto
$ code .
Tip: Al ejecutar code . se abre VS Code directamente en la carpeta del proyecto.
  1. Ctrl+Shift+P → Escribir "Git: Clone" y Enter
  2. Pegar la URL del repositorio: https://github.com/equipo/proyecto.git
  3. Elegir la carpeta destino y confirmar
  4. VS Code preguntará si abrir el repositorio → Abrir
☁️ GitHub (remoto) git clone 💻 Local (tu PC) Cada desarrollador clona: 👩‍💻Ana → git clone 👨‍💻Bruno → git clone 👨‍💻Carlos → git clone

2. Crear ramas (branches)

Cada persona trabaja en su propia rama

Regla de oro: Nunca trabajes directamente en main. Cada nueva funcionalidad o corrección se desarrolla en una rama independiente. Así el trabajo de uno no interfiere con el de los demás.

📋
Issue / Tarea
Se asigna una tarea en GitHub Issues
🌿
Crear rama
Rama desde main con nombre descriptivo
💻
Desarrollar
Codificar y hacer commits
🚀
Push + PR
Subir y abrir Pull Request
# Ana crea una rama para el sistema de login
$ git checkout -b feature/login

# Bruno crea una rama para la API de datos
$ git checkout -b feature/api-datos

# Carlos crea una rama para el dashboard
$ git checkout -b feature/dashboard
Convención de nombres: Usa prefijos como feature/, bugfix/, hotfix/ para organizar tus ramas. Ejemplo: feature/login-oauth, bugfix/fix-header-overlap.
main feature/login (Ana) 👩‍💻 feature/api-datos (Bruno) 👨‍💻 merge merge
En VS Code: Puedes crear ramas desde la barra inferior (clic en el nombre de la rama actual) o con Ctrl+Shift+P → "Git: Create Branch".

3. Commit, Push y el flujo diario

El ciclo básico de trabajo con Git

El flujo diario de trabajo con Git consiste en: editar archivos → preparar cambios (stage) → confirmar (commit) → subir al remoto (push). En VS Code esto es extremadamente visual e intuitivo.

✏️
Editar
Modifica archivos
📂
Stage
git add
📸
Commit
git commit
⬆️
Push
git push
☁️
GitHub
Sincronizado
# Ver qué archivos han cambiado
$ git status

# Añadir archivos al staging area
$ git add src/login.js
$ git add . # o añadir TODO

# Crear un commit con mensaje descriptivo
$ git commit -m "feat: añadir formulario de login con validación"

# Subir al remoto (primera vez en esta rama)
$ git push -u origin feature/login

# Subir cambios siguientes (después de la primera vez)
$ git push
  1. Abrir el panel Source Control con Ctrl+Shift+G
  2. Los archivos modificados aparecen en "Changes". Hacer clic en + para añadirlos al staging
  3. Escribir el mensaje de commit en el campo de texto superior
  4. Pulsar ✓ Commit (o Ctrl+Enter)
  5. Clic en Sync Changes (o el icono ↑) para hacer push
Working Dir Archivos editados Staging Area git add Local Repo git commit Remote (GitHub) git push
Mensajes de commit: Usa Conventional Commits: feat:, fix:, docs:, refactor:, test:. Ayuda a automatizar changelogs y entender el historial.

4. Pull Requests y Code Review

La puerta de entrada a main

Cuando terminas tu trabajo en una rama, NO haces merge directamente. Abres un Pull Request (PR) en GitHub para que tus compañeros revisen el código antes de integrarlo en main.

  1. Push tu rama — git push -u origin feature/login
  2. Ir a GitHub — Aparece un banner amarillo "Compare & pull request" → clic
  3. Rellenar el PR — Título descriptivo, descripción de cambios, screenshots si es visual
  4. Asignar reviewers — Seleccionar compañeros de equipo para revisión
  5. Code Review — Los reviewers comentan, sugieren cambios, aprueban
  6. Merge — Si todo está aprobado, se hace merge a main
feature/login 🔀 Pull Request #12 "feat: sistema de login" 👀 Code Review Bruno revisa los cambios ✅ Approved → Merge main merge commit
En VS Code: Instala la extensión GitHub Pull Requests para gestionar PRs directamente desde el editor sin ir al navegador.

5. Resolución de conflictos

Cuando dos personas tocan el mismo archivo

Los conflictos ocurren cuando dos ramas modifican las mismas líneas del mismo archivo. Git no puede decidir cuál es correcta, así que te pide que lo resuelvas manualmente. ¡No te asustes! VS Code hace que esto sea muy visual y fácil.

👩‍💻 Ana (feature/login)
// config.js
const PORT = 3000;
const HOST = 'localhost';
👨‍💻 Bruno (feature/api-datos)
// config.js
const PORT = 8080;
const HOST = '0.0.0.0';

⬇️ Al intentar hacer merge, Git muestra esto:

<<<<<<< HEAD (tu rama) const PORT = 3000; const HOST = 'localhost'; ======= const PORT = 8080; const HOST = '0.0.0.0'; >>>>>>> feature/api-datos

Cómo resolver en VS Code:

  1. VS Code muestra los conflictos con colores y botones: Accept Current | Accept Incoming | Accept Both | Compare
  2. Elegir qué versión mantener, o editar manualmente para combinar ambas
  3. Eliminar los marcadores de conflicto (<<<, ===, >>>)
  4. Guardar el archivo → git add → git commit
# Después de resolver los conflictos manualmente:
$ git add config.js
$ git commit -m "fix: resolver conflicto en config.js (merge feature/api-datos)"
Nunca hagas esto: Borrar el código del otro sin consultarle. Los conflictos son para negociar, no para imponer. Habla con tu compañero/a si no tienes claro qué versión mantener.

6. Sincronizar con el equipo

git pull, fetch y rebase

Mientras trabajas en tu rama, tus compañeros pueden haber mergeado cambios a main. Es importante actualizar tu rama para no quedarte atrás y minimizar conflictos futuros.

# Traer cambios de main y hacer merge en tu rama
$ git checkout feature/login
$ git pull origin main
Crea un commit de merge que une ambas historias. El historial queda más "desordenado" pero es más seguro.
# Rebase: reescribir tu rama ENCIMA de main actualizado
$ git checkout feature/login
$ git fetch origin
$ git rebase origin/main
Cuidado con rebase: Reescribe el historial. Nunca hagas rebase de ramas que ya están compartidas con otros. Solo en ramas locales o ramas personales.
Merge (historial real) merge commit Rebase (historial lineal) rebased commits → Historial limpio, una sola línea

Simulador de Git — Practica aquí

Escribe comandos Git y observa qué ocurre. Prueba: git init, git branch, git status, git log, help

Bienvenido al simulador de Git interactivo.
Escribe 'help' para ver los comandos disponibles.

Cheat Sheet — Comandos esenciales

Configuración

git config --global user.name "Tu Nombre" git clone <url> Configura identidad y clona repositorios.

Ramas

git branch git checkout -b feature/nueva git switch main Listar, crear y cambiar de rama.

Flujo diario

git add . git commit -m "mensaje" git push Stage, commit y push al remoto.

Sincronización

git pull git fetch git rebase origin/main Traer cambios del equipo.

Inspección

git status git log --oneline --graph git diff Ver estado, historial y diferencias.

Deshacer

git restore <archivo> git reset HEAD~1 git stash Revertir cambios y guardar trabajo temporal.