GitHub

Presentación

Modificas tres archivos.

Haces un commit.

Subes todo a un repositorio.

A partir de ahí, el código puede revisarse, comentarse, probarse automáticamente, vincularse a una issue, integrarse en una release, desplegarse, analizarse en busca de vulnerabilidades y, cada vez más, confiarse a agentes capaces de continuar parte del trabajo.

El commit era solo el principio.

Probablemente sea la mejor manera de entender GitHub.

Git no es GitHub

La confusión es fácil porque ambos nombres aparecen casi siempre en la misma frase.

Git es el sistema de control de versiones distribuido que permite seguir la evolución de un proyecto, crear ramas y fusionar cambios.

GitHub es una plataforma construida alrededor de esa mecánica.

Desarrollada por GitHub, Inc., aloja repositorios y añade todo un entorno alrededor del código: cuentas, organizaciones, discusiones, revisiones, automatización, seguridad, paquetes, documentación, entornos de desarrollo, gestión de proyectos e inteligencia artificial.

Se puede utilizar perfectamente Git sin GitHub.

Pero GitHub consiguió algo más difícil: transformar el control de versiones en un espacio de trabajo colectivo.

El repositorio como centro del proyecto

En GitHub, el repository no es simplemente una carpeta remota que contiene código.

Se convierte en el punto de encuentro de varias capas:

Esta proximidad cambia muchas cosas.

Una issue puede llevar a una rama.

La rama, a una pull request.

La pull request, a un workflow de pruebas.

Los resultados del workflow vuelven a la pull request.

El merge puede activar una release o un despliegue.

Todo permanece vinculado al mismo proyecto.

GitHub no sustituye a Git. Construye todo lo que puede ocurrir a su alrededor.

Del open source a la infraestructura empresarial

GitHub también tiene una identidad algo particular.

Es al mismo tiempo una plataforma profesional y un gigantesco espacio público.

Un estudiante puede publicar allí su primer proyecto.

Una biblioteca open source puede recibir contribuciones de todo el mundo.

Una empresa puede gestionar miles de repositorios privados, imponer políticas de seguridad, controlar accesos y automatizar despliegues.

La mecánica básica sigue siendo sorprendentemente parecida.

Las restricciones, evidentemente, mucho menos.

GitHub ofrece así varios niveles: Free, Pro, Team y Enterprise, con una oferta Enterprise disponible en la nube, pero también mediante GitHub Enterprise Server autoalojado.

Esta amplitud explica en parte su posición dentro del ecosistema.

Puedes empezar gratuitamente con un repositorio personal.

Y unos años después encontrarte administrando toda una cadena de desarrollo sin haber salido realmente de la plataforma.

Funcionalidades

Repositorios, ramas e historial

El repository sigue siendo el corazón de GitHub.

Un repositorio puede ser público o privado y contener el código, su historial Git, documentación y distintos archivos utilizados para configurar los servicios asociados.

GitHub añade sobre Git una interfaz para explorar:

• archivos y carpetas;
• commits;
• ramas y tags;
• colaboradores;
• diferencias entre versiones;
• releases;
• forks.

Las operaciones complejas siguen estando disponibles mediante línea de comandos.

Pero muchas acciones también pueden realizarse desde el navegador, GitHub Desktop, GitHub CLI o herramientas de terceros.

Esta diversidad es importante.

GitHub no impone realmente una única forma de trabajar con Git.

Pull requests: hacer visible el cambio

La pull request es probablemente la idea que mejor representa GitHub.

Una rama contiene una modificación.

La pull request la transforma en una conversación.

Se puede ver exactamente qué cambia, comentar líneas concretas, pedir correcciones, iniciar revisiones, vincular el trabajo a una issue y comprobar los resultados de las pruebas antes de autorizar el merge.

Reúne así tres cosas que antes estaban mucho más separadas:

el código, la discusión y la decisión.

Los equipos pueden ir más lejos con ramas protegidas, reviewers obligatorios, CODEOWNERS o reglas de repositorio para que un cambio solo pueda fusionarse después de determinadas validaciones.

