Saltar a contenido

Capítulo 13: Proyecto Final: Un flujo de trabajo profesional de principio a fin

Has llegado al último capítulo del libro. Ya no se trata de aprender conceptos nuevos, sino de demostrar que eres capaz de usar Git y GitHub como un desarrollador profesional: revisar un proyecto, pulir la historia de commits, trabajar con ramas, documentar de forma clara, publicar el sitio con GitHub Pages, conectar un dominio, cuidar tu perfil y utilizar la IA como asistente sin perder el control.[web:233][web:186]

En este capítulo vas a tomar el mismo proyecto iniciado en el capítulo 2 —tu sitio web personal— y llevarlo a un nivel listo para portafolio. Lo tratarás como si fuera tu primer proyecto entregable para un cliente o una oportunidad laboral.

13.1 El escenario

Imagina la siguiente situación:

"Has terminado el desarrollo de tu primer proyecto de sitio web personal. Ahora debes prepararlo para entregarlo a un cliente, incorporarlo a tu portafolio profesional y dejarlo listo para futuras mejoras. Tienes una semana para pulir todo: código, historial, documentación y publicación."

Objetivos del proyecto

A partir de este punto, tu objetivo es que el proyecto cumpla con:

  • historial de commits limpio y comprensible;
  • uso correcto de ramas para mejoras y correcciones;
  • README y documentación profesional;
  • licencia clara;
  • archivos auxiliares como .gitignore, CHANGELOG, CONTRIBUTING;
  • sitio funcionando en GitHub Pages con dominio personalizado y HTTPS;
  • perfil de GitHub actualizado y conectado al proyecto;
  • revisión final asistida por IA como apoyo.
flowchart TD
    A[Proyecto desarrollado en capítulos anteriores] --> B[Revisión del repositorio]
    B --> C[Última mejora en nueva rama]
    C --> D[Documentación final]
    D --> E[Publicación y dominio]
    E --> F[Revisión asistida por IA]
    F --> G[Lista de verificación profesional]

[Ilustración: escena moderna donde se muestra el proyecto del libro abierto en un editor, el sitio publicado en un navegador y el perfil de GitHub visible, representando el conjunto como un portafolio listo para ser presentado]

Nota

Piensa este capítulo como tu "primer día de trabajo" con este proyecto: ya conoces las herramientas, ahora se trata de aplicarlas con criterio y responsabilidad profesional.

Breve conclusión: el escenario del proyecto final consiste en tomar el sitio del libro y prepararlo para ser mostrado a clientes, empleadores o colaboradores, aplicando todo lo aprendido de Git y GitHub.

13.2 Preparando el repositorio

Antes de implementar la última mejora, revisa el repositorio con ojos críticos. Tu meta es dejarlo ordenado, sin archivos innecesarios, con nombres claros y un historial que cuente la historia del proyecto.

Revisar estructura y archivos

  1. Examina la estructura de carpetas:
  2. index.html, contacto.html, recursos.html;
  3. carpetas como css/, images/, js/ si las has utilizado.
  4. Identifica archivos que no deberían permanecer en el repositorio:
  5. archivos temporales de editor;
  6. artefactos de build si no son necesarios para el despliegue;
  7. borradores obsoletos.
  8. Asegúrate de que .gitignore excluya archivos locales o de build que no deben versionarse.

Nombres, ramas e historial

  1. Verifica que el repositorio tenga un nombre claro (por ejemplo, sitio-web-personal).
  2. Revisa las ramas:
  3. main como rama principal estable;
  4. ramas de características o correcciones con nombres descriptivos.
  5. Observa el historial de commits:
  6. mensajes que describan bien los cambios;
  7. ausencia de commits tipo "prueba" o "arreglos" sin detalle.

Si encuentras commits poco claros que aún no se han compartido, puedes:

  • usar git rebase -i o git reset --soft para reorganizar y combinar commits;
  • mejorar mensajes con git commit --amend cuando tenga sentido.

Buenas prácticas

Trata el historial de commits como parte de la documentación: alguien que llegue al proyecto debería entender qué se hizo y cuándo, sin tener que leer todo el código.

