Git & GitHub – DÍA 5
GitHub profesional: README, Issues, Wiki, Releases y buenas prácticas
(tu repositorio empieza a parecer de verdad profesional)
1. Objetivo del día
Hoy aprenderás a usar GitHub “como un profesional”, aprovechando:
- README (tu carta de presentación)
- Issues (gestión de tareas y bugs)
- Wiki (documentación viva del repositorio)
- Releases (versiones estables de tus scripts)
- Licencia, etiquetas y buenas prácticas
- Organización del repositorio
Con esto tu repo será fácil de entender, de mantener y de colaborar.
2. README: imprescindible y obligatorio
El README es la página de inicio de tu repositorio.
Es lo primero que ve cualquiera.
Debe incluir, como mínimo:
✔ 1. Título del proyecto
# Mis Scripts de Automatización
✔ 2. Descripción breve
Colección de scripts Bash, Python y utilidades para automatización y monitorización.
✔ 3. Cómo usarlo
./backup.sh
./healthcheck.sh servidor.txt
✔ 4. Requisitos
- Bash
- Python
- Linux
✔ 5. Ejemplos
Capturas o comandos.
✔ 6. Estructura del repositorio
/bash
/python
/logs
✔ 7. Notas de seguridad
⚠ No incluir credenciales ni datos sensibles.
💡 TIP PROFESIONAL
Un buen README convierte tu repositorio en algo útil incluso para ti dentro de un año.
3. Issues: tu sistema de tareas y preguntas
Los “Issues” son:
- tareas pendientes
- ideas
- mejoras
- preguntas
- bugs
Crear un issue:
GitHub → pestaña Issues → New issue
Ejemplos:
- “Añadir script de backup incremental”
- “Mejorar documentación del healthcheck”
- “Refactorizar check_dns”
Los issues convierten tu repo en un proyecto vivo.
4. Wiki: documentación extendida
El Wiki es perfecto para:
- manuales
- procedimientos
- instrucciones largas
- histórico de cambios
- mini tutoriales
Ejemplo de páginas útiles:
- “Cómo usar este repositorio”
- “Mejores prácticas de Bash”
- “Estándares de scripts”
- “Templates de README”
Puedes crear páginas fácilmente desde la pestaña Wiki.
5. Releases: versiones estables del proyecto
En GitHub, una Release es una versión empaquetada de tu software.
Para scripts es MUY útil:
- publicar “v1.0”, “v1.1”, etc.
- decir qué cambió
- permitir descargar un zip limpio de esa versión
Crear una release:
GitHub → Releases → Draft a new release
Pon:
- Tag:
v1.0 - Title: “Primera versión estable”
- Notas de cambios
6. Licencia del repositorio
Si el repo es público, debes elegir licencia:
- MIT → muy abierta
- GPL → copyleft
- Apache → profesional
- “All rights reserved” → cerrado
GitHub te ofrece un selector de licencias.
7. Buenas prácticas profesionales
✔ Estructura clara de carpetas
/bash
/python
/logs
/docs
✔ Nombres limpios
healthcheck.sh
backup.sh
procesar_logs.py
✔ Commits con mensajes claros
Añade función check_disk al script healthcheck
✔ README completo
✔ Issues abiertos siempre visibles
✔ Releases por versión
✔ No subir archivos pesados o innecesarios
8. Práctica guiada (20–30 minutos)
1️⃣ Crear un README decente
Incluye:
- título
- descripción
- estructura
- ejemplos
- notas de seguridad
2️⃣ Crear al menos 3 issues
- “Añadir script X”
- “Mejorar documentación”
- “Refactorizar función Y”
3️⃣ Crear una página en el Wiki
“Guía básica de scripts del repositorio”
4️⃣ Crear tu primera Release
- tag
v1.0 - notas breves
- subir los scripts actuales
Todo esto te hace parecer un profesional REAL.
9. Checklist del Día 5
- README completo
- Issues creados
- Wiki creada
- Release creada
- Licencia elegida
- Repositorio ordenado
- Buenas prácticas aplicadas
Si está todo marcado → Día 5 superado.
10. Ejercicio sugerido
En tu repositorio:
- Crear un archivo
VERSION.md - Añadir la historia de versiones
- Crear una Release con Tag
v1.0 - Subir capturas del funcionamiento de algún script
- Crear un issue con mejoras futuras
11. Día 5 completado
Tu repositorio ya tiene estructura, documentación y herramientas profesionales.
Mañana llega algo muy práctico y moderno:
👉 Día 6 – VS Code + Git: flujos visuales, commits gráficos, staging visual, extensiones, GitLens.
VS Code te hará la vida más fácil con Git.
