GitHub: Qué Es, Para Qué Sirve y Cómo Usarlo de Verdad

Mucha gente aprende Git y GitHub como si fueran la misma cosa. No lo son — y entender la diferencia es el primer paso para usar bien ambos.

• Git es el sistema de control de versiones. Corre en tu máquina, funciona sin conexión y es quien de hecho guarda el historial del código.
• GitHub es una plataforma en internet construida alrededor de Git. Aloja repositorios y añade lo que Git no tiene: colaboración, revisión de código, automatización, publicación y una red social de desarrolladores.

Puedes usar Git toda la vida sin GitHub. Lo que pierdes es todo lo que ocurre entre personas.

Índice

• 1 · Por qué existe GitHub
• 2 · El repositorio: la unidad de todo
• 3 · El flujo de trabajo en la práctica
• 4 · Pull Request: donde se revisa el código
• 5 · Issues y organización del trabajo
• 6 · GitHub Actions: automatización y CI/CD
• 7 · Releases, Pages y Packages
• 8 · Seguridad
• 9 · GitHub como portafolio
• 10 · Alternativas y cuándo elegir otra

1. Por qué existe GitHub

Git resuelve el versionado, pero deja tres preguntas abiertas:

1. ¿Dónde está la copia oficial? Si el código solo existe en tu máquina, un disco quemado da por terminado el proyecto.
2. ¿Cómo le propongo un cambio a otra persona? Git tiene format-patch y correo — funciona, pero viene de la época en que Linux se desarrollaba por lista de correo.
3. ¿Cómo garantizo que nadie rompa la build? Git no ejecuta pruebas, no bloquea merges, no avisa a nadie.

GitHub responde a las tres: un repositorio remoto como fuente de la verdad, el pull request como forma estandarizada de proponer un cambio y Actions para automatizar la verificación y el despliegue.

2. El repositorio: la unidad de todo

Un repositorio ("repo") es el proyecto: código, historial, documentación y configuración.

• Público — cualquiera lo ve y lo clona. Es lo que sostiene el open source.
• Privado — solo quien tú autorices. Gratuito e ilimitado desde 2019, incluso en cuenta personal.

Tres archivos definen la primera impresión de tu repositorio:

README.md          # qué es, cómo ejecutarlo, cómo contribuir — se convierte en la portada del repositorio
.gitignore         # lo que nunca debe versionarse (node_modules, .env, build)
LICENSE            # sin licencia, "público" no significa "libre para usar"

Un repositorio público sin licencia es, jurídicamente, "todos los derechos reservados". Si quieres que usen tu código, elige una licencia — MIT y Apache 2.0 son las más comunes.

Y el aviso que vale por todos: nunca hagas commit de un secreto. Un token, una contraseña o una clave privada en un repositorio público son rastreados por bots en minutos. Si ya pasó, revoca la credencial antes que nada — borrar el commit no basta, porque ya fue leída.

3. El flujo de trabajo en la práctica

El ciclo que usa prácticamente todo equipo:

# 1. Trae el estado actual de la rama principal
git switch main
git pull

# 2. Crea una rama para tu tarea
git switch -c feat/filtro-por-assunto

# 3. Trabaja en commits pequeños y descriptivos
git add .
git commit -m "feat(blog): filtro por assunto na listagem"

# 4. Publica la rama
git push -u origin feat/filtro-por-assunto

# 5. Abre el Pull Request (desde el sitio o desde el gh CLI)
gh pr create --fill

¿Por qué una rama en lugar de hacer commit directo en main? Porque main debería estar siempre publicable. Todo cambio pasa por un lugar donde puede revisarse, probarse y deshacerse sin afectar a quien depende de él.

El gh CLI

GitHub tiene un cliente de línea de comandos que te evita ir al navegador:

gh auth login                          # autentica la máquina
gh repo create meu-projeto --private   # crea el repositorio
gh repo clone usuario/projeto
gh pr create --fill                    # abre un PR con título/cuerpo de los commits
gh pr list
gh pr checkout 42                      # baja el PR de otra persona para probarlo
gh pr review 42 --approve
gh pr merge 42 --squash --delete-branch
gh issue create --title "Bug no filtro" --body "Passos para reproduzir..."
gh run list                            # ejecuciones de Actions
gh run watch                           # sigue la ejecución actual

4. Pull Request: donde se revisa el código

El Pull Request (PR) es el corazón de GitHub. Dice: "tengo estos cambios en esta rama y quiero integrarlos en aquella; revisadlos".

Un PR reúne en un solo lugar:

• el diff completo, comentable línea a línea;
• la discusión sobre las decisiones;
• el resultado de la automatización (pruebas, lint, build, vista previa del despliegue);
• las aprobaciones exigidas antes del merge.

Qué hace bueno a un PR:

Tres formas de fusionar, y cuándo usar cada una:

• Merge commit — conserva todos los commits y registra la integración. Bueno cuando el historial de la rama tiene valor.
• Squash and merge — junta todo en un solo commit en main. Lo habitual en la mayoría de los equipos: historial limpio, un commit por funcionalidad.
• Rebase and merge — reaplica los commits sin commit de merge. Historia lineal, pero reescribe los hashes.

Protección de rama

En la configuración del repositorio defines las reglas de main:

• exigir PR (bloquear el push directo);
• exigir N aprobaciones;
• exigir que pasen los checks de CI;
• exigir la rama actualizada antes del merge;
• exigir commits firmados.

