Llevar un proyecto local a GitHub implica conectar tu carpeta de Git con un repositorio remoto, dominar el flujo de ramas y entender cómo se solicitan cambios mediante pull requests. Esta guía te muestra el proceso completo, desde crear el repositorio hasta hacer merge a la rama principal, pensada para quienes empiezan a colaborar con código de forma profesional.

Cómo creas un repositorio en GitHub paso a paso

Desde tu cuenta de GitHub, haces clic en New repository y defines el nombre de tu proyecto. Una recomendación práctica es usar kebab case: todo en minúsculas y los espacios reemplazados por guiones, así mantienes nombres consistentes y legibles en cualquier sistema [01:00].

Después eliges si el repositorio será público o privado. Aquí va una advertencia importante: si trabajas en una empresa, siempre crea repositorios privados. Subir código corporativo a un repo público puede exponer información sensible y eso no es nada bueno.

¿Qué es un repositorio en Git? Es un proyecto, ya sea de código o de texto, donde Git rastrea toda la historia de cambios. Puede vivir solo en tu máquina o estar sincronizado con una plataforma como GitHub.

Qué archivos opcionales puedes añadir al inicio

GitHub te ofrece tres añadidos al crear el repositorio y cada uno cumple una función distinta:

• README: documento principal en formato Markdown que se muestra en la portada del proyecto.
• .gitignore: archivo donde especificas qué archivos no quieres que Git rastree.
• Licencia: documento que describe los usos, reglas, derechos y responsabilidades sobre tu software [02:30].

Entre las licencias más conocidas están MIT, OpenGL y Creative Commons. Esta última te permite compartir tu trabajo de forma gratuita y, según la variación, otros pueden distribuirlo o incluso lucrar con él. Es ideal cuando buscas distribución amplia sin fines comerciales propios.

Cómo conectas tu proyecto local con el repositorio remoto

Una vez creado el repositorio, GitHub te muestra dos formas de conexión: HTTPS o SSH. Si ya configuraste tu llave SSH, esa es la opción recomendada porque evita escribir credenciales cada vez.

Desde la terminal, dentro de tu carpeta de Git, ejecutas:

bash git remote add origin git@github.com:usuario/mi-primer-proyecto.git

Este comando le dice a tu Git local cuál es la URL del repositorio remoto al que llamará origin. Luego, para enviar tus commits al servidor, usas git push origin main [05:20].

¿Qué hace git push exactamente? Empuja todos tus commits locales a una rama remota. Si tienes tres commits hechos localmente, después del push aparecerán en GitHub para que cualquiera con acceso pueda verlos.

La primera vez que haces push por SSH, el sistema te pide autenticar la firma y, si tu llave tiene contraseña, la solicitará. Cuando veas el mensaje de éxito, recarga GitHub y verás tu README publicado junto al historial de commits de forma legible.

Por qué no debes hacer push directo a main

Aunque técnicamente puedes trabajar siempre sobre main y empujar ahí tus cambios, esa práctica está mal vista en equipos profesionales. La regla es clara: no hagas push directo a main. En su lugar, creas una rama nueva, trabajas tus cambios ahí y luego abres un pull request para mezclarlos a la rama principal [08:15].

Piensa en una rama como una bifurcación temporal de tu proyecto. Mientras tú agregas una nueva descripción al README, otra persona podría estar tocando otro archivo en su propia rama, sin pisarse mutuamente.

Cómo creas una rama y subes cambios

Desde la terminal de Visual Studio Code o tu terminal habitual, el comando para crear y moverte a una rama nueva es:

bash git checkout -b mis-cambios

La bandera -b indica que la rama no existe y debe crearse. Después editas tu archivo, guardas, agregas los cambios al staging con git add o el botón de más en VS Code, y haces commit:

bash git commit -m "nuevos cambios"

Un detalle común: si haces commit sin antes agregar los archivos al staging, Git te avisa que no hay nada listo para confirmar. El staging es esa zona intermedia donde decides qué entra al commit y qué no.

Para publicar tu rama nueva en GitHub, usas git push origin mis-cambios. GitHub detectará la rama y te ofrecerá crear un pull request automáticamente [11:40].

Cómo funciona un pull request y cuándo hacer merge

Un pull request es una solicitud formal para incorporar los cambios de tu rama a otra rama, normalmente main. Lleva un título que resume el tema general (por ejemplo, agregando una nueva sección) y una descripción más detallada de lo que aporta.

¿Qué es un conflicto en Git? Ocurre cuando dos ramas modifican la misma línea de un archivo y Git no sabe cuál versión conservar. Debes resolverlo manualmente antes de poder hacer merge.

GitHub te muestra quién hizo los cambios, cuándo y si existen conflictos. Cuando todo está limpio, haces clic en Merge pull request y luego en Confirm merge. Tu rama queda integrada a main y el historial principal del proyecto se actualiza [14:10].

Cómo traes los cambios remotos a tu proyecto local

Después del merge, tu copia local de main todavía no tiene esos cambios. Para sincronizarla, te mueves a main con git checkout main y ejecutas:

bash git pull

El comando git pull es lo opuesto a push: descarga todos los cambios del repositorio remoto a tu proyecto local. Es especialmente útil cuando varias personas hacen pull requests y necesitas mantener tu copia al día.

Más allá de este flujo básico, Git ofrece herramientas como git blame para identificar quién modificó cada línea de código, útil cuando aparece un bug y quieres rastrear su origen. Cuéntame en los comentarios qué parte del flujo te resulta más confusa y qué proyecto vas a subir primero a GitHub.