Git y GitHub desde Cero: La Guía que Todo Junior Debería Leer Antes de su Primera Entrevista

Hay una pregunta que aparece en casi todas las entrevistas de trabajo para programadores junior, sin importar la empresa, el lenguaje o el tipo de puesto:

"¿Has trabajado con Git y GitHub?"

Y hay dos tipos de candidatos: los que responden con seguridad y lo demuestran con un perfil de GitHub activo, y los que dicen "sí" con voz temblorosa y rezan para que no profundicen más.

Este artículo es para que no seas el segundo tipo. Vamos a ver qué es Git, cómo funciona, los comandos que necesitas dominar sí o sí, cómo trabajar con GitHub en un equipo real y, al final, cómo tener un perfil de GitHub que impresione a cualquier reclutador técnico.

Sin rodeos, sin relleno. Solo lo que de verdad necesitas saber antes de tu primera entrevista.

¿Qué es Git y por qué todo programador lo necesita?

Git es un sistema de control de versiones distribuido. En palabras humanas: es una herramienta que registra todos los cambios que haces en tu código a lo largo del tiempo, permitiéndote volver a cualquier versión anterior, trabajar en paralelo con otros desarrolladores sin pisaros el trabajo y mantener un historial completo de quién cambió qué y cuándo.

Imagina que estás escribiendo una novela y cada día guardas una copia con el nombre "novela_final.docx", "novela_final_v2.docx", "novela_ESTA_SÍ.docx". Git es la solución elegante a ese caos. Guarda automáticamente cada versión de tu trabajo con una descripción de qué cambió, cuándo y por qué.

Sin Git, trabajar en equipo en un proyecto de software es prácticamente inviable. Por eso no existe empresa de desarrollo que no use Git. Es una herramienta no negociable en el mercado laboral.

¿Y GitHub qué es? ¿Es lo mismo que Git?

No, y confundirlos es uno de los errores más comunes. La diferencia es clara:

• Git es la herramienta. Se instala en tu ordenador y funciona localmente, sin internet.
• GitHub es una plataforma web que aloja repositorios Git en la nube, añade funcionalidades de colaboración (pull requests, issues, code review) y actúa como red social para desarrolladores.

Existen alternativas a GitHub como GitLab o Bitbucket, pero GitHub es con diferencia la más usada y la más relevante para tu portfolio como junior.

Cómo instalar y configurar Git por primera vez

Antes de escribir ningún comando, necesitas tener Git instalado y configurado con tu identidad. Esto es lo primero que debes hacer:

Instalación

• Windows: descarga el instalador desde git-scm.com. Durante la instalación, deja las opciones por defecto.
• macOS: escribe git --version en la terminal. Si no está instalado, el sistema te ofrecerá instalarlo automáticamente. También puedes usar Homebrew: brew install git.
• Linux (Ubuntu/Debian): sudo apt install git

Configuración inicial (obligatoria)

Una vez instalado, abre la terminal y ejecuta estos dos comandos. Son imprescindibles porque Git los usa para identificar quién hace cada cambio:

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

Usa el mismo email que usas en GitHub. Así los commits aparecerán correctamente vinculados a tu perfil.

Conceptos fundamentales que debes entender antes de los comandos

Mucha gente memoriza comandos de Git sin entender qué hacen por debajo. El resultado es que cuando algo sale mal (y saldrá), no saben cómo arreglarlo. Estos son los conceptos que tienes que tener claros:

Repositorio (repo)

Es la carpeta de tu proyecto gestionada por Git. Contiene todos los archivos de tu proyecto más la carpeta oculta .git, donde Git almacena todo el historial de cambios. Hay dos tipos: repositorio local (en tu ordenador) y repositorio remoto (en GitHub).

Commit

Un commit es una fotografía del estado de tu proyecto en un momento concreto. Cada commit tiene un identificador único (hash), un autor, una fecha y un mensaje que describe qué cambió. El historial de tu proyecto es básicamente una secuencia de commits.

Branch (rama)

Una rama es una línea de desarrollo independiente. La rama principal se llama main (antes era master). Cuando quieres desarrollar una nueva funcionalidad o corregir un error, creas una rama nueva para trabajar sin afectar al código principal. Cuando terminas, fusionas (merge) esa rama con main.

