Idioma
Categoría
Buscar

Subir un nuevo proyecto a GitHub usando Linux y SSH sin contraseña

Configura Git en el repositorio local, sincroniza con GitHub, aprende sobre versionado, usa tags y releases para organizar versiones de tu proyecto y hacerlo disponible para descarga

Índice

Subir un nuevo proyecto a GitHub usando Linux y SSH sin contraseña
En Terminal Por Rudi Drusian Lange
Publicado el
Última actualización

Introducción

Este artículo es una guía paso a paso para ayudar a principiantes a configurar Git en un nuevo proyecto y sincronizarlo con GitHub. Además, aprenderás a usar claves SSH para evitar la necesidad de ingresar contraseñas repetidamente. Al final, también abordaremos cómo crear tags y disponibilizar releases para tu proyecto.

Prerrequisitos

Crear una Cuenta en GitHub y Configurar un Nuevo Repositorio

Antes de comenzar, necesitarás tener una cuenta en GitHub y crear un repositorio para almacenar tu proyecto. Este proceso es intuitivo y cuenta con asistencia directa de la propia plataforma durante las etapas. Asegúrate de seguir las indicaciones en GitHub para completar esta configuración inicial.

Entorno de Desarrollo

Los comandos presentados en este artículo fueron probados en Linux Slackware 15.0, utilizando las herramientas nativas Git (versión 2.46.3) y OpenSSH (versión 9.9p2). Los comandos son genéricos y deberían funcionar en cualquier distribución Linux que tenga Git y SSH instalados.

Iniciando Git en el Proyecto Local

Paso 1: Configurar Git para Usar main Como Branch Predeterminada

Muchas plataformas modernas (como GitHub, GitLab y Bitbucket) adoptan el nombre main como branch predeterminada. Para garantizar que nuevos repositorios usen automáticamente main como branch principal, es necesario ajustar la configuración global de Git. Ejecuta el siguiente comando:

$ bash

git config --global init.defaultBranch main

Con esta configuración, el comando git init creará automáticamente la branch main, eliminando la necesidad de renombrarla manualmente.

Paso 2: Inicializando el Repositorio

Considerando un proyecto denominado telazul, a continuación se presentan los pasos necesarios para configurar Git en este directorio y preparar el proyecto para sincronización con GitHub.

$ bash

# Entra al directorio del proyecto
cd telazul/

# Inicializa el repositorio Git
git init

El comando git init se usa solo una vez para crear la estructura necesaria para el repositorio. Para verificar el nombre de la branch actual y renombrarla si es necesario, usa los siguientes comandos:

$ bash

# Verifica el nombre de la branch actual
git branch

# Renombra la branch master a main
git branch -m master main

Paso 3: Agregando Archivos al Repositorio Local

Agrega todos los archivos y directorios al repositorio y guarda los cambios con un mensaje informativo:

$ bash

# Agrega todos los archivos de la carpeta actual recursivamente
git add .

# Guarda los cambios permanentemente con un mensaje descriptivo
git commit -m "Commit inicial: agregando archivos del proyecto"

El comando git add . agrega todos los archivos modificados o nuevos al índice, mientras que git commit crea una instantánea del estado actual de los archivos, guardando los cambios permanentemente. Como es posible recuperar el estado exacto de este commit en el futuro, el mensaje asociado debe ser claro y descriptivo para facilitar la identificación de los cambios realizados.

Los pasos anteriores configuran Git en el proyecto local. Son independientes de la integración con GitHub y pueden usarse en cualquier flujo de trabajo de Git.

Configurando Acceso SSH a GitHub

El proyecto se transferirá usando SSH, un protocolo seguro y práctico para transferir archivos por internet. Para ello, es necesario configurar claves SSH que funcionarán como credenciales, permitiendo el inicio de sesión en GitHub sin necesidad de ingresar una contraseña.

$ bash

# Crea las claves usando el algoritmo ed25519
ssh-keygen -t ed25519