El botón verde «Merge» parece sencillo.

Lo importante es todo lo que puede exigirse antes de poder pulsarlo.

Issues y Projects: el trabajo alrededor del código

No todos los problemas de un proyecto empiezan con una línea de código.

Una Issue puede representar un bug, una mejora, una idea, una pregunta o una tarea.

Puede recibir labels, responsables, hitos, sub-issues y dependencias.

GitHub Projects permite después organizar ese trabajo en distintas vistas y relacionar la planificación directamente con las issues y pull requests.

No sustituye necesariamente a Jira, Linear o un sistema especializado de gestión de proyectos.

Pero para muchos proyectos de software, la proximidad con el repositorio es precisamente lo que le da valor.

Una tarea no queda simplemente descrita en algún sitio.

Puede permanecer vinculada al cambio que finalmente la resuelve.

GitHub Actions: cuando el repositorio empieza a reaccionar

Un desarrollador hace push de un commit.

Unos segundos después, varias máquinas empiezan a trabajar.

Las pruebas se ejecutan.

El lint revisa el código.

Una aplicación se compila.

Se puede construir un paquete.

Se puede preparar una release.

Puede comenzar un despliegue.

GitHub Actions permite definir estas automatizaciones mediante workflows YAML almacenados directamente en el repositorio.

El desencadenante puede ser un push, una pull request, una release, una planificación, una acción manual o muchos otros eventos.

Esta integración es una de las grandes fortalezas de GitHub.

La automatización ya no es un sistema externo que haya que conectar penosamente al proyecto.

Vive a unas pocas carpetas del código que está comprobando.

Codespaces: abrir el proyecto antes incluso de preparar la máquina

Configurar un entorno de desarrollo puede llevar a veces más tiempo que entender el bug que queríamos corregir.

Versión de Python.

SDK.

Extensiones.

Variables.

Dependencias del sistema.

Y después el famoso archivo de configuración que falta porque «evidentemente ya estaba en la máquina de Paul».

GitHub Codespaces traslada ese entorno a la nube.

Un proyecto puede definir su configuración mediante un dev container y permitir que un desarrollador abra un entorno ya preparado desde el navegador o desde un editor compatible.

Para las cuentas personales, GitHub incluye una cuota mensual de cálculo y almacenamiento según el plan.

Una vez superada, el uso pasa a ser facturable si se ha configurado un presupuesto.

Codespaces no es, por tanto, simplemente «VS Code en un navegador».

Es sobre todo una manera de hacer que el entorno de desarrollo sea reproducible y desechable.

Seguridad: vigilar lo que el repositorio lleva consigo

Un proyecto moderno rara vez contiene únicamente código escrito a mano.

Depende de decenas, a veces miles, de paquetes.

Manipula tokens.

Construye artefactos.

Recibe código externo.

GitHub dispone por ello de varias capas de seguridad integradas.

Dependabot puede señalar dependencias vulnerables y proponer actualizaciones.

El secret scanning busca claves API, tokens y otros identificadores expuestos.

La push protection puede impedir que determinados secretos lleguen al repositorio.

El code scanning, especialmente mediante CodeQL, analiza el código en busca de vulnerabilidades.

La disponibilidad exacta de estas funciones varía según si el repositorio es público o privado y según los productos de seguridad activados.

Pero la lógica general resulta interesante:

La seguridad se acerca al momento en que se escribe el código, en lugar de esperar al final del proyecto para descubrir lo que se ha colado dentro.

Packages, Releases y Pages

GitHub también acompaña lo que ocurre después del código.

GitHub Packages permite alojar distintos tipos de paquetes.

Las Releases estructuran las versiones distribuidas de un proyecto con notas y archivos asociados.

GitHub Pages puede publicar un sitio web estático directamente desde un repositorio.

Estas funciones no sustituyen a todas las plataformas especializadas de distribución o alojamiento.

Pero refuerzan una idea que atraviesa todo GitHub:

mantener la mayor parte posible del ciclo de vida del software alrededor del mismo proyecto.

Copilot: la IA entra en el repositorio

GitHub Copilot ha ido mucho más allá del simple autocompletado.

El ecosistema Copilot incluye ahora conversaciones, sugerencias de código, modo agente, revisión de código y agentes capaces de recibir determinadas tareas relacionadas con issues o pull requests.

Los agentes pueden iniciarse desde distintas superficies de GitHub y trabajar alrededor de un repositorio antes de proponer sus cambios mediante una pull request.

Copilot sigue siendo, sin embargo, un producto independiente, con sus propios planes, cuotas y mecanismos de facturación.

La diferencia importa.

GitHub puede utilizarse perfectamente sin Copilot.

Pero la IA está ahora lo bastante integrada en la plataforma como para cambiar la manera de imaginar el workflow.

El repositorio ya no acoge únicamente humanos y automatizaciones deterministas.

Empieza también a acoger agentes.

Casos de uso

Publicar tu primer proyecto sin construir una infraestructura

Acabas de terminar una pequeña aplicación.

Funciona.

Bueno, en tu máquina.

Ya es un excelente comienzo.

Crear un repositorio en GitHub permite conservar el historial del proyecto, publicar el código si se desea, redactar un README y disponer inmediatamente de un espacio capaz de alojar issues, releases y contribuciones.

Para un proyecto personal o estudiantil, el plan gratuito ya ofrece más que suficiente para empezar.

Y, sobre todo, el proyecto obtiene una dirección.

Algo que se puede mostrar, clonar, seguir y hacer evolucionar.

Colaborar sin enviarse archivos llamados final_v7_ahora_si_final

Dos desarrolladores trabajan sobre la misma funcionalidad.

Cada uno crea su rama.

Las modificaciones llegan mediante una pull request.

Las diferencias son visibles.

Los comentarios permanecen vinculados a las líneas correspondientes.

Las pruebas se ejecutan automáticamente.

Cuando todo está validado, el cambio llega a la rama principal.

Ningún archivo ZIP enviado por Discord.

El progreso humano a veces está hecho de pequeñas victorias.

Construir y probar una aplicación en varios sistemas

Una aplicación debe funcionar en Linux y Windows.

Sin embargo, el desarrollador solo tiene una máquina delante.

GitHub Actions puede ejecutar distintos jobs en varios runners, instalar dependencias, lanzar pruebas y producir artefactos.

La misma mecánica puede utilizarse después para generar una release o automatizar parte del despliegue.

Para un proyecto multiplataforma, GitHub se convierte entonces en algo más que un alojamiento de código.

Participa realmente en la cadena de producción.

Mantener un proyecto open source

Un proyecto público recibe una propuesta de funcionalidad.

Alguien abre una issue.

Otra persona propone una pull request.

Empieza una discusión.

Un maintainer solicita una corrección.

Las pruebas automáticas fallan.

El colaborador corrige.

La PR se pone en verde.

Merge.

Este workflow parece hoy tan normal que a veces olvidamos hasta qué punto ha estructurado la cultura moderna del desarrollo open source.

GitHub no aloja únicamente el resultado.

Aloja buena parte de la conversación que permite llegar hasta él.

Administrar el desarrollo de un equipo

A medida que un proyecto crece, la pregunta deja de ser simplemente «¿dónde guardamos el código?».

Pasa a ser:

¿Quién puede modificar esta rama?

¿Quién debe aprobar esta pull request?

¿Qué pruebas son obligatorias?

¿Qué secretos puede utilizar el pipeline?

¿Quién es responsable de esta parte del código?

¿Qué dependencias presentan vulnerabilidades?

¿Qué repositorios pertenecen a qué equipo?

Los planes Team y Enterprise añaden progresivamente controles destinados a responder a este tipo de preguntas.

GitHub pasa entonces del repositorio compartido a convertirse en infraestructura de gobernanza del desarrollo.

Opinión de PANACHES

