Git y GitHub para tu primer trabajo de programador: los comandos, ramas y pull requests que vas a usar desde el primer día

Resumen ejecutivo

• En casi cualquier equipo de desarrollo vas a usar Git y GitHub desde el primer día: clonar el repositorio, crear una rama por tarea, hacer commits y abrir pull requests.

• Con 12 comandos cubrís el 90% del trabajo diario de un programador junior; el resto lo vas sumando a medida que aparece.

• El flujo completo es siempre el mismo: rama nueva, cambios, commit, push, pull request, code review, merge.

• Practicar ese flujo en un repositorio propio y dejarlo visible en tu perfil de GitHub es una de las mejores pruebas que podés mostrar cuando postulás a un puesto junior.

En las entrevistas para un primer trabajo de programación casi nadie te pregunta por Git. Lo dan por sabido. Y después, en la primera semana, todo pasa por ahí: te dan acceso al repositorio, te asignan un ticket y esperan un pull request. Mucha gente que aprendió a programar sola llega con Git a medias, usando solo add, commit y push sobre la rama principal. Esta guía cubre lo que un equipo real espera que sepas, con un flujo de ejemplo que podés practicar hoy en un repositorio propio.

Git y GitHub no son lo mismo

Git es el sistema de control de versiones: guarda la historia de cada cambio del código en tu computadora y permite trabajar en paralelo con ramas. GitHub es una plataforma en la nube donde se alojan esos repositorios y donde el equipo colabora con pull requests, comentarios y revisiones. Hay alternativas como GitLab o Bitbucket, pero la lógica es la misma. Si querés la referencia completa, el libro Pro Git, gratuito y en español, es la documentación oficial del proyecto.

Los 12 comandos que vas a usar todos los días

1. git clone URL: descarga el repositorio del equipo a tu computadora. Lo hacés una vez por proyecto.

2. git status: muestra qué archivos cambiaste y cuáles están listos para el commit. Usalo todo el tiempo.

3. git pull: trae los últimos cambios del remoto. Hacelo antes de empezar cada tarea.

4. git switch -c nombre-de-rama: crea una rama nueva y te mueve a ella (en versiones viejas, git checkout -b).

5. git switch main: vuelve a la rama principal.

6. git add archivo: marca los cambios que van a entrar en el próximo commit. Evitá git add . sin revisar antes.

7. git commit -m "mensaje": guarda una foto de esos cambios con una descripción.

8. git push -u origin nombre-de-rama: sube tu rama al repositorio remoto la primera vez; después alcanza con git push.

9. git diff: muestra línea por línea qué cambiaste antes de hacer el commit.

10. git log --oneline: lista la historia de commits de forma compacta.

11. git merge main o git rebase main: actualiza tu rama con lo último de la principal. Cada equipo prefiere una de las dos; preguntá cuál.

12. git stash: guarda cambios a medio hacer para cambiar de rama sin perderlos (git stash pop los recupera).

El flujo de trabajo de un ticket, paso a paso

Supongamos que te asignan el ticket «Agregar validación de email en el formulario de registro». El flujo típico en un equipo que trabaja con GitHub es este:

1. Actualizá la rama principal: git switch main y git pull.

2. Creá una rama para la tarea: git switch -c feature/validacion-email. Muchos equipos incluyen el número del ticket en el nombre.

3. Hacé el cambio y probalo: corré la aplicación y los tests antes de seguir.

4. Revisá y hacé commits chicos: git diff, después git add de los archivos correctos y git commit -m "Valida formato de email en registro".

5. Subí la rama: git push -u origin feature/validacion-email.

6. Abrí el pull request en GitHub: título claro, descripción con qué cambiaste, por qué y cómo probarlo, y una captura si es algo visual.

7. Respondé el code review: corregí lo que te pidan en la misma rama, hacé commit y push; el pull request se actualiza solo.

8. Merge: cuando lo aprueban, se integra a la rama principal (a veces lo hacés vos, a veces el revisor) y se borra la rama.

La documentación de GitHub sobre pull requests explica cada pantalla de este proceso. Y si querés saber qué más pasa en esas primeras semanas, leé el primer mes de un programador junior: tareas reales y code reviews.

Cómo escribir buenos mensajes de commit

