Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Stewart-DevTeam-Team/stewart_prealpha/llms.txt

Use this file to discover all available pages before exploring further.

Las contribuciones a Stewart siguen un flujo de trabajo basado en ramas de Git. Cada tarea —ya sea una nueva función, una corrección o cambios de documentación— vive en su propia rama hasta ser revisada y aprobada mediante un Pull Request. Esta guía explica ese proceso de principio a fin.

​
Flujo de contribución

1

Actualizar la rama principal

Antes de empezar cualquier tarea, asegúrate de tener la última versión del código en tu máquina:
terminal
git checkout main
git pull
Mantener main actualizada evita conflictos al crear tu rama y facilita la revisión del Pull Request.
2

Crear una rama para tu tarea

Crea una rama con un nombre descriptivo que siga la convención <tipo>/<nombre-descriptivo>:
terminal
git checkout -b <tipo>/<nombre-descriptivo>
Tipos de rama habituales:
TipoUso
featNueva funcionalidad
fixCorrección de un bug
docsCambios en documentación
choreTareas de mantenimiento o configuración
refactorReestructuración de código sin cambiar comportamiento
artAdición o modificación de assets visuales
audioAdición o modificación de música o efectos de sonido
Ejemplos:
terminal
git checkout -b feat/sistema-dialogo
git checkout -b fix/colision-personaje
git checkout -b docs/guia-contribucion
3

Hacer commits con el formato convencional

Sigue la especificación de Conventional Commits para todos tus commits. El formato es:
<tipo>(<ámbito opcional>): <descripción corta>

git commit -m "feat(dialogo): agregar sistema de opciones de respuesta"
4

Subir los cambios a tu rama

Sube tu rama al repositorio remoto en GitHub:
terminal
git push origin <nombre-de-la-rama>
Ejemplo:
terminal
git push origin feat/sistema-dialogo
5

Abrir un Pull Request

Ve al repositorio en GitHub y abre un Pull Request desde tu rama hacia main.En la descripción del PR, incluye:
  • Qué cambios hiciste y por qué.
  • Si aplica, capturas de pantalla o clips del resultado.
  • Referencias a issues o tareas relacionadas en Notion.
Un miembro del equipo revisará el PR antes de hacer el merge.
Puedes gestionar todo este flujo —clonar, crear ramas, hacer commits y abrir PRs— desde GitHub Desktop sin usar la terminal. Es una buena opción si prefieres una interfaz visual.

Build docs developers (and LLMs) love

Get started for freeTalk to us