Cuando se te pregunte, presiona Enter ↲ para mantener la ubicación predeterminada ~/.ssh/ y para usar una contraseña en blanco. Si ya tienes claves SSH compatibles con GitHub (como id_rsa o id_ed25519), no es necesario crear nuevas claves.

Agregando la Clave Pública a GitHub

Para transferir la clave pública entre computadoras Linux, puedes usar el comando ssh-copy-id. Sin embargo, en GitHub, es necesario copiar y pegar la clave manualmente en la interfaz gráfica de la plataforma.

La clave pública está almacenada en el archivo que termina con .pub. Para mostrar su contenido, usa el siguiente comando (reemplaza tu-usuario por el nombre de tu usuario en el sistema):

$ bash

cat /home/tu-usuario/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEDbDtQNhBvGd292FgKDRgqhiXGiLHo32ZYXCSS017d5 tu-usuario@nombre-del-host

Copia la línea completa que comienza con ssh-ed25519 (clave pública) y:

  1. Accede a GitHub y haz clic en el menú con tu avatar en la esquina superior derecha.
  2. Navega hasta Settings > SSH and GPG Keys.
  3. Haz clic en New SSH Key,
  4. Completa el campo Title con un nombre descriptivo para la clave (ej.: "Clave SSH de mi notebook").
  5. Pega la clave pública en el campo Key.
  6. Haz clic en Add SSH Key para guardar.

Después de la configuración, la clave aparecerá listada en la página de claves SSH, como se ilustra a continuación:

github-ssh-authentication-keys

Subiendo el Proyecto a GitHub

Para conectar el repositorio local al repositorio remoto en GitHub, usa el siguiente comando. Este agrega el alias origin al repositorio remoto, permitiendo referenciarlo fácilmente en operaciones futuras.

$ bash

git remote add origin git@github.com:tu-usuario/tu-repositorio.git

Asegúrate de ejecutar el comando anterior dentro de la carpeta del proyecto y reemplaza tu-usuario por tu nombre de usuario en GitHub y tu-repositorio por el nombre del repositorio creado en la plataforma.

Ahora, envía el proyecto al repositorio remoto con el siguiente comando:

¡Atención! El uso del parámetro -f borrará todos los archivos existentes en el repositorio remoto. Úsalo solo cuando sea necesario, como en el caso de un repositorio recién creado en GitHub.

$ bash

git push -u -f origin main
  • El parámetro -u (o --set-upstream) define origin como la referencia predeterminada para la branch main. Después de esta configuración, podrás usar los comandos git push y git pull sin necesidad de especificar el repositorio remoto o la branch.
  • El parámetro -f (o --force) fuerza la actualización del repositorio remoto, sobrescribiendo cualquier contenido existente. Este parámetro es útil al iniciar un nuevo proyecto cuando el repositorio remoto contiene archivos predeterminados (como LICENSE o README.md) que impiden el push inicial.

Sincronizando Cambios del Repositorio Remoto

Entra en el sitio de GitHub y crea el archivo README con algún contenido. Para sincronizar estos cambios en el repositorio remoto con el repositorio local, ejecuta el siguiente comando desde la carpeta del proyecto:

$ bash

git pull

El comando git pull trae todos los commits más recientes de la branch remota y los aplica a la branch local.

Como se mencionó anteriormente, al subir el proyecto con el comando git push usando el parámetro -u, el repositorio en GitHub se define como referencia predeterminada. Esto elimina la necesidad de especificar el nombre del repositorio remoto (origin) en comandos posteriores.

Después de ejecutar el comando, verifica que el archivo README creado remotamente ahora está presente en la carpeta local del proyecto.

Actualizando Archivos Localmente

Edita el archivo README en el repositorio local, agregando una nueva línea. Luego, registra los cambios y envíalos al repositorio remoto con los siguientes comandos:

$ bash

git commit -a -m "Actualización del archivo README"

git push

El parámetro -a prepara automáticamente todos los archivos modificados o eliminados en el repositorio local. Sin embargo, no incluye nuevos archivos (archivos que aún no han sido rastreados por Git). Para incluir nuevos archivos, usa el comando git add.

