Creación de repositorios en GitHub: Configuración inicial

Para empezar a gestionar código con GitHub, se necesita crear un repositorio en su plataforma. Un repositorio en GitHub es un espacio donde se almacena el código fuente de un proyecto, así como su historial de cambios y colaboraciones. A continuación, se detallan los pasos para crear un repositorio y configurar sus opciones iniciales.

Para crear un nuevo repositorio:

1. Acceder a GitHub e iniciar sesión con la cuenta de usuario.

2. Hacer clic en el símbolo + situado en la esquina superior derecha de la página y seleccionar "New repository" en el menú desplegable.

3. En la página de creación del repositorio, completar los campos requeridos:

• Nombre del repositorio: Especificar un nombre único y descriptivo para el proyecto.
• Descripción (opcional): Proporcionar información breve sobre el propósito del repositorio.

4. Elegir la visibilidad del repositorio:

• Público: El repositorio será accesible para cualquier usuario en GitHub.
• Privado: Solo los usuarios autorizados podrán acceder al repositorio.

5. Inicializar el repositorio con ciertos archivos opcionales:

• README.md: Un archivo de texto en formato Markdown que describe el proyecto. Seleccionar la casilla "Add a README file" si se desea incluirlo.
• .gitignore: Un archivo que indica a Git qué archivos o directorios deben ser ignorados. Se puede seleccionar una plantilla predefinida según el lenguaje o la tecnología utilizada en el proyecto desde el menú "Add .gitignore".
• Licencia: Definir los términos bajo los cuales se distribuye el software. Se puede elegir una licencia desde el menú "Choose a license".

6. Revisar la información ingresada y hacer clic en el botón "Create repository" para finalizar el proceso.

Al crear el repositorio, se redirigirá a la página principal del mismo, donde se podrá ver el contenido inicial y acceder a opciones adicionales de configuración.

Es importante tener en cuenta ciertas buenas prácticas al configurar un nuevo repositorio:

• Utilizar un nombre de repositorio claro y representativo del proyecto para facilitar su identificación.
• Proporcionar una descripción detallada en el README.md para orientar a los colaboradores y usuarios.
• Seleccionar una licencia apropiada que refleje cómo se permite el uso y distribución del código.
• Configurar un archivo .gitignore adecuado para evitar subir al repositorio archivos innecesarios o sensibles.

Además, se pueden personalizar otras opciones del repositorio después de su creación:

• Desactivar o activar funciones como Issues, Wikis o Proyectos desde la pestaña "Settings" en la sección "Options".
• Gestionar colaboradores para permitir que otros usuarios contribuyan al repositorio, agregándolos desde la sección "Manage access".
• Configurar ramas protegidas y reglas de fusión para mantener la integridad del código en desarrollo.

Conexión con repositorio local: git remote add, git push, git pull

Una vez creado un repositorio en GitHub, se necesita conectar el repositorio local con el remoto para sincronizar los cambios. Esta conexión se realiza con el comando git remote add, que establece un vínculo entre ambos repositorios.

Para añadir el repositorio remoto, se utiliza la siguiente sintaxis:

git remote add origin <URL-del-repositorio>

Donde <URL-del-repositorio> es la dirección del repositorio en GitHub. Por ejemplo:

git remote add origin https://github.com/usuario/repositorio.git

Al ejecutar este comando, se está añadiendo un remoto llamado origin, que es el nombre por defecto utilizado en Git para referirse al repositorio principal. Se puede verificar que el remoto se ha añadido correctamente con:

git remote -v

Este comando muestra las URLs asociadas a los remotos configurados, confirmando la conexión establecida.

Una vez configurado el remoto, se pueden enviar los cambios locales al repositorio en GitHub utilizando git push. Este comando actualiza el repositorio remoto con los commits realizados en la rama local especificada. La sintaxis básica es:

git push origin main

Aquí, main es el nombre de la rama que se desea subir al repositorio remoto. Si es la primera vez que se realiza un push a esta rama, puede ser necesario utilizar:

git push -u origin main

La opción -u establece un seguimiento entre la rama local y la rama remota, facilitando futuros push y pull sin necesidad de especificar el nombre del remoto y la rama.

Para mantener el repositorio local actualizado con los cambios del remoto, se utiliza git pull. Este comando descarga y fusiona las nuevas confirmaciones del repositorio remoto en la rama local actual. Su uso es sencillo:

git pull origin main

De este modo, se asegura de tener la versión más reciente del código antes de comenzar a trabajar, evitando conflictos.

Autenticación HTTPS vs. SSH: Ventajas de SSH

En Git, existen dos métodos principales de autenticación para interactuar con repositorios remotos como GitHub: HTTPS y SSH. Ambos protocolos ofrecen conexiones seguras, pero tienen diferencias que afectan al flujo de trabajo y a la seguridad.

La autenticación mediante HTTPS utiliza el protocolo HTTP seguro y normalmente pide ingresar las credenciales de usuario (nombre de usuario y contraseña o token personal) cada vez que se ejecutan comandos que modifican el repositorio remoto, como git push o git pull. Este método no se suele utilizar ya, porque se tiene que proporcionar autenticación repetidas veces, interrumpiendo el proceso de desarrollo.

