Una guía rápida sobre la plataforma de alojamiento de proyectos de TI y desarrollo colaborativo más popular del mundo.
83 millones de usuarios, cuatro millones de organizaciones y 200 millones de repositorios. En internet existen muchos servicios para alojar el código fuente de tus proyectos, pero se habla más a menudo de GitHub. ¿Por qué?
Por supuesto, el conocido propietario del servicio (Microsoft) y la costumbre juegan un papel importante, pero la razón principal son las posibilidades de la plataforma.
¿Qué es GitHub y en qué se diferencia de Git?
GitHub es una plataforma en la nube para alojar proyectos de TI y desarrollo colaborativo, que utiliza la popular sistema de control de versiones Git, además de ser una red social completa para desarrolladores.
Aquí puedes encontrar muchos proyectos de código abierto en diferentes lenguajes y participar en ellos, colocar tu portafolio con ejemplos de código para añadir un enlace a tu currículum, observar soluciones arquitectónicas interesantes en proyectos abiertos, ver cómo los desarrolladores experimentados escriben código y descargar una gran cantidad de herramientas útiles y gratuitas para el desarrollo. Por cierto, algunos usuarios logran reunir en GitHub bibliotecas enteras de libros y artículos, ¡no solo librerías de programación! 🙂
Y sí, si no estás contento con algunas funciones de tu programa abierto favorito y está subido a GitHub, siempre puedes ir y quejarte en los comentarios del proyecto 🙂 O mejor aún, crea un issue (te explicaremos qué es) y soluciona el problema tú mismo para la alegría de todos los usuarios. No olvides agradecer a los autores de los proyectos abiertos geniales, con donaciones o simplemente con palabras amables. Se lo agradecerán mucho.
Al entrar en casi cualquier empresa de TI, te encontrarás con que el código se almacena en algún lugar, y en la gran mayoría de los casos, ese “lugar” será GitHub. GitHub tiene un competidor bastante conocido: GitLab, también basado en Git, pero son plataformas diferentes de compañías diferentes, aunque su funcionalidad es muy similar.
[Lista completa de clientes Git con interfaz gráfica]
¿Suena genial? Entonces, comienza con nuestra guía sobre cómo usar GitHub para entenderlo todo y comprender si lo necesitas ahora mismo.
¿Cómo saber si necesitas GitHub?
Sin duda, GitHub no lo necesitan todos. Por ejemplo, si todavía estás aprendiendo a programar o estás haciendo un pequeño proyecto para uso personal, te puede bastar con almacenar el proyecto en tu equipo local. Quizás ahora simplemente estás aprendiendo un lenguaje que te gusta y, en esta etapa, no quieres abarcar demasiado.
GitHub es necesario, en primer lugar, para proyectos con actualizaciones frecuentes, muchas versiones, una gran cantidad de archivos, la necesidad de sincronizar el desarrollo y un despliegue cómodo.
Aunque hay excepciones: incluso algunos de los desarrolladores clave del núcleo (kernel) de Linux todavía intercambian actualizaciones de código mediante correo electrónico y archivos comprimidos 🙂
De hecho, hay muchas otras formas de almacenar código fuente: puedes crear una carpeta en la sección “Mis documentos”, subirlos a la nube y firmar las versiones, o incluso subirlos a “Favoritos” en Telegram o una nube (engorroso, sí, pero es posible).
También puedes añadir una lista de cambios en notas en tu teléfono/en la nevera, en texto, en un canal privado de Telegram. Puedes desplegar un proyecto simplemente descargando y descomprimiendo un archivo ZIP con los archivos de tu programa (especialmente si el objetivo es simplemente mostrarle el programa a un amigo o a una novia a la que has ido a “ayudar con el portátil” ^_^). Al fin y al cabo, puedes informar de errores en tu framework favorito a la comunidad de anónimos en un grupo público de Fb: ¡protestar juntos es muy divertido.
Todas estas formas son buenas a su manera, pero para trabajar en TI, debes acostumbrarte a GitHub: es el estándar de la industria.
La mayor parte de las funciones necesarias de GitHub son gratuitas, aunque la plataforma también tiene planes de pago, pero puedes no necesitarlos durante mucho tiempo, ya que las funciones gratuitas suelen ser suficientes para un desarrollador común.
Conceptos básicos de GitHub en palabras sencillas
A los principiantes, la interfaz de GitHub puede resultar confusa: con los años, desde su creación, la plataforma ha ido añadiendo muchas herramientas, pero lo principal sigue siendo lo mismo.
Casi toda la terminología se hereda de Git. Los términos principales son repositorio, rama, commit, fork. La elección de algunos de estos nombres puede parecer poco intuitiva (incluso si dominas el inglés), pero así es como se ha establecido.
Cómo subir archivos, crear repositorios y realizar otras operaciones, lo veremos en la siguiente sección, así que no te asustes si se mencionan diferentes acciones en las definiciones de los términos: ¡lo mostraremos todo con imágenes! 🙂
Repositorio
Es simplemente la carpeta raíz con los archivos y subcarpetas de tu programa, y al mismo tiempo, su página en GitHub. Puedes subir al repositorio cualquier cosa, pero se supone que guardarás en él archivos con el código fuente y algunos materiales adicionales, como la gráfica necesaria para la interfaz gráfica de usuario o el diseño (imágenes, iconos, etc.).
Los repositorios pueden ser públicos y privados, en ellos puedes crear otras carpetas y realizar un seguimiento de los cambios de versión. Puedes gestionar tus repositorios directamente a través de la interfaz del sitio web, la línea de comandos, la aplicación de escritorio de GitHub o diversas herramientas de desarrollo (IDE) que admiten la integración con el servicio.
Rama (branch)
En las ramas se agrupan los cambios y las actualizaciones; por ejemplo, una rama principal (por defecto se crea main) y una beta. Las ramas son independientes entre sí, pero si lo deseas, puedes combinarlas (merge – fusión), incluso si hay diferencias en el código entre ellas.
Formas de modificar un repositorio: commit, push, clone, fork
Puedes introducir cambios en el contenido de un repositorio directamente o creando una copia. El proceso de introducir cambios se llama “commit” (de la palabra inglesa commit – realizar), tiene una marca de tiempo y una suma de comprobación.
La transferencia de cambios-commits desde un repositorio local (en tu PC) a uno remoto (remote repository, es decir, en este caso, a GitHub) se denomina “push” (push) – de la palabra inglesa “empujar” (literalmente – “introducir” los cambios).
Puedes copiar un repositorio para introducir cambios en una copia de dos maneras principales:
- Clonar (clone) – es decir, simplemente copiarlo a un equipo local o servidor;
- O hacer un fork (de la palabra inglesa fork – bifurcación) – hacer una copia separada del repositorio (normalmente de otro usuario) para continuar el desarrollo “por otro camino de la bifurcación”.
Si has hecho un fork de un proyecto ajeno para sugerir al autor mejoras concretas, cuando esté listo, debes “subirlo” al repositorio original, es decir, hacer una pull request (petición de cambios).
Estos son el 90% de los datos necesarios. Los detalles más aburridos se describen en la documentación y en la sección de aprendizaje de GitHub, así como en la guía de Git en sí, pero nosotros intentaremos aplicar todo esto en la práctica.
Creación de un repositorio y carga de archivos
Por supuesto, la forma más sencilla de usar GitHub es a través del sitio web, así que empezaremos por ahí.
Las acciones más típicas al trabajar con un repositorio son su creación y la carga de archivos, que ya hemos visto anteriormente. Es fácil comprobar que ambas tareas no tardan más de 30 segundos.
Repasamos brevemente las conclusiones de nuestro material anterior:
- Para crear un repositorio, debes hacer clic en el “+” en la esquina superior derecha del sitio web, seleccionar el elemento New Repository, rellenar el nombre y la descripción, marcar las casillas necesarias y hacer clic en Create Repository;
- Para cargar archivos, debes acceder al repositorio necesario, hacer clic en Add file y seleccionar Upload files.
Pero para aprender el lado oscuro de la Fuerza el trabajo con GitHub, es útil practicar también otras acciones necesarias durante el proceso de desarrollo: clonar/fork, fusionar ramas, ver y resolver conflictos, etc.
Vamos a recorrer todo esto paso a paso, primero a través del sitio web, y luego echaremos un vistazo a cómo funciona con los clientes GUI y la interfaz de línea de comandos (CLI).
Visualización de archivos en un repositorio
Tienes que admitir que, en algunos casos, es conveniente no descargar el código fuente, sino simplemente echarle un vistazo rápido. Para estas operaciones sencillas, no necesitas un cliente de escritorio: todos los archivos se pueden abrir rápidamente en la versión web (tanto el código como las imágenes). ¡Simplemente haz clic en ellos para verlos!
Búsqueda y lectura de repositorios
Aunque navegar por repositorios ajenos es una pérdida de tiempo, en primer lugar, es una forma de encontrar herramientas útiles para ayudarte. Ya alguien ha trabajado en muchas de las funciones que te gustaría añadir a tu aplicación, solo tienes que encontrar los repositorios de GitHub de esos proyectos.
Al igual que en otros casos de búsqueda, puedes acceder al repositorio necesario desde un buscador o a través de la búsqueda interna de GitHub.
Por ejemplo: este es el repositorio oficial de GitHub de la aplicación Android de Telegram. Veamos los detalles: la breve descripción es “— About (Telegram for Android source)”, tiene dos ramas (
masterydev), la ramamastertiene 545 commits, 127 pull requests, la última versión se lanzó en 2024, la licencia es GPL 2.0, 1200 usuarios lo siguen, 8300 forks y ¡26100 estrellas!
Lo más importante es saber en qué fijarse. Analicemos algunos puntos de la captura de pantalla anterior.
En primer lugar, lo más obvio es la descripción de la página principal. En ella se encuentra la respuesta a tu pregunta principal: qué es y cómo puede ayudarte.
Más concretamente, hay dos descripciones de los repositorios: una breve (un párrafo en la parte superior derecha) y una completa (en el centro, debajo de la lista de archivos).
Si el repositorio parece útil, a continuación, debes comprender en qué condiciones puedes utilizarlo, lo que depende de la licencia indicada por el autor.
Después de esto, evalúa si te conviene la frecuencia de las actualizaciones; esto se puede hacer en la sección Releases (enlace justo debajo de la descripción breve). Por supuesto, esto depende de la situación: en algunos casos puede ser útil una herramienta que no se ha actualizado en cuatro años, pero normalmente se necesita al menos un soporte mínimo, es decir, actualizaciones al menos cada pocos meses.
Es importante saber dónde ver el número y el contenido de los commits; el contador con posibilidad de clic se encuentra sobre la lista de archivos de la derecha.
Por último, también debes mirar el número de marcas que muestran la popularidad del proyecto entre la comunidad: seguimientos, forks y estrellas (en cierto modo, son análogos locales de los “me gusta” y los “compartir”).
Un poco más abajo a la derecha se encuentra una de las cosas más interesantes: un análisis de los lenguajes de programación utilizados en el repositorio. En el repositorio de la captura de pantalla anterior, el conjunto tiene este aspecto.
En general, es bueno estudiar los repositorios de aplicaciones conocidas que usas tú mismo (como en la captura de pantalla anterior) y marcar las que te gusten con estrellas. Esto no solo es interesante, con el tiempo GitHub aprenderá tus preferencias y empezará a ofrecerte en el bloque Explore lo que te pueda gustar.
Creación de ramas
Crear una nueva rama es muy sencillo:
- Haz clic en el gran botón verde New branch.
- Introduce el nombre de la nueva rama.
- Selecciona la rama de origen para copiar (es decir, main, ya que por ahora no hay otras).
- Haz clic en Create new branch.
Cambio de ramas y resolución de conflictos
En este caso, primero hay que aclarar qué se entiende: si simplemente necesitas entrar en una rama alternativa, puedes hacerlo en la lista de ramas del repositorio (el enlace necesario está sobre la lista de archivos).
Creemos también una rama alternativa nº 2 (demo) y veamos cómo se ve todo al final.
También se puede hablar del cambio entre ramas en otro sentido: cuando los cambios de una rama alternativa se fusionan con la rama principal. Mira: tenemos el archivo scripts.js, pero su contenido es ligeramente diferente:
- En la rama main no hay comando JS console.log;
- Sin embargo, en la rama articulo, el mismo archivo contiene el comando console.log(“Rama por defecto”);
- Y todo se complica aún más con la tercera rama demo, donde la salida de la consola es console.log(“¡Demo!”);
Resulta que hay un conflicto entre las ramas y no se puede fusionar ninguna de las ramas alternativas con la principal. Pero para eso ya hay una solución: GitHub nos ofrece comparar las ramas en conflicto, y si queremos, también subir los cambios a la principal, es decir, hacer esa pull request de la que hemos hablado antes.
Así es como se ve la comparación de ramas (con articulo y demo respectivamente).
Supongamos que decidimos aceptar los cambios de la rama sava y creamos una pull request con un pequeño comentario.
A continuación, aparece en la lista de pull requests del repositorio, donde determinamos el destino posterior de esta solicitud de cambios.
La pull request se puede aceptar definitivamente, confirmando la fusión (merge) de las ramas, o rechazar, cerrando la solicitud (Close pull request).
Al mismo tiempo, la rama principal main se puede proteger de los cambios, activando las opciones correspondientes en la configuración del repositorio (lo que se te sugerirá al crear nuevas ramas).
Para cambiar esta serie de parámetros, accede en tu repositorio a la sección Settings -> Branches. La configuración necesaria se encuentra en la subsección Branch protection rules (hasta 10 casillas para elegir).
Configuración de la descripción de un repositorio
La descripción principal de tu proyecto de GitHub se establece en el archivo Readme.md, que puedes crear junto con el repositorio o después. La extensión md es simplemente una abreviatura del nombre del popular lenguaje de marcado simplificado de contenido: Markdown.
El contenido del archivo Readme se muestra en la página principal del repositorio y responde a la pregunta de qué es este proyecto, cómo puede ser útil a otros desarrolladores y cómo utilizarlo.
Para diseñar el Readme con gusto, puedes utilizar la guía de GitHub sobre el marcado Markdown. Así es como se verá el Readme de nuestro repositorio de ejemplo después de la mejora.
Ten en cuenta que en el diseño puedes usar cualquier cosa: encabezados de diferentes niveles, negrita/cursiva, imágenes, emojis, enlaces, etc.
El archivo Readme puede ser bastante largo, pero para la documentación extensa, GitHub recomienda crear una “Wiki”.
Creación de un sitio web desde tu perfil de GitHub
Puedes alojar un sitio web en GitHub utilizando la función GitHub Pages. Es muy sencillo:
- Accede a la configuración (Settings) del repositorio.
- En el bloque Code and automation, selecciona Pages.
- Selecciona el origen (Deploy from a branch, luego la rama necesaria).
- Haz clic en Save.
- Actualiza la página y en la parte superior de la página aparecerá un enlace a tu nuevo sitio web.
En el caso de crear un sitio web para promocionarte a ti mismo, no al proyecto, simplemente crea un repositorio con el código del sitio web de presentación y dale un nombre como [nombre de usuario].github.io, donde nombre de usuario es el nombre de tu cuenta en GitHub. Más información sobre esta función aquí.
Conexión del cliente GUI GitHub Desktop
Si te resulta más cómodo este método de trabajo, aquí también es sencillo. Una vez más, repasaremos brevemente las conclusiones de nuestra guía más detallada sobre este tema:
- Descarga e instala el cliente.
- Inicia sesión en tu cuenta.
- Trabaja con los repositorios existentes o crea otros nuevos (locales).
La aplicación te ofrece clonar el repositorio en tu equipo local para seguir trabajando, lo que haremos.
Los archivos clonados desde el repositorio remoto de GitHub se almacenan en una carpeta especial de tu equipo, y es fácil introducir cambios en ellos: el cliente los abrirá en el editor de código/entorno de desarrollo que hayas seleccionado (aunque es más cómodo hacerlo por separado: seleccionando el archivo fuente necesario en la carpeta).
En general, todo es sencillo, como uno-dos-tres.
Trabajo con GitHub a través de CLI
También puedes trabajar con GitHub a través de la línea de comandos de Windows o PowerShell. No es muy complicado: para empezar, también debes descargar e instalar la interfaz de línea de comandos (documentación aquí).
Los comandos para GitHub CLI empiezan con la abreviatura gh, por ejemplo, gh repo clone.
Hay otra opción: utilizar Git en sí y trabajar a través de su propia CLI. Git se descarga e instala por separado, tiene una GUI minimalista, pero es más lógico utilizarla en el terminal.
Lo principal que debes saber al respecto: todos los comandos de Git empiezan, respectivamente, con la palabra git, después de lo cual se indica el tipo de acción: git clone, git merge, git fork, etc. Para utilizarlos, instala Git, imprime cualquier ayuda sobre sus comandos y empieza a usarlos con valentía.
Lee también: 30 Comandos Básicos de Git que debes Conocer
Configuración del perfil de GitHub
La personalización del perfil es una parte importante de la autopresentación de un desarrollador: currículum, tarjeta de presentación y escaparate de proyectos en los que has trabajado.
Esta información es evaluada por los empleadores, por lo que merece la pena rellenar la información sobre ti y hacer públicos algunos de tus mejores repositorios (por supuesto, si no hay nada secreto :)) – precisamente ellos formarán parte de tu escaparate personal.
Veamos el perfil de algún desarrollador genial de los que están de moda en GitHub (sí, sí, hay una sección así).
En primer lugar, se encuentra Peter Steinberger. ¿Y qué hay en su perfil? Se indica el lugar de trabajo, hay sitios web y contactos, y en las estadísticas, 84 repositorios y 4,443 cambios (contribuciones) en los repositorios en un año (todo el año). Es decir, a simple vista se ve que la persona es al menos activa y experimentada.
Incluso si todavía no estás en el top de GitHub, debes aspirar a un relleno de perfil similar: información detallada + una serie demostrativa de proyectos (puedes fijarlos a tu manera, haciendo clic en Customize your pins en tu propio perfil).
En lugar de end()
Todo no es tan complicado como puede parecer (hablando metafóricamente, cada desarrollador en su vida primero aprende a comer con un tenedor y luego a hacer un fork de repositorios de GitHub).
GitHub lo usan todos: es una de las habilidades generales importantes, independientemente del lenguaje de programación y el área de desarrollo que elijas. Y, al igual que las lecciones escolares de primeros auxilios, git clone te salvará algún día.
Por lo tanto, es importante empezar a usar GitHub lo antes posible, aunque sea solo para hacer copias de seguridad del código de aprendizaje, y pronto se convertirá en un hábito útil.
