Tutorial de Git desde Cero: Comandos, Ramas y GitHub Paso a Paso

Tu carpeta del proyecto final tiene archivos como informe_v2.docx, informe_v2_FINAL.docx y informe_v2_FINAL_ahora_si.docx. Ya no sabes cuál es el bueno, y el cambio que hiciste el martes desapareció cuando tu compañero te mandó “su versión”.

Así trabajaba casi todo el mundo antes de Git. Hoy es la herramienta que usan desde estudiantes hasta los equipos que mantienen Linux, Android o Visual Studio Code.

En este tutorial de Git desde cero vas a instalarlo, crear tu primer repositorio, trabajar con ramas, resolver un conflicto, subir tu proyecto a GitHub y, sobre todo, deshacer errores sin perder nada. Abre una terminal y escribe los comandos conmigo.

---

¿Qué Es Git y Por Qué Lo Usan Casi Todos los Equipos de Desarrollo?

Git es un sistema de control de versiones distribuido. Guarda fotografías (commits) del estado de tu proyecto, y puedes volver a cualquiera de ellas cuando quieras. Lo creó Linus Torvalds en 2005 para coordinar el desarrollo del kernel de Linux.

“Distribuido” significa que cada persona tiene una copia completa del historial en su computadora. Puedes trabajar sin internet, crear ramas para experimentar y sincronizar con tu equipo solo cuando estés listo.

Git No Es GitHub: La Diferencia en 30 Segundos

Es la confusión número uno de quien empieza. Git es el programa que instalas; GitHub es un servicio web donde guardas una copia de tus repositorios para colaborar.

Herramienta	Qué es	Para qué la usas
Git	Programa de control de versiones (libre y gratuito)	Registrar cambios, crear ramas y deshacer errores en tu equipo
GitHub	Plataforma web de Microsoft	Alojar repositorios, revisar código con pull requests y publicar portafolios
GitLab	Plataforma web, también instalable en servidores propios	Lo mismo que GitHub, con CI/CD muy integrado
Bitbucket	Plataforma web de Atlassian	Equipos que ya usan Jira y otras herramientas de Atlassian

Puedes usar Git toda la vida sin abrir GitHub. Pero GitHub sin Git no tiene sentido.

---

¿Cómo Instalar Git en Windows, macOS y Linux?

La instalación toma un par de minutos. Elige tu sistema:

# Windows: instalador oficial (incluye Git Bash) desde https://git-scm.com
# o, desde PowerShell, con el gestor de paquetes winget:
winget install --id Git.Git -e

# macOS: instala las herramientas de línea de comandos de Xcode...
xcode-select --install
# ...o usa Homebrew
brew install git

# Ubuntu / Debian
sudo apt update && sudo apt install git

# Fedora
sudo dnf install git

Comprueba que quedó instalado con git --version. Si ves algo como git version 2.x, estás listo.

Consejo para Windows: el instalador de Git for Windows trae Git Bash, una terminal con los mismos comandos que en Linux y macOS. Si sigues tutoriales en inglés o cursos online, te ahorrará muchas diferencias de sintaxis.

Configuración Inicial: Nombre, Correo y Rama Principal

Git firma cada commit con tu nombre y correo. Configúralos una sola vez:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

# Llama "main" a la rama principal de los repositorios nuevos (Git 2.28 o superior)
git config --global init.defaultBranch main

# Opcional: usa VS Code para escribir mensajes largos
git config --global core.editor "code --wait"

# Revisa tu configuración
git config --list

Usa el mismo correo que registres en GitHub. Así tus commits aparecerán vinculados a tu perfil.

---

Las Zonas de Git: Directorio de Trabajo, Staging y Repositorios

Antes de escribir comandos, entiende dónde “vive” tu código. Esta idea evita la mayoría de las confusiones del principio.

• Directorio de trabajo: los archivos que ves y editas en tu carpeta.
• Área de preparación (staging): una “sala de espera” donde eliges qué cambios entrarán en el próximo commit.
• Repositorio local: el historial de commits, guardado en la carpeta oculta .git.
• Repositorio remoto: una copia en GitHub u otro servidor, para compartir y respaldar.