Staging area (área de preparación)

Es una zona intermedia entre tus archivos modificados y el commit. Antes de hacer un commit, decides exactamente qué cambios quieres incluir usando git add. Esto te permite hacer commits precisos, no guardar todos los cambios a ciegas.

El flujo de trabajo básico de Git

Así se ve el ciclo normal de trabajo con Git:

1. Modificas archivos en tu directorio de trabajo.
2. Seleccionas los cambios que quieres guardar con git add → pasan al staging area.
3. Confirmas esos cambios con git commit → quedan guardados en el historial local.
4. Subes los cambios al repositorio remoto con git push → ya están en GitHub.

Los comandos Git que debes dominar antes de tu entrevista

No necesitas memorizar los 200+ comandos que tiene Git. Necesitas dominar los que se usan el 95% del tiempo en el trabajo real. Estos son:

Iniciar y clonar repositorios

# Inicializar un repositorio Git en una carpeta existente git init 

# Clonar un repositorio remoto en tu ordenador git clone https://github.com/usuario/repositorio.git

Ver el estado y el historial

# Ver qué archivos han cambiado y cuáles están en staging git status 

# Ver el historial de commits git log 

# Ver el historial de forma compacta (muy útil) git log --oneline 

# Ver los cambios concretos en los archivos git diff

Guardar cambios (add y commit)

# Añadir un archivo específico al staging area git add nombre-archivo.txt 

# Añadir todos los archivos modificados git add . 

# Hacer un commit con mensaje descriptivo git commit -m "Añadir función de login de usuario" 

# Añadir al staging y hacer commit en un solo paso (solo archivos ya rastreados) git commit -am "Corregir error en validación del formulario"

Trabajar con ramas

# Ver todas las ramas del proyecto git branch 

# Crear una rama nueva git branch nombre-de-la-rama 

# Cambiar a una rama existente git checkout nombre-de-la-rama 

# Crear una rama nueva y cambiar a ella en un solo paso (forma recomendada) git checkout -b nombre-de-la-rama 

# Fusionar una rama con la rama actual git merge nombre-de-la-rama 

# Eliminar una rama (cuando ya no la necesitas) git branch -d nombre-de-la-rama

Trabajar con repositorios remotos

# Ver los repositorios remotos configurados git remote -v 

# Subir cambios al repositorio remoto git push origin main 

# Descargar y fusionar cambios del repositorio remoto git pull origin main 

# Descargar cambios sin fusionarlos (solo para revisar) git fetch origin

Deshacer cambios (los más importantes en situaciones de emergencia)

# Descartar cambios en un archivo (volver a la última versión del commit) git checkout -- nombre-archivo.txt 

# Sacar un archivo del staging area sin perder los cambios git restore --staged nombre-archivo.txt 

# Deshacer el último commit manteniendo los cambios en los archivos git reset --soft HEAD~1 

# Ver a qué commit apunta HEAD y el historial de referencias git reflog

El comando git reflog es el salvavidas de Git. Guarda un registro de todos los movimientos de HEAD en tu repositorio local. Si alguna vez haces algo que crees irreversible, git reflog casi siempre te permite recuperarlo.

El flujo de trabajo con ramas que usan los equipos profesionales

En el trabajo real, nadie trabaja directamente sobre la rama main. Hacerlo es una mala práctica porque cualquier error va directo al código de producción. Los equipos profesionales usan un flujo de trabajo con ramas que debes conocer.

El flujo básico feature branch

Este es el patrón más habitual en equipos pequeños y medianos, y el que más probablemente usarás en tu primer empleo:

1. Asegúrate de estar en main y que está actualizado: git checkout main y git pull origin main.
2. Crea una rama nueva para tu funcionalidad: git checkout -b feature/login-usuario.
3. Desarrolla tu funcionalidad haciendo commits frecuentes con mensajes descriptivos.
4. Cuando termines, sube la rama a GitHub: git push origin feature/login-usuario.
5. Abre un Pull Request en GitHub para que tu equipo revise el código.
6. Después de la revisión y aprobación, se fusiona con main.

Convenciones de nombres para ramas

Los equipos suelen seguir una convención para nombrar ramas. La más común es usar prefijos que indiquen el tipo de cambio:

