Collaborer sur Sanctuary 26.2

main représente toujours la dernière version intégrée et jouable. Le travail se fait dans des branches courtes, puis arrive régulièrement sur main par petites pull requests testées. Ainsi, une correction de bug et une nouvelle fonctionnalité peuvent avancer en parallèle sans s'écraser.

Première installation

git clone https://git.botsu.net/koka/sanctuary.git sanctuary-26.2
cd sanctuary-26.2
./scripts/install-git-hooks.sh
./gradlew check

Les hooks empêchent les commits directs sur main, contrôlent les noms de branches et exécutent la vérification du workspace avant un push. Ils ne remplacent pas la CI du serveur.

Créer une branche

Toujours repartir de la version distante courante :

git switch main
git pull --ff-only
git switch -c feature/casino
git push -u origin feature/casino

Préfixes utilisés :

feature/casino pour une fonctionnalité ;
fix/crash-portail pour une correction ;
integration/casino-shop pour relier plusieurs mods ;
docs/economie pour la documentation ;
chore/gradle pour la maintenance ;
release/26.2.0-alpha.196 pour préparer une publication.

Chaque personne ou agent travaille dans sa propre branche. Si deux travaux doivent toucher le même fichier central (gradle.properties, build.gradle, une API ou un registre), le signaler dans les pull requests et convenir de l'ordre de fusion.

Exemple : développer le casino

Le casino commence dans feature/casino. Avant de coder, décider quel module possède chaque responsabilité. Par exemple, les règles amusantes et jeux peuvent appartenir à onlyfun, tandis que la monnaie/progression reste sous l'autorité de sanctuary. Le casino appelle alors une API publique de Sanctuary au lieu de dupliquer un solde ou d'écrire directement dans ses données.

Pendant le développement :

./gradlew :onlyfun:check :sanctuary:check
git add onlyfun sanctuary
git commit -m "Add casino game foundation"
git push

Pour récupérer les corrections de bugs déjà fusionnées dans main :

git fetch origin
git merge origin/main
./gradlew check
git push

Utiliser merge sur une branche déjà partagée afin de ne pas réécrire l'historique de son collègue. Un rebase reste acceptable seulement sur une branche personnelle qui n'a jamais été poussée.

Intégration entre mods

Avant une pull request qui touche plusieurs modules, vérifier :

le module propriétaire de la donnée, de la règle et de l'ID ;
l'API publique utilisée par les autres modules ;
la dépendance déclarée dans Gradle, sans nouveau cycle ;
le comportement quand un payload vient d'un client ancien ou invalide ;
la compatibilité des sauvegardes, ou la migration et son data_version ;
les tests serveur, client et multijoueur utiles ;
les traductions FR/EN/RU et les ressources de chaque namespace ;
la version de chaque module touché et la version du pack si une release est créée.

Envoyer et fusionner

Faire des commits relisibles et pousser souvent la branche avec git push.
Ouvrir une pull request vers main, même en brouillon pendant une coordination longue.
Remplir la checklist, attendre la CI verte et faire relire par l'autre personne.
Fusionner la pull request. Éviter les gros lots : chaque étape complète et jouable peut rejoindre main séparément.
Revenir sur main, exécuter git pull --ff-only, puis créer la branche suivante.

Ne jamais utiliser git push --force sur main, ni fusionner une branche dont ./gradlew check échoue. Les urgences suivent le même chemin avec une petite branche fix/....

Protection recommandée dans Gitea

Dans Settings > Branches > Branch protection, protéger main avec les règles suivantes :

push direct interdit, fusion par pull request uniquement ;
au moins une approbation ;
conversation résolue avant fusion ;
vérification Verification 26.2 / check obligatoire ;
force push et suppression de branche interdits.

Conserver les droits de push normaux sur feature/*, fix/*, integration/*, docs/*, chore/* et release/*.

4.1 KiB Raw Permalink Blame History