Ajout de la contribution avec Git - Part 3
This commit is contained in:
parent
8a38a53f99
commit
9b1ad7a26a
1 changed files with 26 additions and 2 deletions
28
README.md
28
README.md
|
@ -137,7 +137,7 @@ Les variables et les classes commencent généralement plutôt par un nom.
|
||||||
|
|
||||||
###### Export glTF
|
###### Export glTF
|
||||||
|
|
||||||
Les objets à destination du mùoteur de jeu Godot doivent être exportés au format glTF. Il faut pour cela sélectionner tous les objets à exporter puis aller dans `File > Export > glTF`, avec les options suivantes à vérifier particulièrement :
|
Les objets à destination du moteur de jeu Godot doivent être exportés au format glTF. Il faut pour cela sélectionner tous les objets à exporter puis aller dans `File > Export > glTF`, avec les options suivantes à vérifier particulièrement :
|
||||||
- `Format > glTF Embeddded`.
|
- `Format > glTF Embeddded`.
|
||||||
- `Copyright : Khaganat`.
|
- `Copyright : Khaganat`.
|
||||||
- On peut cocher `Remember export settings` pour ne pas avoir à revérifier à chaque export de ces modèles.
|
- On peut cocher `Remember export settings` pour ne pas avoir à revérifier à chaque export de ces modèles.
|
||||||
|
@ -148,7 +148,31 @@ Les autres options par défaut conviennent.
|
||||||
|
|
||||||
## Le suivi de version avec Git
|
## Le suivi de version avec Git
|
||||||
### Le dépôt principal
|
### Le dépôt principal
|
||||||
|
Le dépôt de référence et sa branche principale « main » doivent avoir un historique le plus propre possible. C’est la raison pour laquelle il convient de toujours travailler par le biais de forks et de merge requests via la forge gitlab de Khaganat : https://git.numenaute.org/khaganat.
|
||||||
|
|
||||||
|
Cela permet à chaque contributrice de travailler en local via son propre fork distant. Elle peut ensuite proposer son code une fois prêt via une merge request qui sera auditée par une autre contributrice ayant l’accès au dépôt principal (rôle de **developper**, **maintainer** voire **owner** du dépôt principal). C’est lors de cette étape de validation avant fusion/merge qu’un contrôle sera opéré non seulement sur le code en lui-même, mais également sur la rédaction du message de [commit](#les-commits).
|
||||||
|
|
||||||
### Forker sur gitlab / cloner en local
|
### Forker sur gitlab / cloner en local
|
||||||
|
#### Forker : copie distante
|
||||||
|
|
||||||
|
En cliquant sur le bouton « Fork » sur le projet principal, vous allez créer une copie distante sur la forge Gitlab, ce sera votre dépôt de développement depuis lequel vous pourrez opérer des emrge request. Vous pouvez le gérer comme bon vous semble, mais dans le doute, vous pouvez laisser les options proposées par défaut si vous comptez simplement vous en servir comme base pour contribuer au code.
|
||||||
|
|
||||||
|
### Cloner : copie locale
|
||||||
|
Une fois votre dépôt distant créé (appelé _origin remote_ dans le jargon Git), vous allez le copier sur votre ordinateur local pour travailler, cela se fait via la commande `git clone`.
|
||||||
|
|
||||||
|
Pour obtenir l’adresse à cloner, il faut cliquer sur le bouton « Clone » de l’interface gitlab sur la page d’accueil du dépôt. Vous pourrez choisir soit par _https_, soit par _ssh_. Préférez toujours de passer par _ssh_.
|
||||||
|
|
||||||
|
$ git clone ssh://git@port.numenaute.org:3543/yannk/khanat_gamedev_guide.git
|
||||||
|
|
||||||
|
Cela va copier le dépôt dans un sous-répertoire de l’endroit où vous avez tapé la commande. Il vous faudra alors vous y déplacer pour travailler.
|
||||||
|
|
||||||
|
Une étape essentielle est ensuite d’ajouter le dépôt principal sur une branche locale de façon à pouvoir récupérer la dernière version du code du dépôt principal quand vous travaillez sur vos propres implémentations. Cela se fait en ajoutant une branche, appelée conventionnellement _upstream_ et pointant vers le dépôt principal, dont l’adresse est indiquée par le même bouton « Clone » sur sa page gitlab.
|
||||||
|
|
||||||
|
$ git remote add upstream ssh://git@port.numenaute.org:3543/khaganat/mmorpg_khanat/khanat_gamedev_guide.git
|
||||||
|
|
||||||
|
|
||||||
|
#### Le travail en local
|
||||||
|
|
||||||
### Gestion des branches
|
### Gestion des branches
|
||||||
### Le merge request
|
### Le merge request
|
||||||
### Les commits
|
### Les commits
|
||||||
|
@ -215,7 +239,7 @@ Facultatif, il permet de décrire de façon détaillée ce qui a motivé les cho
|
||||||
|
|
||||||
Il peut comporter deux éléments :
|
Il peut comporter deux éléments :
|
||||||
|
|
||||||
- si le commit clôt un ticket, il faut indiquersur une ligne son numéro de la façon suivante : `« Close #58 »`
|
- si le commit clôt un ticket, il faut indiquer sur une ligne son numéro de la façon suivante : `« Close #58 »`
|
||||||
- si le commit entraîne une rupture de compatibilité, il doit comporter une ligne avec la mention « BREAKING CHANGES » en majuscules.
|
- si le commit entraîne une rupture de compatibilité, il doit comporter une ligne avec la mention « BREAKING CHANGES » en majuscules.
|
||||||
|
|
||||||
### Projets Godot
|
### Projets Godot
|
||||||
|
|
Loading…
Reference in a new issue