====== Collaborer sur Khanat assets - OpenNeL legacy ======
Cette page n’est conservée que pour des raisons historiques. Il n’y a plus lieu de collaborer à ce dépôt.
{{ :fr:picture.png?nolink |}}
Ce dépôt concerne les éléments graphiques en 2D et en 3D qui seront ensuite passés au pipeline pour fournir les éléments nécessaires au système de jeu selon ses spécifications.
Leur organisation, nomenclature et formats sont très fortement encadrés pour [[fr:tag:graphisme:3d:pipeline:start|le pipeline]]. Il faut absolument se renseigner sur leurs spécificités avant d'ajouter du contenu, sans quoi le risque est grand que le fichier soit ignoré ou, pire encore, fasse planter le pipeline.
Les fichiers sources n'y ont pas du tout leur place. Ceux-ci doivent aller dans [[fr:collabo_khanat-assets-sources|khanat-assets-sources]]
===== Le workflow de travail =====
Créez toujours une [[#gestion_des_issues|Issue]] avant de commencer une tâche qui n'y est pas référencée.
\\ Cela permet de suivre le travail en vérifiant si une branche Git avec ce numéro existe, de façon à éviter de refaire du travail déjà commencé.
==== Avoir un dépôt sur lequel travailler ===
=== Mise en place d'un dépôt personnel (fork) ====
Pour commencer, il vous faudra forker le dépôt principal : [[gitlab>khaganat/khanat-assets|khanat-assets]]. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.
Pour cela, il vous suffit de cliquer sur le bouton suivant sur la page d’accueil du projet.
{{:fr:fork.png}}
Vous serrez alors redirigé vers votre copie du dépôt.
=== Travailler directement sur le dépôt principal ===
Si vous êtes un développeur "officiel" chez nous, vous aurez accès au dépôt principal sur notre GitLab : [[gitlab>khaganat/khanat-assets|khanat-assets]].
Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.
==== Le dépôt et ses branches ====
Khanat utilise un workflow inspiré de [[fr:gitflow]]. De ce fait, il y a deux types de branches : principales et temporaires.
Les branches principales sont :
* Branche **Master** (aka Lirria) : Branche **stable**, où seuls des éléments d'organisations importants sont autorisés à être mergés directement. Cette branche garantit un serveur fonctionnel, dans la mesure du possible.
* Branche **Spofu** : Branche de test, qui permet de tester sur le serveur spofu de nouvelles données.
À cela s'ajoute des branches temporaires, ouvertes et fermées suivants les besoins:
* Branche **Feature** : C'est **une nouvelle addition** au contenu de Khanat, développée dans une branche séparée afin de réduire les risque d'introduction de bugs. Elle sera à merge sur la branche "spofu" pour tester ou, si cela n'est pas jugé nécessaire, sur "lirria".
Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommés de la façon suivante:
* Branche **Feature** : Doit être nommée "feature/[numéro(s) de(s) (l')issue][nom de la feature sans espaces ni ponctuation]"
* Exemple : "feature/43-mission_peche"
==== Organisation des dossiers et fichiers ====
Les fichiers doivent impérativement respecter [[fr:les_conventions_de_nommage|les conventions de nommage des fichiers graphiques]], et le format selon leur type.
En outre, pour le bon fonctionnement du [[fr:tag:graphisme:3d:pipeline:start|pipeline]], leur organisation en répertoire et sous-répertoire est très codifiée. Il faut absolument se référer à l'organisation de celui-ci avant toute intervention.
==== Publication d'une feature ====
Une fois que vous considérez la feature que vous avez développé terminée, vous pouvez créer une Merge Request, à destination de **Spofu** voire de **Master**. Cette requête doit respecter ces impératifs :
* La Merge Request doit clairement expliquer en quoi elle répond à la feature
===== Gestion des Merge Request =====
Lorsqu'on a terminé une //Feature//, il faut faire une demande de //Merge Request// en expliquant en quoi la tâche est terminée et l'affecter à une autre personne même si on a la capacité de merger directement.
Cela permettra d'avoir un contrôle, ne serait-ce que formel, sur l'ajout.
**On ne merge jamais soi-même directement sur Master**.
===== Gestion des Issues =====
Avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça vous pouvez numéroter la branche correctement et on sait que quelqu'un a commencé à travailler sur ce sujet.
Les travaux à faire qui entraînent des modifications de fichier, créations, doivent être indiqués en faisant référence aux //Issues// de ce dépôt : [[gitlab>khaganat/khanat-assets-sources/issues|Issue sur Khanat-assets-sources]] qui contiennent la source des ajouts. Une nouvelle //Issue// doit éventuellement y être créée.
Il suffit de cliquer sur : {{ :fr:new_issue2.jpg?nolink |}}
Vous renseignez ensuite les différents champs.
Le titre doit être concis et le plus explicite possible.
\\ Par contre, n'hésitez pas à être le plus précis possible dans la zone //Description//.
Il y a ensuite 3 zones de champs à renseigner :
* //Assignee// pour indiquer la personne à qui affecter la tâche ;
* //Milestone// qui désigne la version du projet pour laquelle ce travail devra être fait ;
* //Labels// permet de choisir des tags pour déterminer le genre de tâche ;
* //Select due date// propose de fixer une date de remise des travaux.
Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.
===== Gestion des Milestones =====
On se servira des mêmes //milestones// que pour les autres dépôts et secteurs de développement du projet, présentés sur la page [[fr:milestones]].
===== Gestion des Tags =====
Nous n'utilisons pas de //Tags// sur ce dépôt Git pour le moment.
===== Gestion des Labels =====
Les //Labels// doivent être génériques et concerner de préférence un type technique d'asset graphique et permettre ainsi de regrouper par genre de compétence. Il est possible d'en créer lors de la génération d'une //Issue// si aucune ne convient mais cela peut être fait par la suite, surtout quand on est indécis.
{{tag>Données Ryzom_Core Outils Graphisme}}