• feature/nombre-funcionalidad — para nuevas funcionalidades.
• fix/descripcion-del-error — para corrección de errores.
• hotfix/error-critico — para errores urgentes en producción.
• chore/tarea-de-mantenimiento — para tareas técnicas sin impacto en el usuario.
• docs/actualizar-readme — para cambios en documentación.

Cómo escribir buenos mensajes de commit

Un mensaje de commit malo: "cambios", "fix", "asdfgh".

Un mensaje de commit bueno describe qué cambia y por qué, no cómo. Sigue esta estructura:

# Formato recomendado tipo(ámbito): descripción breve en imperativo 

# Ejemplos reales feat(auth): añadir validación de email en el registro fix(cart): corregir cálculo incorrecto del total con descuentos docs(readme): actualizar instrucciones de instalación refactor(api): simplificar manejo de errores en endpoints

Este formato se llama Conventional Commits y es ampliamente usado en la industria. Si lo usas en tus proyectos personales desde el principio, destacarás frente a otros juniors.

Qué es un Pull Request y cómo funciona la revisión de código

Un Pull Request (PR) es una solicitud para que tu código sea revisado e integrado en la rama principal del proyecto. Es el mecanismo central de colaboración en GitHub y el que más usarás en tu día a día profesional.

El flujo de un PR bien hecho es así:

1. Subes tu rama con los cambios a GitHub.
2. Abres un Pull Request desde esa rama hacia main, con un título claro y una descripción que explique qué cambios introduces y por qué.
3. Uno o varios compañeros revisan el código, pueden dejar comentarios, pedir cambios o aprobar directamente.
4. Si hay comentarios, los resuelves haciendo nuevos commits en la misma rama. El PR se actualiza automáticamente.
5. Una vez aprobado, el PR se fusiona con main y la rama puede eliminarse.

Cómo resolver conflictos de merge

Un conflicto de merge ocurre cuando dos personas han modificado el mismo fragmento de código en ramas distintas y Git no sabe cuál versión conservar. Es algo completamente normal en equipos, no es un error tuyo.

Cuando ocurre, Git marca los archivos en conflicto con esta estructura:

<<<<<<< HEAD código de tu rama actual ======= código de la otra rama >>>>>>> feature/otra-rama

Tu trabajo es editar ese archivo manualmente, quedarte con el código correcto (que puede ser uno, el otro o una combinación de ambos), eliminar los marcadores de conflicto y hacer un commit con la resolución. La mayoría de editores como VS Code tienen una interfaz visual que hace este proceso mucho más sencillo.

Cómo tener un perfil de GitHub que impresione a los reclutadores

Tu perfil de GitHub es tu portfolio técnico. Un reclutador que no tiene tiempo de leer tu CV completo sí va a mirar tu GitHub durante 60 segundos. Esos 60 segundos determinan si pasas a la siguiente fase.

Elementos que los reclutadores miran primero

• El gráfico de contribuciones. Esa cuadrícula verde que muestra tu actividad. No necesitas contribuir todos los días, pero muestra actividad consistente en los últimos meses. Un perfil sin actividad reciente transmite desinterés.
• Los repositorios fijados. GitHub te permite fijar hasta 6 repositorios en tu perfil. Esos 6 son tu escaparate. Pon solo tus mejores proyectos.
• La calidad de los READMEs. Cada proyecto debe tener un README bien escrito que explique qué hace, qué tecnologías usa, cómo instalarlo y, si es posible, una captura de pantalla o demo.
• La calidad de los commits. Si abren uno de tus repos y ven 3 commits con el mensaje "cambios", "más cambios" y "por fin funciona", mala señal. Los commits cuentan tu historia como desarrollador.

Cómo escribir un README que destaque

Un buen README tiene esta estructura mínima:

# Nombre del Proyecto Descripción breve y clara de qué hace el proyecto (2-3 líneas). 

## 🛠️ Tecnologías utilizadas - React 18 - Node.js + Express - MongoDB - JWT para autenticación 

## 🚀 Cómo ejecutarlo en local 1. Clona el repositorio: `git clone ...` 2. Instala dependencias: `npm install` 3. Configura las variables de entorno (ver .env.example) 4. Ejecuta: `npm run dev` 

## ✨ Funcionalidades principales - Registro e inicio de sesión de usuarios - CRUD de tareas con filtros - Interfaz responsive 