Es lo que convierte la buena intención en proceso. Sin eso, el "quedamos en abrir siempre un PR" dura hasta el primer viernes apretado.

5. Issues y organización del trabajo

Las issues son las tareas, los bugs y las ideas del proyecto — cada una con su discusión, responsable, etiquetas y hito.

# En el cuerpo del commit o del PR, esto cierra la issue automáticamente al fusionar:
git commit -m "fix: corrige contraste do tema claro

Closes #42"

Recursos que vale la pena conocer:

• Labels — bug, enhancement, good first issue. La última es la invitación clásica para nuevos colaboradores.
• Milestones — agrupan issues por entrega o versión.
• Projects — un tablero estilo kanban conectado a las issues y los PR, que se mueven solos según cambia el estado.
• Discussions — para dudas y propuestas abiertas, sin ensuciar las issues con lo que no es una tarea.
• Templates — .github/ISSUE_TEMPLATE y PULL_REQUEST_TEMPLATE.md estandarizan lo que necesitas recibir.

6. GitHub Actions: automatización y CI/CD

Actions ejecuta tareas automáticamente cuando algo ocurre en el repositorio: un push, un PR abierto, una etiqueta creada, una hora del día.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  verificar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Con eso, todo PR llega al revisor ya con lint, pruebas y build verificados. Los usos más comunes:

• CI — probar y validar cada cambio.
• CD — publicar automáticamente al fusionar en main.
• Programado (on: schedule) — rutinas periódicas, como comprobar enlaces rotos o actualizar dependencias.
• Calidad — cobertura, análisis estático, verificación de licencias.

Dos consejos que evitan dolor: usa secrets para las credenciales (nunca escribas un token en el YAML) y fija la versión de las actions (@v4, o mejor, el hash del commit) para que la actualización de un tercero no te sorprenda.

7. Releases, Pages y Packages

• Releases — empaquetan una etiqueta con notas de versión y binarios. Es donde el usuario descarga la versión lista, sin necesidad de entender Git.
• GitHub Pages — alojamiento estático gratuito directamente desde el repositorio. Perfecto para documentación, landing page y portafolio.
• Packages — registro de paquetes (npm, Docker, Maven, NuGet) integrado con los permisos del repositorio.
• Gists — fragmentos de código sueltos, versionados, públicos o secretos. Ideales para compartir un script.

gh release create v1.2.0 --generate-notes
gh release upload v1.2.0 ./dist/app.zip

8. Seguridad

GitHub incorpora varias capas de protección — y la mayoría solo hay que activarlas:

• Dependabot — abre un PR automático cuando una dependencia tuya tiene una vulnerabilidad conocida o una versión nueva.
• Secret scanning — detecta un token subido y, en muchos casos, avisa al proveedor para que lo revoque.
• Code scanning (CodeQL) — análisis estático que busca patrones de vulnerabilidad en tu código.
• Security advisories — canal privado para que alguien reporte un fallo sin exponer el problema al mundo.
• 2FA obligatorio — desde 2023 para quien contribuye con código en la plataforma.

Y de tu lado: usa SSH o un token con el alcance mínimo, nunca la contraseña; y prefiere los fine-grained tokens, que dan acceso a repositorios concretos en lugar de a toda la cuenta.

# Clave SSH: genérala, añádela al agente y registra la pública en GitHub
ssh-keygen -t ed25519 -C "voce@email.com"
ssh-add ~/.ssh/id_ed25519
gh ssh-key add ~/.ssh/id_ed25519.pub
ssh -T git@github.com    # prueba la conexión

9. GitHub como portafolio

Para quien está construyendo una carrera, el perfil de GitHub suele leerse antes que el currículum. Lo que de verdad pesa:

1. README en los proyectos. Un repositorio sin README parece abandonado, por bueno que sea el código. Explica el problema, la solución, cómo ejecutarlo y qué aprendiste.
2. Commits con un mensaje de verdad. Un historial de "update", "prueba" y "asdf" dice mucho de cómo trabajarías en equipo.
3. Pocos proyectos bien hechos > muchos a medias. Tres repositorios completos valen más que treinta tutoriales copiados.
4. README de perfil. Un repositorio con tu nombre de usuario se convierte en la página inicial de tu perfil.
5. Contribución en un proyecto ajeno. Un PR aceptado en un proyecto real demuestra que sabes trabajar con el código de otros — y vale más que un gráfico de contribuciones lleno.

Sobre los "cuadraditos verdes": la constancia está bien, pero nadie serio contrata por eso. Un commit diario sin sustancia se identifica fácilmente.

10. Alternativas y cuándo elegir otra

Para un proyecto personal, open source y portafolio, GitHub es la elección por defecto por su alcance. Para una empresa con exigencia de datos on-premise, GitLab y Gitea autoalojados suelen entrar en la conversación.

En resumen

Git guarda la historia de tu código. GitHub es donde esa historia se encuentra con otras personas — para revisar, automatizar, publicar y colaborar.

Si estás empezando, el camino más corto para sacarle provecho real:

1. Sube un proyecto tuyo con README y licencia.
2. Trabaja en ramas y abre PR aunque estés solo — el hábito es lo que cuenta.
3. Activa un workflow sencillo de CI que ejecute las pruebas.
4. Activa Dependabot.
5. Busca una issue good first issue en un proyecto que uses y manda tu primer PR.

El quinto paso es el que cambia de nivel: es cuando GitHub deja de ser una copia de seguridad de tu código y se convierte en el lugar donde trabajas con el resto del mundo.