Aprender Git y GitHub puede ayudarte a trabajar con cambios de un proyecto sin convertir cada versión en una carpeta nueva. Para empezar no necesitas construir una aplicación completa: puedes practicar con un documento de instrucciones y aprender a explicar qué has cambiado, por qué y cómo lo has revisado.
Esta propuesta se centra en el control de versiones y la colaboración, no en decorar un perfil para buscar empleo. Fuentes oficiales consultadas el 28 de octubre de 2026. No implica una inscripción realizada, una certificación obtenida ni una garantÃa de contratación.
Una formación anunciada para noviembre en Barcelona Activa
La ficha de Git y GitHub para principiantes de Cibernà rium anuncia una sesión de cuatro horas por Zoom, en catalán, el 20 de noviembre de 2026, de 9:30 a 13:30. La inscripción abre el 4 de noviembre a las 8:30, en horario de Barcelona. A la fecha de consulta no corresponde presentarla como una plaza ya disponible.
El temario incluye repositorios, historial, ramas, fusiones y solicitudes de cambios. La ficha indica que, para Zoom, el acceso se habilita en el Espacio Personal entre una y dos horas antes de empezar. Revisa allà las instrucciones de tu inscripción, no esperes un enlace por una vÃa diferente.
Las normas de Cibernà rium señalan que las actividades son gratuitas y requieren registro previo. Pueden inscribirse personas mayores de 16 años con DNI, NIE o pasaporte, sin exigir una situación laboral especÃfica. Antes de organizarte, confirma que el idioma, el horario y las condiciones encajan contigo.
Qué aporta el control de versiones
El libro oficial Pro Git explica el control de versiones como un registro de cambios que permite consultar estados anteriores y comparar modificaciones. Es distinto de mantener archivos llamados final, final-bueno y final-definitivo sin saber qué contiene cada uno.
Git es la herramienta de control de versiones; GitHub es una plataforma donde puedes alojar repositorios y colaborar. No son dos nombres para la misma cosa. Para la práctica inicial de este artÃculo utilizaremos el navegador, sin pedirte que configures todavÃa un entorno local.
La finalidad del ejercicio es sencilla: que puedas enseñar una modificación pequeña y explicar su recorrido. Tener una cuenta abierta o muchos archivos subidos no demuestra por sà solo que comprendas ese proceso.
Prepara un proyecto ficticio y sin datos privados
Como propuesta propia, imagina un documento con instrucciones para una aplicación inventada de tareas. El texto inicial podrÃa decir: «Para crear una tarea, escribe un tÃtulo y pulsa Guardar». Tu mejora consistirá en aclarar qué debe hacer la persona si el tÃtulo está vacÃo.
No necesitas una aplicación funcionando para ensayar el historial del documento. Si no existe, dilo en la descripción: «Práctica de documentación sobre un producto ficticio». No presentes el texto como una solución implantada en una empresa ni como una prueba de programación que no has realizado.
Utiliza únicamente contenido propio. No copies un documento del trabajo para quitarle después el logotipo. Revisa también nombres de personas, correos, claves y capturas antes de subir cualquier archivo, aunque inicialmente el repositorio sea privado.
Recorrido inicial en el navegador
El ejercicio oficial Hola mundo de GitHub enseña repositorios, ramas, commits y pull requests sin exigir programación, lÃnea de comandos ni instalar Git. Necesitas una cuenta de GitHub. Puedes seguirlo y utilizar después nuestro pequeño ejemplo para comprobar qué has entendido.
- Crea un repositorio de práctica y añade un README. Elige su visibilidad de forma consciente.
- Crea una rama para la mejora, por ejemplo
aclarar-titulo, en vez de modificar directamente la rama principal. - Edita el texto en esa rama y confirma el cambio con un mensaje que explique la modificación.
- Abre una solicitud de cambios hacia la rama principal y revisa lo que propone antes de fusionarla.
Realiza este recorrido solo en tu repositorio de práctica. No cambies un proyecto compartido para comprobar dónde está un botón. En un equipo real, los permisos y las normas de revisión pueden impedir que tú mismo completes todas las acciones.
Qué escribir en el commit y en la solicitud
Para nuestro ejemplo, un mensaje de commit propuesto serÃa «Aclara que el tÃtulo de la tarea es obligatorio». Es más informativo que «cambios» porque permite reconocer el propósito sin abrir inmediatamente todo el documento. No necesitas inventar una terminologÃa complicada.
En la solicitud, explica tres cosas con tus palabras: problema, modificación y revisión realizada. Por ejemplo: el texto no explicaba qué hacer con un tÃtulo vacÃo; has añadido una instrucción; has comprobado que no contradice el párrafo anterior. Si no has probado una aplicación, no escribas que todas sus pruebas han pasado.
La documentación de pull requests describe estas solicitudes como propuestas que permiten discutir y revisar cambios antes de integrarlos. La pestaña Files changed muestra las diferencias. Úsala para comprobar que no has añadido una modificación accidental junto a la que querÃas presentar.
La revisión también incluye saber qué no has comprobado
Una primera lista puede ser breve: ¿se entiende la nueva instrucción?, ¿has conservado el resto del texto?, ¿el nombre de la rama permite reconocer su finalidad?, ¿la descripción explica el cambio real? Estas preguntas son una propuesta de revisión, no un resultado automático de GitHub.
Si trabajas sin otra persona, indica que has realizado una autorrevisión. No inventes una aprobación externa. Si alguien colabora, acuerda antes qué debe revisar y no añadas personas a un proyecto sin su autorización.
No necesitas provocar conflictos ni utilizar operaciones que reescriban el historial para completar esta primera práctica. Aprender a revisar un cambio pequeño es un objetivo suficiente. Los conflictos y la recuperación de cambios pueden estudiarse después en un entorno que puedas reconstruir.
Qué puedes mostrar y qué debes seguir aprendiendo
Al terminar de verdad el ejercicio, deberÃas poder localizar el texto inicial, el cambio y la explicación de su integración. Si todavÃa no lo has ejecutado, conserva el documento como un plan de práctica y marca lo pendiente.
Nuestra guÃa de portafolio en GitHub trata cómo presentar muestras. Este ejercicio aporta una habilidad distinta: explicar el recorrido de una modificación. No convierte una sesión corta en dominio de Git ni sustituye los requisitos de una oferta.
Antes de pagar por una formación más larga, compara ejercicios corregidos, soporte, nivel inicial e idioma. Utiliza la sesión anunciada o los recursos oficiales para detectar qué te falta, y amplÃa la práctica con cambios pequeños que puedas justificar.
Portada ilustrativa de programación; no muestra una sesión de Barcelona Activa ni la interfaz de GitHub: Mikhail Fesenko en Pexels, licencia Pexels.