El mensaje de commit es lo que tus compañeros van a leer meses después para entender por qué cambió algo. Algunas reglas que casi todos los equipos comparten:

• En imperativo y corto: «Agrega validación de email» o «Corrige cálculo de descuento», no «cambios» ni «arreglos varios».

• Un cambio lógico por commit: si arreglaste un bug y además renombraste variables, son dos commits.

• Con el porqué cuando no es obvio: la primera línea dice qué; el cuerpo del mensaje puede explicar por qué.

• Siguiendo la convención del equipo: algunos usan prefijos como feat:, fix: o docs:. Mirá el historial con git log --oneline y copiá el estilo.

Cómo resolver un conflicto de merge sin romper nada

Un conflicto aparece cuando vos y otra persona cambiaron las mismas líneas del mismo archivo. No es un error grave, es parte del trabajo. Para resolverlo:

1. Actualizá tu rama con la principal (git merge main o git rebase main, según el equipo).

2. Git te marca los archivos en conflicto. Abrilos: vas a ver bloques entre <<<<<<<, ======= y >>>>>>> con las dos versiones.

3. Decidí qué queda: tu versión, la otra o una combinación. Si no entendés el cambio ajeno, preguntale a quien lo hizo.

4. Borrá las marcas, probá que todo funcione, hacé git add del archivo y terminá con git commit (o git rebase --continue).

Los editores como VS Code muestran los conflictos con botones para aceptar una u otra versión, lo que hace el proceso mucho más visual.

Errores típicos de un junior con Git (y cómo evitarlos)

• Trabajar directo sobre main: creá siempre una rama, aunque el cambio sea de una línea.

• Pull requests gigantes: cuanto más chico el cambio, más rápido y mejor te lo revisan.

• Subir archivos que no van: contraseñas, archivos .env, carpetas como node_modules. Para eso existe el archivo .gitignore.

• Usar git push --force sin saber qué hace: puede borrar trabajo ajeno en una rama compartida. Si un tutorial te lo sugiere, preguntá antes.

• No hacer git pull antes de empezar: es la forma más rápida de terminar en un conflicto evitable.

Cómo practicar y mostrarlo en tu GitHub cuando postulás

Un perfil de GitHub con un solo commit gigante que dice «proyecto final» no dice mucho. Uno con ramas, pull requests y mensajes claros muestra que ya sabés trabajar como en un equipo. Para practicar:

• Creá un repositorio propio y trabajá cada funcionalidad nueva en una rama con su pull request, aunque te lo apruebes vos.

• Escribí en cada pull request la descripción como si alguien más lo fuera a revisar.

• Pedile a un compañero de curso que te revise un pull request y revisá uno de él: así practicás las dos puntas del code review.

• Contribuí a un proyecto open source con issues marcados como good first issue.

Para elegir qué proyectos subir, tenemos una guía de proyectos de GitHub para conseguir trabajo y qué buscan los recruiters, y otra sobre cómo conseguir tu primer trabajo en tecnología.

Curso recomendado de Coderhouse

En la carrera de Desarrollo Full Stack trabajás con Git y GitHub en todos los proyectos, con entregas que pasan por un flujo parecido al de un equipo real. Si preferís empezar por la base, el curso de Desarrollo Web es un buen primer paso para armar tus primeros repositorios.

Preguntas frecuentes

¿Tengo que saber usar Git por consola o alcanza con una interfaz gráfica? Las interfaces como GitHub Desktop o la de VS Code sirven mucho, pero conviene entender los comandos: cuando algo sale mal, la solución casi siempre se explica en términos de consola.

¿Cuál es la diferencia entre merge y rebase? Los dos integran cambios de una rama en otra. Merge crea un commit que une las historias; rebase reescribe tus commits encima de la rama principal y deja una historia lineal. Usá la que use tu equipo.

¿Qué hago si hice un commit en la rama equivocada? Si todavía no lo subiste, podés crear la rama correcta desde ese punto y deshacer el commit en la rama original. Si ya lo subiste, avisá y pedí ayuda antes de reescribir historia.

¿GitHub sirve como portfolio? Sí, siempre que los repositorios tengan un README claro, una historia de commits prolija y, si es posible, el proyecto publicado online para probarlo.