El parámetro -m permite agregar un mensaje descriptivo al commit.

El comando git push actualiza el repositorio remoto en GitHub con los cambios recientes realizados en la carpeta local del proyecto.

Versionamiento Semántico

Antes de entrar en el tema de tags y releases, es importante entender brevemente la numeración utilizada en las versiones de software. El Versionamiento Semántico (o SemVer) es una convención ampliamente adoptada para nombrar versiones de software, facilitando la comunicación sobre cambios y garantizando compatibilidad.

Sigue el formato:

MAYOR.MENOR.PARCHE
  • MAYOR: Incrementado cuando hay cambios incompatibles con versiones anteriores (ej.: alteraciones que rompen APIs o funcionalidades).
  • MENOR: Incrementado cuando se agregan funcionalidades compatibles (sin romper el funcionamiento actual).
  • PARCHE: Incrementado para correcciones de errores o pequeñas mejoras que no alteran funcionalidades existentes.

Ejemplos

  • 1.0.0: Primera versión estable del software.
  • 1.1.0: Adición de nuevas funcionalidades sin romper la compatibilidad.
  • 1.1.1: Corrección de errores en la versión 1.1.0.
  • 2.0.0: Cambios incompatibles con la versión 1.x.x.

Es una práctica recomendada para proyectos que necesitan comunicar claramente el estado de desarrollo y los cambios introducidos en cada versión.

Nombrando Versiones con Tags

Una tag es una referencia estática que apunta a un commit específico en el historial de Git. A diferencia de los branches, que pueden avanzar y cambiar con el tiempo, las tags son fijas y no cambian después de crearse. Esto las hace ideales para marcar eventos importantes, como lanzamientos de versiones que pueden ser disponibles para que los usuarios las descarguen.

$ bash

git tag v1.0.0

Este comando crea una tag llamada v1.0.0, generando una versión definitiva del proyecto que contiene todos los archivos y directorios en el estado en que estaban en el momento del último commit ejecutado.

El prefijo v (de "versión") es una convención adoptada para identificar tags de versión, facilitando su distinción en el historial de Git, especialmente entre otras marcas (ej.: beta-test).

Para nombrar un commit específico, diferente al actual, con una tag usa:

$ bash

git tag nombre-de-la-tag hash-del-commit

Para descubrir el hash-del-commit consulta este tema.

Los comandos anteriores crean las llamadas tags simples (o ligeras). Otra opción son las tags anotadas, que son más detalladas e incluyen metadatos, como mensaje, autor y fecha. Se recomiendan para marcar versiones importantes.

Para crear una tag anotada, usa el parámetro -a:

$ bash

git tag -a v1.0 -m "Versión 1.0 estable"

Otros comandos útiles para gestionar tags:

$ bash

# Lista todas las tags
git tag

# Lista todas las tags y sus commits
git log --oneline --decorate

# Muestra detalles sobre una tag específica
git show nombre-de-la-tag

Enviando Tags al Repositorio Remoto

Por defecto, las tags no se envían automáticamente al repositorio remoto al usar el comando git push. Para enviar tags al repositorio remoto, usa los siguientes comandos:

$ bash

# Envía una tag específica
git push origin nombre-de-la-tag

# Envía todas las tags de una vez
git push origin --tags

Ejemplo Práctico

Supón que acabas de concluir la versión 1.0 de tu proyecto. Puedes marcar este momento con una tag anotada y enviarla al repositorio remoto siguiendo estos pasos:

$ bash

# Crea la tag localmente
git tag -a v1.0 -m "Versión 1.0 estable"

# Envía la tag al repositorio remoto
git push origin v1.0

Eliminando Tags

Las tags en Git son referencias inmutables por diseño, lo que significa que, una vez creadas, siempre apuntan al commit al que fueron asignadas. Sin embargo, es posible eliminarlas.

Para eliminar una tag local:

$ bash

git tag -d nombre-de-la-tag