¿Por qué existe el staging? Porque te permite hacer commits pequeños y con sentido. Si cambiaste tres archivos por motivos distintos, puedes guardarlos en tres commits separados.

---

Tu Primer Repositorio Git Paso a Paso

Crear el Repositorio con git init

mkdir mi-proyecto
cd mi-proyecto
git init

Git responde Initialized empty Git repository in .../mi-proyecto/.git/. Esa carpeta .git es tu historial: no la borres ni la edites a mano.

Git Add, Commit y Log: El Ciclo Básico de Trabajo

Crea un archivo y observa cómo Git lo detecta:

echo "# Mi proyecto" > README.md
git status

git status lo mostrará en rojo como untracked (sin seguimiento). Pásalo al staging y haz tu primer commit:

git add README.md          # un archivo concreto
git add .                  # o todos los cambios de la carpeta

git commit -m "Agrega README inicial"

git log --oneline          # historial compacto
# a1b2c3d Agrega README inicial

Ese es el ciclo que repetirás cientos de veces: editar → git add → git commit. Usa git status constantemente; es tu mapa.

Para ver qué cambió exactamente antes de guardar, usa git diff (cambios sin preparar) o git diff --staged (cambios ya en staging).

¿Cómo Escribir Buenos Mensajes de Commit?

Dentro de seis meses, tus mensajes de commit serán la única explicación de por qué cambió el código. Escríbelos para tu yo del futuro:

Evita	Prefiere
cambios	Corrige el cálculo del IVA en el carrito
arreglos varios	Valida el correo antes de enviar el formulario
asdf	Agrega botón para descargar el informe en PDF
final final 2	Actualiza dependencias de seguridad

La convención más extendida: un verbo en imperativo, una sola idea por commit y menos de unos 50 caracteres en la primera línea.

Ignorar Archivos con .gitignore

Hay archivos que nunca deben entrar al repositorio: dependencias descargadas, archivos generados y, sobre todo, contraseñas y claves de API. Crea un archivo .gitignore en la raíz:

node_modules/
dist/
.env
*.log
.DS_Store

Git ignorará todo lo que coincida con esos patrones. GitHub mantiene plantillas de .gitignore para casi cualquier lenguaje.

---

Ramas en Git: Crear, Cambiar y Fusionar Branches

Una rama es una línea de trabajo independiente. Te permite probar una idea sin tocar el código que ya funciona en main.

# Crear una rama y cambiarte a ella
git switch -c feature/formulario-contacto

# ...editas, haces add y commit en la rama...

# Volver a la rama principal
git switch main

# Traer los cambios de la rama a main
git merge feature/formulario-contacto

# Borrar la rama cuando ya no la necesitas
git branch -d feature/formulario-contacto

En tutoriales antiguos verás git checkout -b en lugar de git switch -c. Hacen lo mismo; git switch existe desde Git 2.23 y es más fácil de recordar porque solo sirve para cambiar de rama.

¿Qué Hacer Cuando Aparece un Conflicto de Merge?

Un conflicto ocurre cuando dos ramas modificaron la misma línea de forma distinta. Git no adivina cuál es la correcta y te pide que decidas. El archivo quedará así:

<<<<<<< HEAD
<h1>Bienvenido a mi portafolio</h1>
=======
<h1>Hola, soy desarrolladora web</h1>
>>>>>>> feature/nuevo-titulo

Para resolverlo:

1. Abre el archivo y decide qué texto queda (uno, otro o una mezcla).
2. Borra las marcas <<<<<<<, ======= y >>>>>>>.
3. Guarda el archivo y ejecuta git add archivo.html.
4. Termina con git commit.

Tranquilidad ante todo: un conflicto no es un error ni rompe nada. Si te asustas a mitad de camino, git merge --abort deja todo como estaba antes del merge.

---

¿Cómo Subir tu Proyecto a GitHub?

Crea un repositorio vacío en GitHub (sin README, para evitar conflictos con el tuyo) y copia su URL. Luego conecta tu repositorio local:

git remote add origin https://github.com/tu-usuario/mi-proyecto.git
git push -u origin main

El -u deja recordada la conexión; a partir de ahí basta con git push. Para traer los cambios que otras personas subieron, usa git pull. Para descargar un repositorio existente desde cero, git clone URL.