Breve conclusión: preparar el repositorio implica limpiar estructura y archivos, revisar nombres y ramas, y asegurarte de que el historial de commits sea claro y profesional.

13.3 Desarrollo de una última mejora

Para simular un flujo profesional completo, implementarás una última mejora sobre el sitio usando el patrón de trabajo que ya conoces: rama de funcionalidad, commits claros, merge y push.

Elegir la mejora

Elige una mejora significativa pero acotada, por ejemplo:

  • añadir una sección "Testimonios" en index.html;
  • incorporar una página "Preguntas frecuentes" (faq.html);
  • mejorar accesibilidad (etiquetas, contrastes, navegación por teclado).

Flujo profesional

Nueva Branch → Desarrollo → Commit → Merge → Push

  1. Nueva Branch

Desde main estable:

git checkout main
git switch -c mejora-testimonios

  1. Desarrollo

  2. implementa la sección o página nueva;

  3. ajusta estilos en style.css si es necesario;

  4. prueba el sitio localmente.

  5. Commit

  6. prepara cambios:

git add index.html style.css
  • haz uno o varios commits pequeños con mensajes claros:
git commit -m "Agregar sección de testimonios en la página principal"

  1. Merge

  2. vuelve a main:

git checkout main
  • integra la rama usando merge:
git merge mejora-testimonios

  • resuelve cualquier conflicto si aparece.

  • Push

  • publica los cambios en el remoto:

git push origin main

Este flujo refleja el "GitHub flow": trabajar en ramas, abrir cambios y luego integrar a la rama principal.[web:233]

flowchart LR
    A[main estable] --> B[Crear rama de mejora]
    B --> C[Desarrollo y pruebas]
    C --> D[Commits claros]
    D --> E[Merge en main]
    E --> F[Push a remoto]

Consejo

Incluso para mejoras pequeñas, usar una rama separada te acostumbra a un flujo ordenado y reduce el riesgo de mezclar cambios independientes.

Breve conclusión: la última mejora se implementa siguiendo un flujo profesional de ramas y commits, consolidando tu dominio del trabajo con Git y GitHub en el proyecto del libro.

13.4 Documentación final

Con el código y el historial en buen estado, toca dejar la documentación lista para que cualquiera pueda comprender y utilizar el proyecto.

Revisar README

  1. Asegúrate de que el README del repositorio incluya:
  2. descripción clara del sitio;
  3. características principales;
  4. instrucciones de instalación y uso;
  5. capturas del sitio publicado;
  6. lista de tecnologías;
  7. estructura del proyecto;

  8. información de licencia y autor.[web:215]

  9. Actualiza cualquier sección que haya quedado obsoleta tras la última mejora.

Revisar LICENSE

  1. Comprueba que el archivo de licencia (LICENSE) esté presente.
  2. Verifica que la licencia elegida (por ejemplo, MIT) se mencione también en el README.[web:220]

Revisar .gitignore

  1. Asegúrate de que .gitignore excluya:
  2. archivos temporales de editor;
  3. posibles carpetas de build;
  4. archivos que no deben versionarse.

CHANGELOG y CONTRIBUTING

  1. En CHANGELOG, puedes resumir las principales etapas del proyecto:
  2. versión inicial;
  3. incorporación de secciones nuevas;

  4. mejoras visuales y de accesibilidad.

  5. En CONTRIBUTING, explica:

  6. cómo abrir Issues;
  7. cómo proponer cambios mediante Pull Requests;
  8. reglas básicas de estilo y mensajes de commit.

Error común

Tener buenas funcionalidades pero documentación incompleta o desactualizada. En contextos profesionales, la documentación es parte del entrega tan importante como el código.[web:215]

Breve conclusión: la documentación final se centra en un README completo, una licencia clara, un .gitignore adecuado y archivos como CHANGELOG y CONTRIBUTING que preparan el proyecto para colaboración futura.

13.5 Publicación

El proyecto no está completo hasta que se puede ver y usar desde Internet. Aquí verificas que GitHub Pages, el dominio personalizado, HTTPS y tu perfil estén alineados.