Para eliminar una tag remota:

$ bash

git push origin --delete nombre-de-la-tag

Este comando eliminará la tag en GitHub.

Actualizando Tags

Las tags en Git no pueden actualizarse directamente. Sin embargo, es posible simular una actualización eliminando la tag existente y creando una nueva con el mismo nombre. Para ello, sigue los pasos a continuación:

$ bash

# Elimina la tag local
git tag -d nombre-de-la-tag

# Elimina la tag remota
git push origin --delete nombre-de-la-tag

# Crea la nueva tag con el mismo nombre
git tag -a nombre-de-la-tag -m "Nuevo mensaje de la tag"

# Envía la nueva tag al repositorio remoto
git push origin nombre-de-la-tag

¡Atención! Buenas Prácticas al "Actualizar" Tags

Aunque técnicamente es posible eliminar y recrear tags con el mismo nombre, esta práctica puede causar confusión, especialmente si la tag original ya está siendo usada por otras personas. Cambiar una tag después de haber sido compartida puede llevar a inconsistencias en el historial del proyecto.

Evita alterar tags ya publicadas: Si la tag ya ha sido compartida con otros desarrolladores o utilizada en releases oficiales, prefiere crear una nueva tag con un nombre diferente (por ejemplo, v1.0.1 en lugar de reutilizar v1.0).

Creando una Nueva Release en GitHub

Comienza creando una tag local para indicar la versión de tu proyecto y envíala al repositorio remoto en GitHub:

$ bash

# Crea la tag localmente
git tag -a v1.0.0 -m "Versión 1.0.0 estable"

# Envía la tag al repositorio remoto
git push origin v1.0.0

En GitHub:

  1. Accede a la página de releases.
    • https://github.com/tu-usuario/tu-repositorio/releases
  2. Haz clic en Create a new release.
  3. Completa los detalles de la release:
    • Chose a tag: Selecciona la tag que creaste (ej: v1.0.0) o crea una nueva directamente en esta pantalla. En este ejemplo, la tag se está creando localmente y se transfiere al repositorio remoto, sin embargo, el proceso inverso también es válido.
    • Release Title: Proporciona un título descriptivo para la release (por ejemplo, v1.0.0 - Versión Estable).
    • Describe this release: Agrega una descripción detallada de la release. Incluye información como: qué se agregó, corrigió o alteró, enlaces a documentación, recursos relacionados, etc.
    • Set as a pre-release : Marca esta opción si la versión es beta o experimental. De lo contrario, déjala desmarcada.
  4. Publica haciendo clic en Publish release.

Después de publicar la release, GitHub disponibiliza automáticamente los archivos asociados al commit marcado por la tag. Puedes descargarlos como un archivo .zip o .tar.gz.

Conclusión

Este artículo fue escrito para ser una guía práctica, en la que las personas puedan consultar los pasos necesarios para crear sus primeros proyectos y disponibilizarlos para descarga en GitHub. Si lograste configurar tu repositorio, crear tags, releases y compartir tu trabajo con el mundo, cumplió su propósito.

Continúa explorando Git y GitHub, y aprovecha todas las posibilidades que estas herramientas ofrecen para organizar, compartir y colaborar en tus proyectos.

Referencias

Tablón de Anuncios

Este no es mi idioma original y no lo hablo muy bien. Utilicé mis pocos conocimientos y herramientas de traducción para redactar el texto de este artículo. Disculpe los posibles errores ortográficos o gramaticales, se agradecen sugerencias de correcciones y se pueden enviar al correo electrónico de contacto que se encuentra en el pie de página del sitio. Mi intención es compartir algunos conocimientos y espero que esta traducción sea lo suficientemente buena.


Algunos de los contenidos de este sitio web, incluidos textos, imágenes, gráficos y otros materiales, pueden ser generados o mejorados mediante herramientas de inteligencia artificial (IA). Para obtener más detalles sobre nuestro uso de IA, consulte nuestro Término de uso.

Anuncio
Índice
Anuncio