Sobre la autenticación: GitHub no acepta la contraseña de tu cuenta para operaciones de Git por HTTPS. Tienes tres opciones:

• Git Credential Manager, incluido en Git for Windows: abre el navegador para que inicies sesión.
• GitHub CLI (gh auth login): configura el acceso en un par de pasos.
• Claves SSH: la opción favorita de quienes trabajan a diario con varios repositorios.

Flujo de Trabajo Profesional con Pull Requests

En equipos, casi nadie hace commits directos en main. El flujo habitual es:

1. Crear una rama desde main actualizado (git pull antes).
2. Hacer commits pequeños y descriptivos.
3. Subir la rama con git push -u origin nombre-rama.
4. Abrir un pull request en GitHub para que alguien revise el código.
5. Aplicar los cambios que pidan en la revisión.
6. Fusionar en main y borrar la rama.

Aunque trabajes solo, este flujo te sirve: los pull requests dejan documentado por qué hiciste cada cambio, y lucen muy bien en un portafolio.

---

¿Cómo Deshacer Cambios en Git sin Perder Trabajo?

Aquí es donde Git demuestra su valor. Elige el comando según tu situación:

Situación	Comando
Quiero descartar lo que cambié en un archivo (sin commit)	git restore archivo.js
Agregué un archivo al staging por error	git restore --staged archivo.js
Me equivoqué en el mensaje del último commit (sin push)	git commit --amend -m "Mensaje correcto"
Quiero deshacer el último commit pero conservar los cambios	git reset --soft HEAD~1
Quiero revertir un commit que ya subí a GitHub	git revert a1b2c3d
Necesito guardar cambios a medias para cambiar de rama	git stash y luego git stash pop
Quiero saber quién cambió una línea y cuándo	git blame archivo.js

Advertencia: git reset --hard borra cambios sin preguntar, y reescribir commits que ya compartiste (con reset o --amend seguidos de push --force) rompe el historial de tus compañeros. Si el commit ya está en GitHub, usa git revert: crea un commit nuevo que deshace el anterior sin reescribir nada.

¿Borraste algo y crees que lo perdiste? Prueba git reflog. Muestra todos los movimientos recientes de tu repositorio, incluso los commits que “desaparecieron”, y casi siempre permite recuperarlos.

---

Errores Comunes y Límites de Git que Conviene Conocer

Git es potente, pero no hace magia. Estos son los tropiezos y limitaciones más frecuentes:

• Subir secretos por accidente. Si una clave de API llega a un commit, queda en el historial aunque luego borres el archivo. Revoca la clave de inmediato y usa .gitignore desde el primer día.
• Git no es un respaldo por sí solo. Tu historial vive en tu disco; si se daña y nunca hiciste push, lo pierdes todo.
• No está pensado para archivos binarios grandes. Videos, datasets o modelos de varios gigas hinchan el repositorio. Para eso existe Git LFS (Large File Storage).
• Commits gigantes. Un commit con 40 archivos y el mensaje “avances” es imposible de revisar o revertir. Mejor varios pequeños.
• La curva de aprendizaje es real. Los primeros días confunde; a las dos semanas de uso diario, el ciclo add → commit → push se vuelve automático.

Si trabajas con microcontroladores, Git combina muy bien con simuladores como Wokwi, que se integra con VS Code: puedes versionar tu código de Arduino o ESP32 igual que cualquier proyecto web.

---

Próximos Pasos para Dominar Git y GitHub

Con lo que acabas de practicar ya cubres el 90 % del uso diario de Git: crear repositorios, hacer commits con sentido, trabajar en ramas, resolver conflictos, colaborar en GitHub y recuperarte de los errores.

Para profundizar, el libro Pro Git es gratuito, está en español y es la referencia oficial. Y si buscas proyectos para practicar, los cursos de freeCodeCamp te dan ejercicios ideales para versionar desde el primer día.

Tu reto para hoy: crea un repositorio con tu próximo proyecto, haz al menos tres commits con buenos mensajes y súbelo a GitHub. ¿Qué comando de Git te costó más entender? Cuéntanos en los comentarios.