Différences
Ci-dessous, les différences entre deux révisions de la page.
Prochaine révision | Révision précédente | ||
fr:collabo_client_3d_assets [2021/10/11 12:42] – créée YannK | fr:collabo_client_3d_assets [2021/10/11 12:57] (Version actuelle) – supprimée YannK | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Collaborer aux assets 3D du client de jeu 3D Godot ====== | ||
- | {{ : | ||
- | |||
- | ===== Le workflow de travail ===== | ||
- | |||
- | <WRAP center round info 90%> | ||
- | Créez toujours [[# | ||
- | \\ 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> | ||
- | |||
- | Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet. | ||
- | |||
- | {{: | ||
- | |||
- | 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> | ||
- | |||
- | Vous n' | ||
- | |||
- | ==== Le dépôt et ses branches ==== | ||
- | |||
- | <WRAP center round important 60%> | ||
- | Si vous n’avez pas accès en tant que développeur à notre dépôt officiel et travaillez depuis votre fork, merci de nous confirmer que la procédure fonctionne bien pour vous. | ||
- | </ | ||
- | |||
- | |||
- | Khanat utilise un workflow simplifié. Les branches principales sont : | ||
- | |||
- | * Branche **main** : c’est la branche qui contient les assets prêts à être intégrés au client de jeu. | ||
- | |||
- | * Branche **XXX_titre_du_ticket** : Branche contenant le développement d’un ticket (voir ci-dessous) XXX, en cours de travail. | ||
- | |||
- | * Branche **develop** : Branche par défaut sur laquelle les ajouts récents se trouvent, qui est celle qui vise à contenir les tâches des tickets définis pour le Milestone en cours. | ||
- | |||
- | Les branches de module, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommées de la façon suivante : | ||
- | |||
- | * Branche **Module** : Doit être nommée " | ||
- | * Exemple : pour travailler sur le ticket numéro 2 titré « Faire une des tâches détaillée de la tâche globale XXX », il faut créer une branche « 2-faire-une-des-taches-detaillee-de-la-tache-globale-xxx » | ||
- | |||
- | Si vous êtes développeur officiel chez nous, vous pourrez créer automatiquement la branche et la merge request depuis l’issue en cliquant sur le bouton prévu : | ||
- | |||
- | {{ : | ||
- | |||
- | |||
- | ==== Travail sur un ticket ==== | ||
- | |||
- | Si vous travaillez depuis un fork, vous devez créer une Merge Request, à destination de **develop** sur notre dépôt. Cette requête doit respecter ces impératifs : | ||
- | |||
- | * elle doit avoir comme titre « Draft: Resolve "titre du ticket" | ||
- | * elle doit comporter en première ligne de sa description une commande pour fermer le ticket correspondant. Dans notre cas, ce serait « Closes #2 ». | ||
- | |||
- | ==== Merge sur la branche « stable » ==== | ||
- | |||
- | Une fois que l’ensemble des Tickets/ | ||
- | |||
- | Il est indispensable de bien vérifier le changelog à ce moment là, selon le modèle de [keepachangelog.com](https:// | ||
- | |||
- | Lors du commit de merge, il faudra passer une commande pour que la CI de Gitlab exporte vers le dépôt où seront les assets sous le format utilisé par le moteur de jeu Godot ([[https:// | ||
- | ===== Gestion des Merge Request ===== | ||
- | |||
- | Il ne faut pas hésiter à laisser des commentaires sur la demande de Merge Request, cette page est là pour expliquer les soucis, détailler l’approche etc. Cela permet de s’assurer que les solutions retenues sont pertinentes pour les autres contributrices et de faciliter l’intégration finale. | ||
- | |||
- | Lors de la validation de la Merge Request, on efface la branche de travail et on ne squashe pas les commits. | ||
- | |||
- | **Dans la mesure du possible, on ne merge jamais soi-même directement**. | ||
- | |||
- | ===== Gestion des Tickets / Issues ===== | ||
- | Créez les demandes de fonctionnalités ou les erreurs sur le [[gitlab> | ||
- | |||
- | <WRAP center round info 80%> | ||
- | |||
- | Avant de commencer une tâche qui n’existe pas, créez une Issue que vous vous attribuez, comme ça on sait que quelqu' | ||
- | </ | ||
- | |||
- | |||
- | Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'// | ||
- | |||
- | Il suffit de cliquer sur : {{ : | ||
- | |||
- | Vous renseignez ensuite les différents champs. | ||
- | |||
- | Le titre doit être concis et le plus explicite possible. | ||
- | \\ Par contre, n' | ||
- | |||
- | Il y a ensuite quelques zones de champs à renseigner : | ||
- | |||
- | * // | ||
- | * //Labels// permet de choisir des tags pour déterminer le genre de tâche (voir [[# | ||
- | |||
- | Dans le doute, n' | ||
- | |||
- | ===== Gestion des messages dans les Tickets / Issues ===== | ||
- | |||
- | Pour chaque ticket, il est possible de laisser des messages. Chacun d’eux initie un fil de discussion auquel on peut répondre en cliquant sur l’icône de bulle dans son coin supérieur droit. Cela permet de conserver des fils thématiques sur des sujets abordés par le ticket. | ||
- | |||
- | {{ : | ||
- | |||
- | ===== Gestion des dossiers et des fichiers ===== | ||
- | |||
- | Les noms des dossiers et des fichiers sont écrits en [[https:// | ||
- | |||
- | **Les commentaires dans le code/les scripts se font en anglais**, de façon à ce que le code soit international. | ||
- | |||
- | Pour chaque fichier d’assets, il faut impérativement y adjoindre un fichier //.json// de même nom, qui comportera le suivi des contributions, | ||
- | |||
- | La structure du fichier est la suivante : | ||
- | <WRAP prewrap 600px> | ||
- | |||
- | <code json myasset.svg.json > | ||
- | { | ||
- | " | ||
- | [{ | ||
- | " | ||
- | " | ||
- | " | ||
- | }, | ||
- | { | ||
- | " | ||
- | " | ||
- | " | ||
- | }], | ||
- | " | ||
- | } | ||
- | </ | ||
- | </ | ||
- | |||
- | Description : | ||
- | * contributors : | ||
- | * indiquer le nom/le pseudonyme (obligatoire), | ||
- | * licence : | ||
- | * indiquer la licence appliquée aux fichiers de ce répertoire, | ||
- | |||
- | N' | ||
- | |||
- | <WRAP center round todo 60%> | ||
- | Le nommage des assets devra obéir à une certaine nomenclature sur les dépôts officiels, afin d' | ||
- | </ | ||
- | |||
- | ===== Gestion des Commits ===== | ||
- | |||
- | **On rédige ses commits en anglais**, de façon à ce que le code soit international (même si c’est du franglais, aucune importance). Ne pas hésiter à remettre dans chaque message de Commit le numéro de ticket correspondant, | ||
- | |||
- | ===== Gestion des Milestones ===== | ||
- | |||
- | On se servira des // | ||
- | |||
- | ===== Gestion des Tags ===== | ||
- | |||
- | Nous n' | ||
- | |||
- | ===== Gestion des Labels ===== | ||
- | La liste des Labels/ | ||
- | |||
- | |||
- | {{tag> |