Por otro lado, la autenticación mediante SSH se basa en un par de claves criptográficas: una clave privada que se almacena de forma segura en el equipo local y una clave pública que se añade al perfil de GitHub. Una vez configuradas las claves, la conexión con el repositorio remoto se realiza sin solicitar credenciales adicionales, lo que agiliza las operaciones de Git.

Una ventaja es que las claves SSH son difíciles de descifrar mediante ataques de fuerza bruta y no se transmiten contraseñas por la red, reduciendo el riesgo de interceptación. Además, si la clave privada se mantiene segura, se previene el acceso no autorizado incluso si la clave pública es conocida.

Otra ventaja es la eficiencia. Al evitar la introducción constante de credenciales, se facilita un flujo de trabajo más fluido y ya no hay tantas interrupciones. Esto es muy útil en proyectos donde se realizan múltiples acciones sobre el repositorio remoto muchas veces.

También, SSH ofrece una más compatibilidad con herramientas de automatización y scripts. Como no requiere interacción humana para proporcionar credenciales, se pueden configurar procesos de integración continua y despliegue que interactúen con GitHub.

En entornos corporativos, SSH permite una gestión centralizada de claves y políticas de seguridad más estrictas. Se puede revocar el acceso simplemente eliminando la clave pública en GitHub, sin necesidad de modificar contraseñas o tokens, lo que simplifica la administración de permisos y el control de acceso.

Además, al utilizar SSH, se evita la dependencia de tokens personales de acceso que son necesarios con HTTPS y que pueden caducar o requerir renovaciones periódicas. Esto reduce la carga administrativa y el riesgo asociado al manejo de múltiples tokens o credenciales.

Gestionar repos privados y públicos: Opciones de visibilidad y permisos

Al crear o modificar un repositorio, se definen las opciones de visibilidad y los permisos de acceso, para controlar quién puede ver y colaborar en el código.

Al crear un nuevo repositorio, se ofrece la posibilidad de seleccionar entre dos opciones de visibilidad. Los repositorios públicos son accesibles para cualquier usuario en GitHub; todo el mundo puede ver el código, los issues y las pull requests, pero solo los colaboradores con permisos pueden realizar cambios. En cambio, los repositorios privados son accesibles únicamente para los usuarios a los que se han otorgado permisos, y el código y las actividades asociadas están ocultos para el resto de usuarios.

La selección de la visibilidad se realiza en el momento de la creación del repositorio, pero también se puede cambiarla posteriormente. Para modificar la visibilidad de un repositorio existente, se siguen los siguientes pasos: acceder al repositorio en GitHub, dirigirse a la pestaña "Settings", ir hasta la sección "Danger Zone", hacer clic en "Change visibility", seleccionar la nueva opción deseada y confirmar la acción escribiendo el nombre del repositorio cuando se solicite. Es importante considerar las implicaciones en cuanto a la exposición del código y la colaboración al cambiar la visibilidad.

Para gestionar quién puede acceder y contribuir al repositorio, se utilizan los permisos y la asignación de colaboradores. En repositorios privados, se necesita dar acceso explícito a cada usuario que participará en el proyecto. Para añadir colaboradores, se accede a la pestaña "Settings", se selecciona "Manage access", se hace clic en "Invite a collaborator", se introduce el nombre de usuario o correo electrónico del colaborador y se envía la invitación. El colaborador recibirá una notificación y deberá aceptar la invitación para obtener acceso.

Hay varios permisos que se pueden asignar a los colaboradores.

• El permiso Admin permite administrar todos los aspectos del repositorio, incluyendo la gestión de configuración, colaboradores y eliminar el repositorio.
• El permiso Write permite realizar cambios en el código, fusionar pull requests y gestionar issues.
• El permiso Read otorga acceso de solo lectura al repositorio, permitiendo ver el código y las actividades, pero sin posibilidad de realizar cambios.

En contextos de organizaciones, también existe el permiso Maintainer, similar a Admin pero dentro del ámbito de un equipo.

En proyectos más grandes, se suele utilizar una organización para agrupar repositorios y miembros. Las organizaciones permiten gestionar equipos de usuarios y asignar permisos de forma más específica. Para trabajar con organizaciones, se crea una organización desde el perfil de usuario en GitHub, se añaden miembros a la organización y se crean equipos con responsabilidades específicas. Luego, se asignan repositorios a los equipos y se definen los permisos correspondientes (Admin, Write, Read).

Para mantener un control adecuado sobre el repositorio y proteger el código, se recomienda seguir buenas prácticas en la gestión de permisos. Es aconsejable revisar periódicamente los permisos asignados a colaboradores y equipos, otorgar el mínimo nivel de acceso necesario para cada colaborador según sus responsabilidades, utilizar equipos dentro de organizaciones para gestionar permisos de forma colectiva, configurar ramas protegidas para evitar cambios no autorizados en ramas críticas como main o master, y establecer reglas de fusión que requieran revisiones o aprobaciones antes de integrar cambios.