Verificar GitHub Pages y repositorio

  1. En Settings > Pages del repositorio, confirma:
  2. rama de publicación (por ejemplo, main);

  3. carpeta de publicación (/ o /docs).[web:186][web:223]

  4. Usa el enlace "Visit site" para comprobar que:

  5. el sitio se carga correctamente;
  6. la última mejora está visible.

Dominio personalizado y HTTPS

  1. Si configuraste un dominio de ejemplo (por ejemplo, www.misitio-educativo.com):
  2. confirma el archivo CNAME en la raíz del repositorio;
  3. revisa los registros DNS en tu proveedor;

  4. comprueba que el dominio apunta al sitio de GitHub Pages.[web:176][web:175]

  5. En Settings > Pages, verifica que "Enforce HTTPS" esté activado y que el sitio responda en https://.[web:177]

Perfil de GitHub y capturas

  1. Asegúrate de que el repositorio del proyecto esté fijado en tu perfil.
  2. Comprueba que el README de perfil incluya el proyecto del libro como ejemplo destacado.[web:207][web:209]
  3. Revisa que las capturas del sitio estén bien integradas en el README del proyecto.
flowchart TD
    A[Repositorio configurado para Pages] --> B[Sitio publicado]
    B --> C[Dominio personalizado (ejemplo)]
    C --> D[HTTPS activado]
    D --> E[Perfil de GitHub muestra el proyecto]

[Ilustración: vista del sitio publicado en un navegador con URL de GitHub Pages o dominio personalizado, junto al perfil de GitHub mostrando el repositorio fijado y un README con capturas]

Buenas prácticas

Antes de compartir tu proyecto, prueba el sitio como si fueras un usuario externo: navega, busca errores visuales y asegúrate de que los enlaces y recursos funcionen en la versión publicada.[web:186]

Breve conclusión: la publicación final verifica que el sitio funciona en GitHub Pages, el dominio y HTTPS están correctamente configurados y tu perfil de GitHub muestra el proyecto de forma clara y atractiva.

13.6 Revisión asistida por IA

Con todo listo, puedes utilizar la IA como una última capa de revisión: no para tomar decisiones por ti, sino para obtener sugerencias de mejora.

Revisar documentación y textos

Usa tu asistente de IA favorito (ChatGPT, Claude, Gemini, GitHub Copilot Chat, etc.) para:

  • revisar el contenido del README;
  • sugerir mejoras de claridad y estilo;
  • detectar inconsistencias entre documentación y código.[web:191][web:193]

Prompt ejemplo:

"Este es el README de mi proyecto de sitio web personal, publicado con GitHub Pages y utilizado como portafolio. Sugiere mejoras de claridad, estructura y profesionalismo sin cambiar el contenido técnico.".

Detectar posibles problemas y sugerir mejoras

Puedes pedir a la IA:

  • revisar nombres de archivos y carpetas;
  • comentar sobre la organización del repositorio;
  • sugerir secciones adicionales en CONTRIBUTING o CHANGELOG.

En algunos casos, asistentes como GitHub Copilot Code Review pueden analizar Pull Requests y señalar problemas de código, aunque en este proyecto el foco está en estructura y documentación.[web:231][web:234]

Mantener siempre la decisión final

Aunque la IA puede aportar ideas útiles:

  • tú decides qué sugerencias aplicar;
  • revisas cualquier cambio propuesto antes de integrarlo;
  • mantienes la responsabilidad sobre el resultado final del proyecto.[web:200]

Consejo

Usa la IA como último filtro para detectar cosas que se te hayan escapado (errores de redacción, pequeños problemas de organización), pero no la dejes reescribir el proyecto sin supervisión.[web:191][web:200]

Breve conclusión: la revisión asistida por IA sirve como última capa de refinamiento para documentación y organización, con la condición clave de que tú mantienes el control sobre las decisiones finales.

13.7 Lista de verificación profesional

Para cerrar el proyecto y tener una guía reutilizable en futuros trabajos, construimos una checklist completa.

Checklist del proyecto final

✔ Proyecto organizado (estructura de carpetas clara, sin archivos innecesarios).

✔ Commits claros (mensajes descriptivos, historial sin ruido).