GitHub tiene un defecto extraño: se ha vuelto tan cotidiano que apenas percibimos todo lo que contiene.

A menudo decimos:

«El proyecto está en GitHub».

Como si eso significara simplemente que hay una carpeta esperando en algún lugar de Internet.

En realidad, GitHub puede cubrir una parte considerable del ciclo de desarrollo: versionar, debatir, planificar, revisar, probar, proteger, compilar, publicar, distribuir y ahora delegar determinadas tareas a la IA.

Su verdadera fuerza: el contexto permanece unido al código

Existen excelentes herramientas especializadas para casi todas las funciones de GitHub.

Sistemas de CI más especializados.

Gestores de proyectos más potentes.

Escáneres de seguridad más profundos.

Entornos cloud diferentes.

Asistentes de IA competidores.

Tomadas individualmente, GitHub no es necesariamente la mejor herramienta absoluta en cada una de esas categorías.

Pero ese no es realmente su juego.

Su fuerza nace de la continuidad entre todas ellas.

La issue conoce la pull request.

La pull request conoce el commit.

El commit activa la Action.

La Action produce el resultado.

La seguridad analiza el mismo repositorio.

El paquete procede de ese proyecto.

La release lleva esa versión.

El contexto circula.

Y en el desarrollo de software, perder el contexto suele costar mucho más de lo que pensamos.

GitHub también es un lugar

Hay algo más.

GitHub no es únicamente una caja de herramientas.

Es un lugar donde resulta visible una enorme parte del ecosistema público de software.

Hay bibliotecas.

Frameworks.

Modelos de IA.

Aplicaciones.

Motores de juego.

Extensiones.

Proyectos diminutos.

Infraestructuras utilizadas por millones de personas.

Se puede observar cómo evoluciona un software, leer sus issues, mirar sus decisiones técnicas, seguir sus releases o descubrir una herramienta simplemente remontándose hasta su repositorio.

Para un desarrollador, saber moverse por GitHub forma casi parte de la cultura general del oficio.

La otra cara de la integración

Pero esta riqueza tiene su reverso.

Cuanto más utiliza un proyecto GitHub para repositorios, issues, Actions, Packages, Pages, Codespaces, seguridad, Copilot y gestión de equipos, menos significa migrar simplemente cambiar la URL de un remote Git.

Hay que mover una parte del propio sistema de trabajo.

Es la paradoja clásica de las plataformas integradas.

Resultan cómodas precisamente porque todas las piezas se comunican muy bien.

Y esa comunicación también es lo que hace que marcharse sea más costoso.

¿Cuándo conviene preferir otra cosa?

GitLab es la alternativa más evidente cuando se busca una plataforma DevOps integrada con grandes posibilidades de autoalojamiento.

Gitea, Forgejo o Codeberg resultan especialmente interesantes para quienes priorizan software libre, ligereza, independencia o control de la infraestructura.

Bitbucket puede seguir siendo relevante dentro de un entorno fuertemente vinculado al ecosistema Atlassian.

La elección depende, por tanto, menos de la pregunta:

«¿Qué servicio sabe alojar Git?»

Casi todos saben hacerlo.

La verdadera pregunta es:

¿Qué entorno quieres construir alrededor de tus repositorios?

Y en ese terreno, GitHub sigue siendo extremadamente difícil de ignorar.

Puntos de atención

GitHub no es open source porque Git lo sea

Probablemente sea la confusión más importante que conviene eliminar.

Git es libre y open source. GitHub no lo es.

La plataforma GitHub es un servicio propietario operado por GitHub, Inc.

Algunas piezas relacionadas con el ecosistema GitHub cuentan con su propio código open source, y GitHub aloja evidentemente una cantidad gigantesca de software libre.

Eso no convierte al servicio en sí mismo en software libre.

Las condiciones de uso especifican que GitHub y sus proveedores conservan los derechos de propiedad intelectual asociados al sitio y al servicio.

Gratuito no significa que todo sea ilimitado

