Repository repo
El proyecto y su historia: los archivos y cada cambio que se les ha hecho.
Pregunta práctica¿Es el repo oficial? Llega desde el sitio del proyecto, o mira que el nombre de la cuenta coincida.
GitHub para leer repositorios
Recurso complementario de Software libre con IA: las palabras de GitHub que necesitas para leer un repositorio ajeno y entender sus señales.
GitHub para leer repositorios
Software libre con IARecurso complementarioCap. 3 · Discernimiento
La IA puede hacer scouting por ti, pero tú debes poder entender qué está mirando y por qué esas señales importan. Esto no es una clase de Git: es lo justo para leer un repositorio ajeno sin que parezca una pared de jeroglíficos.
Capa 1
Qué estoy mirando
Con estas palabras puedes leer casi cualquier repositorio. No necesitas comandos.
Commit
Un punto guardado en esa historia, con un mensaje que dice qué cambió.
Pregunta práctica¿Se sigue trabajando en el proyecto? Arriba de la lista de archivos aparece el último commit y hace cuánto fue.
Branch rama
Una línea de trabajo separada de la principal. Sirve para probar un cambio sin tocar lo que ya funciona. La principal suele llamarse main o master.
Pull request PR
pull = el cambio
request = pedir permiso
request = pedir permiso
Un PR propone incorporar cambios. Que exista no significa que los hayan aceptado. Normalmente trae:
- un diff: qué cambió, línea por línea;
- conversación;
- checks: pruebas automáticas;
- revisión de otras personas;
- una decisión eventual: integrarlo o no.
Merge
El cambio propuesto se incorporó a la línea de destino.
merge = el permiso fue concedido
Es una forma de recordarlo. Técnicamente, merge es unir dos líneas de trabajo.
Fork
Una copia independiente de un repositorio bajo otra cuenta u organización. Puede usarse para experimentar, desarrollar una variante o preparar contribuciones al proyecto original.
En el workshopLo leemos como señal aproximada de interés e involucramiento técnico, no como certificación. Muchos forks nunca se tocan después de creados.
Release
commitalguien guardó un cambio en el proyecto
releaseel proyecto presenta una versión identificable para distribución o uso
Si llegaste a GitHub para descargar una aplicación, lo que buscas es una release, no el código.
Tag etiqueta
Una etiqueta que marca un punto específico de la historia del proyecto. Casi siempre es una versión, como v2.3.0. Cada release apunta a un tag.
Semver versionado semántico
1MAJORpuede romper algo
.
17MINORagrega sin romper
.
3PATCHarregla
Una promesa acerca de qué clase de cambio puede romper algo. Si pasas de 1.17 a 2.0, lee las notas antes de actualizar.
Semver no es Git: es una convención de versionado muy común. No todos los proyectos la usan; algunos numeran por fecha, como 2026.10.
Dónde está la release · y qué no descargar
Ejemplo ilustrativo · página principal de un repo
notas-libres / notasPublic
1<> Code ▾Clone · Download ZIP
Última actividad:Fix export · 3 days ago · 2,184 commits
About
Notas locales en Markdown, sin cuenta.
★ 4.2k stars · 310 forks
2Releases 48
v1.4.2Latest2 weeks ago
Contributors37
Ejemplo ilustrativo · dentro de la release v1.4.2
Assets7
Notas-1.4.2-Windows-x64.msi3
Notas-1.4.2-macOS-arm64.dmg
Notas-1.4.2-macOS-x64.dmg
Notas-1.4.2-Linux-x86_64.AppImage
Notas-1.4.2-Windows-x64.msi.sig4
Source code (zip)5
Source code (tar.gz)
- 1El botón verde Code y Download ZIP bajan el código fuente, no una aplicación lista para instalar.
- 2En la columna de la derecha, Releases. La marcada Latest es la versión estable más reciente. Atajo: agrega
/releases/latestal final de la dirección del repo. Si esa sección no aparece, el proyecto quizás no publica releases: busca «Download» o «Install» en el README. - 3Los instaladores. Elige el de tu sistema y tu arquitectura:
x64=x86_64=amd64(la mayoría de los PC);arm64=aarch64(Mac con Apple Silicon, muchos teléfonos y algunos portátiles nuevos). - 4Archivos como
.sig,.DIGEST,dSYMsoPDBssirven para verificar la descarga o para depurar. No son para instalar. - 5Source code (zip / tar.gz) lo agrega GitHub solo, en todas las releases. Es el código, no un instalador. Algunos proyectos suben además su propio archivo de código (con
-srcoSourcesen el nombre).
Si la release solo trae código y las instrucciones hablan de compilar, de Docker o de comandos de servidor, probablemente no es un easy win para una persona no técnica.
Capa 2 · La pieza más importante
De palabras a señales
No aprendemos vocabulario por aprenderlo. Cada palabra abre una pregunta que puedes hacerle a un proyecto.
No estamos buscando simplemente popularidad. Estamos buscando señales de cuántos ojos humanos parecen estar sobre el software.
Ninguna métrica aislada demuestra que un proyecto sea seguro o confiable. Las señales se leen juntas.
| Señal | Qué puede ayudarme a preguntar | Dónde la veo |
|---|---|---|
| Commit reciente | ¿Se sigue trabajando en el proyecto? | Arriba de la lista de archivos: «hace 3 días» |
| Edad del repo | ¿Tiene alguna historia y madurez observables? | El commit más antiguo; la primera release |
| Stars | ¿Ha atraído atención? | ★ arriba a la derecha y en About |
| Forks | ¿Hay personas suficientemente interesadas como para trabajar a partir del código? | Junto a las stars |
| Contributors | ¿Cuánta actividad parece depender de una sola persona o de una comunidad? | Columna derecha; pestaña Insights → Contributors |
| Pull requests | ¿Se proponen cambios? ¿Se revisan? ¿Se responden? | Pestaña Pull requests: abiertos y cerrados |
| Issues | ¿Hay usuarios reportando problemas? ¿Alguien responde? | Pestaña Issues |
| Releases | ¿Existen versiones utilizables y recientes? | Columna derecha: Releases · Latest |
| Semver / tags | ¿Cómo comunica el proyecto sus versiones y cambios? | El número de la release y sus notas |
Leerlas juntas · tres combinaciones
★ muchas · último commit hace 2 años · issues sin respuesta
Atrajo atención en su momento. Hoy el mantenimiento es dudoso.
★ pocas · releases regulares · maintainers que responden
Proyecto chico pero cuidado. Puede servirte más que uno famoso.
muchos PRs · casi todos de bots · pocas reviews
Hay movimiento, pero no necesariamente muchas personas mirando.
Las heurísticas con números (dos meses, dos años, forks ÷ 10) están en Repo Scout · Parte B.
Leer un pull request ajeno
Cómo leer un pull request
No vas a crear uno. Vas a abrir uno ajeno y reconocer qué está pasando. GitHub muestra esta pantalla en inglés.
Ejemplo ilustrativo
Agregar exportación a Markdown #318
Open1ana-r wants to merge 3 commits into main from ana-r:export-md
Conversation 6Commits 3Checks 2Files changed 2
2
3✓Changes approved · 1 approving review
4✓All checks have passed · build, tests· o bien✕Some checks were not successful
5src/exportar.js +2 −1
function exportar(nota) {
- return nota.texto
+ const md = aMarkdown(nota)
+ return md
}
6opened 4 days ago · last activity 2 days ago
- 1Quién propone el cambio, cuántos commits trae, hacia qué línea va y desde dónde viene. Si viene de
otra-cuenta:branch, viene de un fork. - 2Conversación. ¿Alguien del proyecto respondió? ¿Hay preguntas sin contestar?
- 3Reviews. Otra persona revisó y aprobó, o pidió cambios. También puede decir Review required: nadie lo ha revisado todavía.
- 4Checks. Verde: las pruebas automáticas pasaron. Rojo: algo falló. Los checks son automáticos; no reemplazan a una persona que revisa.
- 5Files changed. Qué archivos toca y qué cambió en cada uno: verde = agregado, rojo = eliminado. Esa es toda la notación.
- 6Actividad. Un PR abierto hace una semana es normal. Uno abierto hace un año sin respuesta dice algo del proyecto.
Estado del PR
Open propuesto, sin decisión
Draft su autor dice que no está listo
Merged incorporado
Closed cerrado sin incorporar
¿Quién está detrás de la actividad?
OpenBump lodash from 4.17.20 to 4.17.21· dependabotbot
Openchore(deps): update dependency vite to v6· renovatebot
MergedAgregar exportación a Markdown· ana-r
Ojo
Muchos pull requests no equivalen necesariamente a muchos humanos revisando código.
Hay actividad que generan bots (como Dependabot o Renovate, que proponen actualizar dependencias), otras automatizaciones y agentes de IA. GitHub marca algunas cuentas con la etiqueta bot, pero no todas se identifican. Y un PR hecho por una persona tampoco garantiza que el cambio sea bueno, seguro o que alguien lo haya revisado.
La pregunta útil
¿Qué tipo de actividad parece existir alrededor de estos cambios?
Dos objetos distintos
Fork vs branch
Una branch vive dentro del repo. Un fork es otro repo.
- BBranch: una línea de trabajo dentro del mismo repo. La crea alguien con permiso para escribir ahí.
- FFork: una copia independiente bajo otra cuenta u organización. Quien no tiene permiso en el original puede trabajar en su copia y proponer el cambio de vuelta con un pull request. O seguir su propio camino.
Por qué te importa al evaluar software
Bajo el nombre de un fork, GitHub muestra forked from …. Y a veces, cuando el proyecto original se abandona o cambia de rumbo, la vida sigue en un fork. LibreOffice, por ejemplo, nació en 2010 como fork de OpenOffice.org. Si el original parece muerto, vale la pena preguntar si hay un fork activo.
Segunda capa · opcional
Si algún día contribuyes
No necesitas esto para este workshop. Está aquí para cuando GitHub deje de ser solamente un lugar que visitas y pase a ser un lugar donde trabajas.
| Palabra | Qué es | Dónde o cuándo vas a encontrarte con esto |
|---|---|---|
| clone | bajar una copia completa del repo, con su historia, a tu computador | en el botón verde Code; en instrucciones de instalación que empiezan con git clone |
| commit | un punto guardado, con un mensaje | en la historia del proyecto; cuando guardes tus propios cambios |
| push | subir tus commits a la copia en GitHub | cuando quieras que tus cambios aparezcan en línea |
| pull | traer a tu copia lo nuevo que hay en GitHub | antes de seguir trabajando en una copia que dejaste un tiempo |
| fetch | mirar qué cambió en GitHub sin tocar tu trabajo | cuando quieras saber si hay novedades antes de mezclar nada |
| PR | una propuesta de cambio, con revisión | cuando propongas tu primer arreglo, aunque sea una errata en la documentación |
| draft PR | un PR que dice explícitamente: todavía no está listo | etiqueta gris Draft; cuando quieras mostrar algo a medio hacer y pedir opinión |
| merge | unir una línea de trabajo con otra | cuando acepten tu PR; el botón lo presiona quien mantiene el proyecto |
| tag | un nombre fijo para un punto de la historia, por ejemplo una versión | en Releases y en la lista de Tags |
| revert | deshacer un commit agregando su opuesto, sin borrar la historia | en el historial: commits que empiezan con «Revert …» |
| origin | el nombre por defecto de la copia en GitHub de la que clonaste | en mensajes de la terminal, como origin/main |
| HEAD | dónde estás parado ahora en la historia | en mensajes de la terminal; por ejemplo, detached HEAD |
Un nivel más · sin profundizar
3 commits behind mainNo es un error. La línea principal avanzó mientras trabajabas. Ponerse al día seguido evita sustos.
merge conflictDos cambios tocaron las mismas líneas. Git no adivina cuál vale y pregunta. Lo vas a ver con marcas
<<<<<<< ======= >>>>>>>.rebaseOtra forma de ponerse al día: recoloca tus commits sobre la punta de la línea principal. Regla: nunca sobre algo que ya subiste y compartiste.
force pushUn push normal agrega. Uno forzado sobrescribe lo que está en GitHub y puede borrar trabajo de otras personas. En una branch compartida, no.
reflogEl diario de Git de todos los lugares por donde pasó HEAD. Por eso el trabajo «perdido» casi nunca está perdido. Antes de intentar arreglarlo, pide ayuda.
Para seguir
Para seguir
Repo Scout · Buscar software libre con IA sin delegar tu criterio → tus estándares · señales de salud · prompt reutilizable para un ProjectPara practicar con repos reales
Abre la página de releases de un proyecto y busca los instaladores, los archivos auxiliares y el Source code automático:
- KeePassXC: gestor de contraseñas. Junto a cada instalador hay archivos
.sigy.DIGEST. - OBS Studio: grabación y transmisión. Hay versiones para Apple Silicon e Intel, y archivos de depuración.
- O el proyecto que encuentres en OpenAlternative durante el recorrido.
Mapas originales · en inglés
Git, for People Who Never Got Good at GitHub → ocho momentos confusos de GitHub · la página del PR · la tabla de palabras Branches, Pull Requests and Release Lanes → branch · pull request · merge · semver
Adaptación al español de los materiales de Git del companion de Agentic SDLC, de Liz Howard · The Multiverse School
Software libre con IA · Sandra Acevedo
Gracias. ¿Puedes agregar una prueba para archivos vacíos?