Git
Published:
Blog dedicado al uso de Git y GitHub.
Git and GitHub
[! info] Website: https://git-scm.com Documentación:
- https://git-scm.com/doc
- https://git-scm.com/book/en/v2
[! info] Website: https://github.com Necesidad de crear una cuenta. Documentación:
- https://docs.github.com/en/authentication/connecting-to-github-with-ssh
- https://docs.github.com/es/get-started/using-github/github-flow
- https://github.com/apps/desktop
- https://docs.github.com/es/get-started
- https://education.github.com/git-cheat-sheet-education.pdf
Resumen básico
Configuraciones e instrucciones principales
Configuración inicial
git config --global user.name My_name
git config --global user.email ownmail@example.com
git config --global init.defaultBranch main
git config -l # Mostrar Configuración general
Comandos Principales
git init #Init Repo
git add "name_file" #Un fichero particular
git add . #Todos los ficheros
git commit -m "Titulo del commit"
git commit -am "Titulo del commit" #Hace el add y el commit
git switch "Nombre de rama" #Cambiar de Rama
git switch -c "Nombre de rama" #Crear rama y cambiar a ella
git status -s #Observar todos los cambios
#########################
git log #vemos todos los cambios
git checkout "hash id" #Para ir a un momento dado
git branch -r #Ramas remotas
git branch -a #Todas las ramas
########################
git clone "repo"
git remote --verbose
git remote add upstream "repo" #Repositorio principal
git pull upstream main # Bajar de la nube
git push origin main # Subir en la nube
########################
git fetch origin # Baja los cambios pero no los fusiona
# Luego
git log main..origin/main # Registro comparativo entre ramas
git merge origin/main # Fusiono si acepto los cambios
Configuración SSH
Para trabajar de forma segura debemos emplear SSH.
ssh-keygen -t rsa -b 4096 -C "email"
- t ed25519 establece el nivel de encriptación.
- C añade un comentario con tu correo, útil para identificar la llave en GitHub.
Comprobemos que el server SSH funcione
eval $(ssh-agent -s)
Add pass privado
ssh-add ~/.ssh/id_rsa
A continuación añadimos la clave pública a GitHub, esta clave pública la encontramos en el fichero
~/.ssh/id_rsa.pub
Verificar la conexión con GitHub:
- Comprobar autenticación: En la terminal, ejecuta el comando:
ssh -T git@github.com
- Escribe “yes” para confirmar la conexión.
- Aparecerá un mensaje de GitHub que confirma la autenticidad.
Ahora cambiamos a trabajar con SSH
# git@github.com:rigo93acosta/repo_test_git.git -- Dirección ssh
git remote set-url origin git@github.com:rigo93acosta/repo_test_git.git
[! attention] Tener en cuenta si usamos como SO Unix/Mac, se deben realizar otras configuraciones.
- Crear el archivo de configuración SSH: Abre o crea el archivo
config
dentro del directorio.ssh
- Agregar parámetros específicos de Mac: Añade la configuración para integrar SSH con el sistema Keychain:
Host github.com AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/id_ed25519
- Añadir la llave al agente SSH con Keychain: Usa el comando:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Flujo de Trabajo
Trabaja con merge
Pasos:
- Ir a la rama a la que quiero traer los cambios.
git merge rama_de_cambios
[!warning] Conflictos Aparece en el archivo el conflicto para solucionar.
- Manual
- IDE lo resuelve más sencillo.
- Al finalizar debo hacer commit para completar el merge
[!hint] Retornar un merge realizado ```shell git merge –abort
Eliminar Ramas
git branch -d nombre-de-la-rama
git branch -D nombre-de-la-rama #Forzar
git push origin --delete nombre-de-la-rama #Remota
Reconstruir commits
git add .
git commit --amend
Trabajo con checkout
git checkout "hash" "archivo_que_quiero_ver" #En ese Commit
git checkout main "archivo_que_quiero_ver" #último Commit
Instrucciones delicadas
- Vuelve al punto que indica hash borrando los posteriores cambios al hash
git reset "hash" --hard
- Vuelve al punto que indica hash manteniendo los cambios en staging
git reset "hash" --soft
Salvarte la vida (reset - revert)
[! note] git reset El comando reset te devuelve a un commit anterior, eliminando los cambios en el historial como si nunca hubieran ocurrido.
[! note] git revert Crear un nuevo commit que revierte los cambios realizados por un commit específico.
[! attention] Para cuando te equivocas y haces un
git reset --hard "hash"
puedes ver todo pero todo útil
git reflog
Ignorando archivos y carpetas
Creamos y añadimos el fichero .gitignore
. En el fichero .gitignore
agrego los archivos a ignorar. https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files
[!warning] Evitemos añadir al control de versiones los archivos binarios, esto es una mala praxis. Ejemplo:
*.jpg
Ignoramos todos los jpg.
[! tip] Dato Nerd En este repositorio de GitHub https://github.com/github/gitignore, se tienen una gran diversidad de plantillas de
gitignore
para los proyectos.
GitIgnore Templete en GitHub
Trabajo con GitHub
Ilustración general
[!info] Usando Fork
- Trabajar de manera independiente en un proyecto sin afectar el repositorio original.
- Personalizar el contenido según tus necesidades sin modificar el repositorio fuente.
- Crear una base para hacer contribuciones posteriores al repositorio original.
Trabajo colaborativo
![]()
[!note] Pull Request Cuando Leonard realiza un Pull Request al trabajo de Sheldon, se realiza un code review donde discuten los cambios en el código, antes de fusionarlos con la rama principal. Esto permite que:
- Evaluar y comentar los cambios antes de fusionarlos.
- Aumentar la calidad y la visibilidad de los cambios propuestos.
El trabajo en GitHub con los Pull Request es bastante sencillo e intuitivo.
Recomendaciones
Link: https://docs.github.com/es/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests Link: https://docs.github.com/es/pull-requests
Git Clone
[!tip] Git clone con todas las ramas
Comando básico
git clone --mirror <URL-del-repositorio>
Este comando descarga una copia exacta del repositorio con todas las ramas, tags, y el historial completo. Es útil si quieres replicar el repositorio como está, incluyendo todas las referencias. Sin embargo, esto clonará el repositorio en modo “bare”, lo que significa que no podrás trabajar directamente en él (no se verá como un directorio de trabajo normal de Git).
Para clonar normalmente pero con todas las ramas
Si deseas clonar el repositorio de forma que puedas trabajar en él y, además, traerte todas las ramas y el historial, usa:
git clone <URL-del-repositorio>
cd <nombre-del-repositorio>
git fetch --all
Detalles de las opciones
- Clonar todo el historial y las ramas:
- El comando
git clone <URL>
por defecto ya clona el historial completo y la rama por defecto (generalmentemain
omaster
). - Para asegurarte de traer todas las ramas remotas, ejecuta después:
git fetch --all
Esto traerá todas las referencias y ramas del repositorio remoto.
- El comando
- Ver todas las ramas locales y remotas: Después de clonar y hacer
git fetch --all
, puedes listar todas las ramas disponibles:git branch -a
Esto te mostrará tanto las ramas locales como las remotas.
- Traer todas las ramas remotas a locales: Si deseas tener todas las ramas remotas también como ramas locales en tu repositorio, puedes ejecutar:
for remote in `git branch -r`; do git branch --track ${remote#origin/} $remote; done git fetch --all git pull --all
Este conjunto de comandos clonará el repositorio, traerá todas las ramas y referencias remotas, y replicará esas ramas en tu repositorio local. Tendrás disponible tanto el historial de commits como las ramas.
Para descargar también los tags:
Si necesitas asegurarte de traer los tags junto con el historial de commits, puedes hacerlo así:
git fetch --tags
Clonar sin limitar el historial (para repositorios grandes):
Si el repositorio es muy grande, algunos clonan con un límite de historial usando --depth
. Para evitar esto y clonar todo el historial, no uses la opción --depth
.
Otras Instrucciones
Git log
git log --graph
git log --graph --pretty=oneline
git log --all --graph --decorate --oneline
git log --grep="lo que se quiere buscar" # Buscar cosas en el repo
[!hint] Dato Nerd
alias arbol="git log --all --graph --decorate --oneline"
Tags
Permite identificar de una mejor forma los commit.
git tag -a v0.1 -m "mensaje" "hash"
git tag
git show-ref --tags
git push origin --tags #Subir todos los tags
git tag -d "name tag" #Eliminar el tag
git push origin :refs/tags/"name tag" #Subir un tag especifico
Checkout
Permite de cambiar de ramas o cambiar de un commit a otro, sin modificar el trabajo que se está haciendo creando un espacio temporal.
git checkout "hash"
git checkout main #Regresa el HEAD al último commit
Rebase (cambios silenciosos)
[!warning] Mala práctica
Hago que una rama nunca hubiese existido:
git rebase a la rama que no va a existir
git rebase a la rama principal
Git stash Guardar cambios en memoria y para luego rescatarlo
git stash
git stash list
git stash pop #Agrego los cambios
git stash branch "rama_nueva"
git stash drop #descarto los cambios
[!help] Use
git stash save "description"
Para agregar descripción al trabajo.
Git Clean
[!warning] No aplica el git clean a los archivos en gitignore
git clean
git clean --dry-run
git clean -f
Cherry-picking
Cherry-picking le permite aplicarla a su rama actual sin fusionar toda la rama.
git cherry-pick "hash"
Esto es especialmente útil cuando se necesita hacer backport de correcciones de errores o pequeñas características.
Buscar cosas en el repositorio
git grep #Buscar cosas en los archivos del repo (Revisar la ayuda)
git log -S "lo que quieres buscar " #Revisar en los commits
Instrucciones curiosas
- Git add interactivo seleccionando lo que deseas dentro del archivo para hacer commit.
git add -p
- Eliminando el último commit Te permite eliminar el último commit manteniendo los cambios en tu directorio de trabajo.
git reset --soft HEAD~1
[!warning] Use
--soft
si quieres mantener los cambios,--hard
elimina todos los cambios incluyendo los cambios locales. - Actualizar todas las ramas desde el repo online
git fetch --all --prune
- Historial línea por línea de quién ha cambiado qué en un archivo.
git blame <filename>
GitHub
Estrellas, why???
Las estrellas en GitHub funcionan como un sistema de marcado para resaltar los repositorios que deseas tener a mano como referencia o favoritos. Son útiles para:
- Crear un índice de repositorios de referencia o inspiración.
- Acceder rápidamente a recursos clave desde tu perfil.
- Seguir el desarrollo de proyectos importantes para tus intereses.
Al seleccionar la estrella en un repositorio, ésta se ilumina para indicar que has marcado este recurso. Puedes acceder a todos tus repositorios marcados desde la sección de “tus estrellas” en tu perfil.
Issues
Link: https://docs.github.com/es/issues/tracking-your-work-with-issues/about-issues
Un Issue es una forma de señalar problemas o sugerencias dentro de un repositorio. Puede ser usado para:
- Notificar errores en la documentación, como faltas de ortografía.
- Reportar problemas en el funcionamiento esperado del código.
- Informar mejoras o cambios necesarios.
Cómo crear un nuevo Issue?
- En el repositorio de GitHub, selecciona la pestaña Issues.
- Haz clic en New Issue y describe el problema en dos campos principales:
- Título: Una breve descripción.
- Descripción: Detalles del problema, pasos para reproducirlo, etc. Es posible agregar elementos adicionales, como asignar el Issue a otra persona o etiquetarlo.
[!summary] ¿Cómo crear una plantilla de Issues? Para facilitar el proceso a otros colaboradores, es útil crear plantillas de Issues. Para hacerlo:
- Desde el repositorio, abre Visual Studio Code con el comando
code .
- Crea una carpeta llamada
.github
y dentro otra carpeta llamadaISSUE_TEMPLATE
.- Dentro de
ISSUE_TEMPLATE
, crea un archivo Markdown (por ejemplo,bug_report.md
).- Copia la estructura de la plantilla, que usualmente incluye secciones como descripción, pasos para reproducir el error y detalles adicionales.
Con esta plantilla, los colaboradores tendrán un formato estándar para reportar problemas, lo que ayuda a una mejor gestión y resolución.
En la sección PLANTILLA ISSUE dejó un plantilla de ayuda.
¿Qué ventajas tiene una plantilla de Issues?
Las plantillas simplifican el proceso de documentación de problemas y mejoran la comunicación al estandarizar la información que se solicita a los colaboradores. Esto ayuda a identificar los problemas de forma precisa y rápida.
¿Cómo personalizar las plantillas de Issues para casos específicos?
Además de la plantilla básica para bugs, puedes crear plantillas personalizadas como:
- Document Report: Para señalar errores en la documentación.
- Mejores prácticas: Para sugerir mejoras en la estructura del código. Estas plantillas permiten a los colaboradores elegir el tipo de Issue que mejor se adapta al problema y agilizan la gestión del repositorio.
GitHub Proyects
GitHub nos provee una variedad de plantillas.
[!tip] Proyects Cada plantilla nos ofrece una lista de tareas o acciones a realizar en el proyecto. A través de las Issues se puede orientar el trabajo a los miembros del proyecto. Esto ayuda a los desarrolladores a mejorar en la gestión de su propio tiempo y a contribuir de manera eficiente al equipo, evitando interrupciones.
[! hint] Tips
- Se puede filtrar por items para cada miembro en específico.
- En cada tarea te brinda un número de identificación el cual lo puedes emplear para crear una rama de trabajo con ese identificador, es una excelente práctica realizar esto.
- Se pueden crear issues de forma automática.
- Se puede observar tu rendimiento dentro del proyecto, a través de métricas de rendimiento.
- Es una buena práctica cuando se crea el Pull Request señalar que issue estas solucionando.
Flujo automatizado en GitHub
Con esta automatización:
- El estado de las tareas se actualiza solo, sin necesidad de hacerlo manualmente.
- Los workflows pueden expandirse para notificar por Slack, Teams o correo electrónico cada vez que un pull request se cierra, facilitando la comunicación y el seguimiento en equipo.
- GitHub Projects, junto con estas integraciones, permite un flujo de trabajo robusto y ágil.
GitHub Codespaces
Markdown, Good Documentation and GitHub Profile
Link: https://docs.github.com/es/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax Badges Link: https://shields.io/badges
GitHub Profile
- Crear un repositorio de esta forma:
- Crear en la plantilla de formato Markdown
### Hola 👋, Rigo
#### PhD Student
Habilidades:









[](https://badges.pufler.dev)
[](https://badges.pufler.dev)
[<img src='https://cdn.jsdelivr.net/npm/simple-icons@3.0.1/icons/github.svg' alt='github' height='40'>](https://github.com/rigo93acosta)


[](https://github.com/anuraghazra/github-readme-stats)
Wikis
Para ello existe dentro de Github la opción de crear una Wiki en donde puedes generar un nivel más estructurado de documentación. Puedes ver la sección de Wiki en tus proyectos en la sección superior del portal de Github.
Una característica superinteresante es que puedes clonar esta wiki dentro de tu entorno local sin mayor problema, observa que hacer esto significa que solo vas a clonar todos estos documentos y no vas a hacer lo mismo con el repositorio lo que se me hace superinteresante porque puede ser que el portal de GitHub sea fantástico, pero no tanto como para pasar ahí horas leyendo documentos por lo que de esta manera puedes hacerlo desde tu lector de documentos Markdown favorito.
GitHub Gits
Link: https://gist.github.com
Link: https://docs.github.com/es/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists
[!note] Gits Permite una forma elegante y sencilla de compartir un fragmento de código para debatir.
[! tip] Uso de GITS
- Crear un Gist: Ingresa a gist.github.com, pega el fragmento de código y añade una descripción breve.
- Compartir el enlace: Copia la URL generada y compártela con tus colaboradores para abrir la discusión.
- Feedback en tiempo real: Los colaboradores pueden comentar directamente en el Gist, permitiendo iteraciones y mejoras rápidas.
[! success] Beneficios Además de la colaboración, los Gists son útiles para mantener una biblioteca personal de snippets de código, mejorando la eficiencia en nuevos proyectos.
- Biblioteca personal: Guarda configuraciones iniciales o fragmentos reutilizables para evitar escribir código repetitivo.
- Probar ideas antes de integrarlas: Permite experimentar con variantes de código antes de incorporarlas oficialmente.
- Ahorro de tiempo: Facilita el acceso y reutilización de código en proyectos similares, optimizando el flujo de trabajo.
GitHub Pages
[! note] GitHub Pages Para crear un sitio web, no importa si es dinámico o estático. Link: https://pages.github.com Link: https://docs.github.com/es/pages/quickstart
GitHub Codespaces
[! note] Ambiente de desarrollo en la nube. Link: https://docs.github.com/en/codespaces Link: https://github.com/codespaces Link: https://docs.github.com/es/codespaces/getting-started/understanding-the-codespace-lifecycle
Configuración y Desarrollo en la Nube
[! hint] Para iniciar un Codespace
- Selecciona “New Codespace” en el menú.
- Escoge el repositorio en el que vas a trabajar.
- Elige la rama y región que prefieras.
- Configura el tipo de máquina virtual, seleccionando entre diferentes núcleos y memoria RAM según la necesidad del proyecto.
Una vez creado, se abre una interfaz de desarrollo completa, que incluye explorador de archivos, terminal integrada y control de versiones.
[!warning] ¿Por qué es importante eliminar Codespaces al terminar? Cada Codespace utiliza recursos de GitHub y, en cuentas gratuitas, existe un límite de 120 horas de uso al mes. Al completar una tarea:
- Elimina el Codespace para evitar cargos adicionales.
- Desde “My Codespaces”, selecciona el Codespace y elige “delete” para confirmar la eliminación.
Este proceso garantiza que solo uses el tiempo necesario y no excedas el límite de la cuenta gratuita.
[!note] Las ventajas de usar entornos de desarrollo avanzados en GitHub Codespaces incluyen:
- Configuración rápida: Permite crear entornos preconfigurados con solo un clic, ahorrando tiempo.
- Accesibilidad: Puedes acceder a tu entorno desde cualquier lugar con conexión a internet.
- Colaboración: Facilita la colaboración en tiempo real con otros desarrolladores.
- Integración: Funciona perfectamente con GitHub y sus herramientas, como pull requests e issues.
- Personalización: Puedes añadir extensiones y personalizar tu entorno según tus necesidades.
Estos beneficios mejoran la productividad y simplifican el flujo de trabajo en proyectos de software.
Live Share
¿Qué ventajas tiene trabajar en la nube con Codespaces y Live Share?
- Colaboración segura: Permites acceso solo al entorno de Codespaces en la nube, manteniendo tu espacio local aislado.
- Facilidad para múltiples colaboradores: Puedes compartir el enlace con más de un participante, y al terminar la sesión todos los cambios pueden unificarse en un solo commit.
- Entorno unificado: Todos los participantes trabajan con el mismo set de extensiones y configuración, lo que facilita la integración y el seguimiento del proyecto.
[! info] Devcontainer ¿Qué configuraciones están disponibles en el archivo devcontainer.json? Dentro de cada plantilla, encontrarás una carpeta
.devcontainer
que contiene el archivodevcontainer.json
. Este archivo:
- Define el entorno que tu Codespace utilizará, configurando lenguajes y herramientas específicos, como Python en el caso de un proyecto Django.
- Permite agregar extensiones de Visual Studio Code necesarias para el proyecto. Por ejemplo, al agregar la extensión “Live Share”, puedes activarla en el archivo
devcontainer.json
para que esté disponible en futuras sesiones.
GitHub Dev Editor
El GitHub.dev Editor es un entorno de edición de texto que permite realizar cambios rápidos en los archivos de un repositorio sin necesidad de abrir un entorno de desarrollo completo. Algunas de sus características son:
- Interfaz similar a Visual Studio Code: Proporciona una experiencia familiar al usuario.
- Edición rápida: Permite editar cualquier archivo de un repositorio de manera sencilla.
- Sin costos adicionales: A diferencia de Codespaces, no genera costos.
- Sin terminal: Es solo un editor de texto, no incluye funcionalidades avanzadas de desarrollo como la terminal. Es ideal para modificaciones pequeñas y rápidas.
GitHub Tokens
[!note] Invitar sin ser colaborador GitHub ofrece dos tipos de tokens:
- Tokens Clásicos: Permiten seleccionar permisos básicos y pueden tener duración indefinida (aunque no es recomendable).
- Tokens Detallados: Versiones más nuevas que permiten control granular y una duración máxima de 90 días. Ideal para asegurar un acceso mucho más restringido.
[!info] Clásico
- Acceso a Configuración: Ve a “Settings” en tu perfil y selecciona “Developer Settings”.
- Generar Token: Elige “Generate New Token” y configura:
- Nombre: Ayuda a identificar el propósito del token.
- Expiración: Ajusta a la duración esperada del proyecto.
- Permisos: Elige los accesos que consideres necesarios (repos, paquetes, notificaciones, etc.).
- Guardar Token: Copia el token en un lugar seguro, ya que no será visible nuevamente después de cerrar la página.
[!note] Detallados A diferencia de los tokens clásicos, los detallados permiten:
- Duración Máxima de 90 Días: Ofrece seguridad adicional al limitar el tiempo de acceso.
- Control de Repositorio Específico: Puedes configurar que el token tenga acceso solo a repositorios específicos, incluso privados o públicos.
- Permisos Granulares: Permiten ajustar más a detalle el alcance y las acciones que el token puede realizar.
[!warning] Seguridad
- Configurar expiración: Limita la duración del token según las necesidades.
- Reducir permisos: Otorga solo los permisos mínimos necesarios.
- Revisión y eliminación: Revisa periódicamente los tokens en uso y elimina aquellos que ya no sean necesarios para evitar riesgos de acceso no autorizado.
¿Para qué otras tareas se pueden utilizar los tokens?
Los tokens no solo sirven para acceder desde equipos remotos; su funcionalidad se extiende a:
- Automatización con GitHub Actions: Automatiza flujos de trabajo en tu repositorio.
- Scripts Personalizados: Ideal para automatizar tareas repetitivas como commits periódicos o sincronización de proyectos.
- Integración con Terceros: Configura accesos específicos para aplicaciones que interactúan con tu repositorio.
Dependabot
Cuando Dependabot encuentra una vulnerabilidad:
- Notifica con prioridad la versión insegura del paquete.
- Crea un pull request para actualizar el paquete a una versión segura.
- Permite revisar y aceptar la actualización directamente desde la sección de Security o en Pull Requests. Dependabot analiza la compatibilidad de versiones para asegurar que la actualización sea estable y, en algunos casos, puede incluso eliminar la rama creada una vez fusionada la actualización.
Dependabot simplifica la gestión de actualizaciones:
- Detecta y repara vulnerabilidades sin intervención manual.
- Mantiene el proyecto actualizado con las versiones estables más recientes de cada dependencia.
- Agiliza la revisión y aplicación de actualizaciones, evitando que el equipo trabaje con versiones obsoletas.
[!info] Activar Dependabot:
- Accede a Settings o Security dentro del repositorio.
- Ve a Code Security and Analysis y selecciona la categoría de Dependabot.
- Activa las alertas de seguridad y actualizaciones de versión.
- Dependabot generará un archivo
dependabot.yml
, donde puedes ajustar la frecuencia de las revisiones, como cambiar de semanal a diaria para detectar actualizaciones con mayor regularidad.
Plantilla Issues
# Informe de Documentación
## Introducción
Este informe proporciona una visión general de la documentación del proyecto. Aquí se detallan los aspectos más relevantes, así como los recursos disponibles para los usuarios y desarrolladores.
## Objetivos
- Proporcionar información clara y accesible sobre el proyecto.
- Facilitar el uso y la colaboración en el desarrollo del software.
- Mantener la documentación actualizada y relevante.
## Estructura de la Documentación
La documentación se organiza en las siguientes secciones:
1. **Introducción**
- Descripción general del proyecto.
- Requisitos previos.
2. **Instalación**
- Instrucciones para instalar el proyecto.
- Dependencias necesarias.
3. **Uso**
- Ejemplos de uso.
- Comandos disponibles.
4. **Contribución**
- Guía para contribuir al proyecto.
- Normas de estilo y buenas prácticas.
5. **Licencia**
- Información sobre la licencia del proyecto.
## Recursos Adicionales
- [Repositorio del Proyecto](URL_DEL_REPOSITORIO)
- [Wiki del Proyecto](URL_DEL_WIKI)
- [Issues y Solicitudes de Extracción](URL_DE_ISSUES)
## Mantenimiento de la Documentación
La documentación debe ser revisada y actualizada regularmente. Se recomienda realizar una revisión cada vez que se implementen cambios significativos en el código.
## Conclusión
Una documentación bien estructurada es clave para el éxito del proyecto. Agradecemos cualquier contribución o sugerencia para mejorar este informe.
---
**Fecha de Actualización:** YYYY-MM-DD
**Autor:** Tu Nombre
Recursos
- https://www.youtube.com/watch?v=niPExbK8lSw
- https://www.youtube.com/watch?v=VdGzPZ31ts8
- https://www.youtube.com/watch?v=3GymExBkKjE (5-horas)
- https://www.freecodecamp.org/espanol/news/aprende-git-y-github-curso-desde-cero/
- https://learngitbranching.js.org/?locale=es_ES (Tipo Juego para aprender Git)
- https://morioh.com/a/3c8d48d43f17/git-github-and-markdown-cheat-sheet (Cheat Sheet)
- https://www.youtube.com/watch?v=mBYSUUnMt9M