## 📸 Capturas de pantalla [Añadir imágenes aquí] 

## 📬 Contacto Tu nombre — [LinkedIn](enlace) — tuemail@ejemplo.com

Cómo personalizar tu perfil de GitHub

GitHub permite crear un repositorio especial con tu nombre de usuario que actúa como la portada de tu perfil. Si tu usuario es juangomez, crea un repositorio llamado juangomez y el README de ese repositorio aparecerá en tu página principal.

Incluye en ese README una presentación breve, tus tecnologías principales, tus proyectos destacados y tus datos de contacto. Hay generadores de perfiles de GitHub como readme.so que hacen este proceso muy sencillo.

Preguntas sobre Git que te harán en la entrevista (y cómo responderlas)

Las entrevistas técnicas para junior suelen incluir entre 3 y 6 preguntas sobre Git. Estas son las más frecuentes y cómo debes responderlas:

¿Qué diferencia hay entre git merge y git rebase?

Ambos sirven para integrar cambios de una rama en otra, pero de forma diferente. git merge crea un nuevo commit de fusión y conserva el historial exacto de ambas ramas. git rebase reescribe el historial colocando tus commits encima de la rama destino, como si los hubieras hecho después. El resultado es un historial más limpio y lineal, pero reescribe el historial, lo que puede causar problemas si ya has compartido esa rama con otros. Para trabajo en equipo, merge es más seguro; rebase se usa habitualmente para mantener ramas de feature actualizadas antes de hacer el PR.

¿Qué es git stash y cuándo lo usarías?

git stash guarda temporalmente los cambios no confirmados de tu directorio de trabajo sin hacer un commit. Es útil cuando estás en medio de un desarrollo, necesitas cambiar urgentemente de rama (por ejemplo, para solucionar un bug), pero no quieres hacer un commit con código incompleto. Con git stash pop recuperas los cambios guardados cuando vuelves a tu rama.

¿Qué es un .gitignore?

Es un archivo de texto que le dice a Git qué archivos o carpetas debe ignorar y no incluir en el control de versiones. Se usa para excluir archivos de configuración local, credenciales, carpetas de dependencias como node_modules, archivos generados automáticamente o cualquier dato sensible que no debe subirse a un repositorio público. Siempre debe estar en la raíz del proyecto.

¿Qué diferencia hay entre git pull y git fetch?

git fetch descarga los cambios del repositorio remoto pero no los fusiona con tu rama local: solo actualiza tu información sobre el estado del remoto. git pull hace lo mismo que fetch pero además fusiona automáticamente los cambios en tu rama actual. En equipos con mucha actividad, a veces es mejor usar fetch primero para revisar qué cambió antes de fusionar.

¿Cómo deshaces el último commit sin perder los cambios?

Con git reset --soft HEAD~1. Este comando mueve el puntero HEAD un commit hacia atrás, pero deja los cambios del commit deshecho en el staging area, listos para ser modificados o vueltos a commitear. Si quieres deshacer el commit y también sacar los cambios del staging, usas git reset --mixed HEAD~1. Y si quieres deshacer el commit y descartar completamente los cambios (cuidado, esto es destructivo), usas git reset --hard HEAD~1.

Resumen: comandos Git esenciales de un vistazo

Conclusión

Git es una de esas herramientas que parecen complicadas al principio pero que, con unos días de práctica, se vuelven completamente intuitivas. Y una vez que la dominas, no puedes imaginar programar sin ella.

Lo más importante que puedes hacer ahora mismo es practicar con un proyecto real. Crea un repositorio en GitHub hoy, empieza a hacer commits con mensajes descriptivos, trabaja con ramas aunque sea en solitario y escribe un README decente. Eso solo ya te pondrá por delante del 60% de los candidatos junior que entran a una entrevista sin haber tocado Git de verdad.

Recuerda que los reclutadores técnicos no buscan que sepas de memoria todos los comandos. Buscan que entiendas el flujo de trabajo, que sepas moverte con soltura y que tu GitHub demuestre que llevas tiempo construyendo cosas reales.

¿Tienes dudas sobre algún comando o concepto de Git? Déjalo en los comentarios y lo resolvemos. Y si este artículo te ha sido útil, compártelo con alguien que esté preparando su primera entrevista como programador.