✔ Rama principal estable (main) y uso ordenado de ramas de mejora.

✔ README completo (descripción, características, instalación, uso, capturas, tecnologías, estructura, licencia, autor).

✔ Licencia adecuada (por ejemplo, MIT) y archivo LICENSE presente.[web:220]

✔ .gitignore configurado para excluir archivos temporales y de build.

✔ CHANGELOG con resumen de principales hitos del proyecto.

✔ CONTRIBUTING con guías básicas para colaborar.

✔ Sitio funcionando en GitHub Pages].[web:186][web:223]

✔ Dominio personalizado configurado (como ejemplo) y CNAME presente.

✔ HTTPS activado en el sitio publicado.[web:177]

✔ Perfil de GitHub actualizado (foto, bio, enlaces).[web:209]

✔ README de perfil profesional que destaca el proyecto del libro.[web:207]

✔ Revisión asistida por IA aplicada a documentación y organización.[web:191]

✔ Proyecto público y listo para ser compartido.

Elemento Estado Comentarios
Organización del repositorio ✔ / ✘ Estructura y archivos
Historial de commits ✔ / ✘ Claridad de mensajes
Documentación del proyecto ✔ / ✘ README, LICENSE, otros
Publicación del sitio ✔ / ✘ GitHub Pages, dominio, HTTPS
Perfil de GitHub ✔ / ✘ Datos y README de perfil
Revisión con IA ✔ / ✘ Sugerencias aplicadas

¿Sabías que...?

Muchas empresas valoran candidatos que muestran proyectos con documentación, licencias claras, historial limpio y publicación real. Tu checklist puede ser un recurso que revises antes de enviar cualquier enlace de GitHub en una entrevista.[web:225]

Breve conclusión: la lista de verificación profesional te ofrece un marco reutilizable para evaluar futuros proyectos, asegurando que todos los elementos clave de código, documentación y publicación estén cubiertos.

13.8 Cierre del libro

Has llegado al final de "Git y GitHub Profesional". Desde el capítulo 2 hasta este proyecto final, has construido y evolucionado un sitio web personal utilizando Git y GitHub como herramientas centrales.

Lo que has construido

A lo largo del libro:

  • iniciaste un proyecto real y lo versionaste con Git;
  • aprendiste a trabajar con ramas, merges y resolución de conflictos;
  • publicaste el sitio con GitHub Pages y exploraste dominios personalizados e HTTPS;[web:186][web:223][web:177]
  • organizaste tu perfil de GitHub y documentaste proyectos como parte de un portafolio;
  • integraste herramientas de IA como asistentes para mejorar documentación y flujo de trabajo.

Has visto que dominar Git y GitHub no consiste en memorizar comandos, sino en adoptar una forma profesional de trabajar:

  • pensar en términos de historial y ramas;
  • documentar para otros (y para tu futuro yo);
  • publicar y mantener proyectos de forma ordenada;
  • colaborar y revisar con criterio.

Filosofía de Academia El Profe: aprender construyendo

Este libro se diseñó con una idea central: aprender construyendo. No te limitaste a leer sobre Git y GitHub, sino que aplicaste cada concepto en un proyecto concreto, paso a paso, hasta convertirlo en algo que puedes mostrar al mundo.

Curiosidad

GitHub mantiene una sección de recursos para aprender Git y GitHub que se actualiza con frecuencia. Revisarla después de este libro puede darte nuevas ideas para proyectos y flujos de trabajo.[web:225]

A partir de aquí, el siguiente paso ya no está en estas páginas, está en tus proyectos:

  • crea nuevos repositorios;
  • explora otras tecnologías, frameworks y lenguajes;
  • aplica el flujo profesional aprendido en este libro a cada nuevo trabajo;
  • usa GitHub como base de tu portafolio y espacio de colaboración.

Breve conclusión: cerrar el libro no significa dejar de aprender. Has adquirido una forma de trabajar con Git y GitHub que puedes aplicar en proyectos reales, siguiendo la filosofía de Academia El Profe: aprender construyendo y compartiendo tu trabajo con el mundo.

Bibliografía