El plan Free permite utilizar, entre otras cosas, repositorios públicos y privados ilimitados.

Pero varios servicios periféricos funcionan mediante cuotas.

Para una cuenta personal GitHub Free, GitHub incluye especialmente 2.000 minutos de Actions al mes, además de una cuota mensual de Codespaces.

GitHub Pro y los planes para organizaciones aumentan algunos de estos volúmenes.

Los runners estándar de Actions son gratuitos en los repositorios públicos, pero el uso en repositorios privados o de determinados recursos puede pasar a ser facturable una vez superadas las cuotas.

La misma lógica se aplica a Codespaces.

El repositorio puede ser gratuito.

La máquina que compila el repositorio no necesariamente va a trabajar gratis para siempre.

Copilot tiene su propia economía

GitHub Copilot no debe confundirse con el precio de la cuenta de GitHub.

GitHub ofrece varios planes Copilot distintos, tanto para particulares como para organizaciones.

En 2026, su uso también se basa en un sistema de GitHub AI Credits, con asignaciones que dependen del plan y posibilidad de facturación por consumo adicional.

Para alguien que utiliza intensamente agentes o modelos premium, ese consumo pasa a formar parte del coste real de la plataforma.

Dicho de otra manera:

GitHub Free puede seguir siendo gratuito mientras los servicios construidos alrededor del repositorio empiezan, ellos sí, a generar una factura.

GitHub.com y autoalojamiento no son la misma oferta

GitHub Enterprise existe en distintas formas.

GitHub Enterprise Cloud sigue estando alojado por GitHub.

GitHub Enterprise Server permite desplegar GitHub en una infraestructura controlada por la empresa.

Esto no significa que la versión estándar de GitHub.com pueda descargarse simplemente e instalarse gratuitamente en un servidor propio.

El autoalojamiento pertenece a la oferta Enterprise.

Para un particular o un pequeño proyecto que busque ante todo una forge libre autoalojable, Gitea, Forgejo o GitLab pueden resultar más naturales.

Los workflows de Actions merecen la misma atención que el código

GitHub Actions es extremadamente práctico.

Y precisamente por eso resulta muy fácil acabar ejecutando muchas cosas automáticamente.

Un workflow puede acceder al código, ejecutar comandos, manipular artefactos, utilizar tokens y, en algunos casos, disponer de secretos que le permiten comunicarse con servicios externos.

Los permisos, secretos y Actions de terceros utilizados en un pipeline deben tratarse, por tanto, como una parte sensible del proyecto.

Automático no significa inofensivo.

Solo significa que el error puede funcionar por sí solo.

Hacer privado un repositorio no elimina todas las cuestiones de confianza

Un repositorio privado limita su acceso a las personas y sistemas autorizados.

Sin embargo, en el caso de GitHub.com, sigue estando alojado por un proveedor externo.

Las condiciones del servicio describen cómo GitHub trata esos contenidos y prevén determinados casos de acceso, especialmente para prestar el servicio, cumplir obligaciones legales, realizar tratamientos automatizados o responder a riesgos de seguridad.

Para la mayoría de proyectos, esto puede constituir un compromiso perfectamente aceptable.

Para determinados entornos regulados, soberanos o extremadamente sensibles, la ubicación de los datos y el control de la infraestructura pueden convertirse en criterios decisivos.

Centralizar simplifica el día a día y a veces complica la salida

Git es distribuido.

Un clon local conserva el historial del código.

Es una excelente protección contra un encerramiento completo.

Pero el resto de GitHub no está contenido en un simple git clone.

Issues.

Pull requests.

Discussions.

Projects.

Actions.

Secrets.

Packages.

Reglas.

Permisos.

Configuración de seguridad.

Cuantas más de estas capas se utilizan, más exige una migración mover el proyecto alrededor del código, y no únicamente el código.

No es una razón para evitar GitHub.

Es una razón para entender qué decidimos construir dentro de él.

Tu repositorio Git puede viajar fácilmente. Tu workflow completo, mucho menos.