|
|
# Organisation du travail collaboratif
|
|
|
## Issue
|
|
|
Une *issue* peut qualifier :
|
|
|
* une erreur dans le code, où la description de l'*issue* permet de comprendre le lieu et la nature de l'erreur ou du dysfonctionnement
|
|
|
* une proposition d'amélioration
|
|
|
* une tâche à réaliser
|
|
|
Voir [les pages Wiki disponibles](https://framagit.org/webradio-malraux/systeme-information/website/wikis/pages)
|
|
|
|
|
|
Dans les deux derniers cas, la description de l'*issue* doit être structurée afin de saisir l'objectif de l'amélioration ou de la tâche à réaliser (nous pourrions par exemple nous en servir comme d'un cahier des charges).
|
|
|
|
|
|
## Label
|
|
|
Les *labels* permettent de qualifier le type de l'*issue*.
|
|
|
|
|
|
## Milestone
|
|
|
Comme son nom l'indique, c'est un jalon temporel auquel nous pouvons associer des *issues*.
|
|
|
|
|
|
Globalement il s'agit des jalons de livraison d'une version, ou bien dans notre cas d'un moment particulier dans la vie de la radio pour lequel des fonctionnalités sont particulièrement attendues.
|
|
|
|
|
|
## Dépôt `git`
|
|
|
Le dépôt `git` est conçu par défaut avec une branche nommée `master`. Cette branche doit être considérée comme la branche fonctionnelle du projet. C'est à dire que si nous faisons un clone du dépôt et que nous exécutons la branche `master`, alors elle est **opérationnelle**, même si elle ne popssède pas beaucoup de fonctionnalités.
|
|
|
|
|
|
Le développement des fonctionnalités et leurs mises au point doit donc se faire dans un *monde parallèle* que sont les **branches**.
|
|
|
|
|
|
### Branches
|
|
|
Je propose d'organiser notre flux de travail selon l'organisation du [*workflow* de Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) tout en adaptant les termes et en complétant avec les préconisations faites par [Florent Lebreton](https://makina-corpus.com/blog/metier/2014/un-workflow-git-efficace-pour-les-projets-a-moyen-long-terme) qui stipule :
|
|
|
1. Un (et un seul) mainteneur, qui gère le dépôt Git et les releases ;
|
|
|
1. Ne jamais commiter directement sur la branche master ;
|
|
|
1. Ne jamais faire de rebase de master sur une autre branche ;
|
|
|
1. Ne pas sortir du workflow prévu.
|
|
|
|
|
|
**Un didacticiel visuel proposé par [Wei Wang](https://onlywei.github.io/explain-git-with-d3/) permet de comprendre les mécanismes de branchage et de fusion.**
|
|
|
|
|
|
### Exemples
|
|
|
#### Mise en œuvre de la branche commune de développement
|
|
|
```bash
|
|
|
git checkout master
|
|
|
git branch develop
|
|
|
git checkout develop
|
|
|
```
|
|
|
|
|
|
#### Travail courant sur une tentative de mise en œuvre d'une fonctionnalité (de gestion de la base de données par exemple = **database**)
|
|
|
Création de la branche de travail :
|
|
|
```bash
|
|
|
git checkout develop
|
|
|
git branch fonct/database
|
|
|
git checkout fonct/database
|
|
|
```
|
|
|
Effectuer les modifications nécessaires :
|
|
|
```bash
|
|
|
... # faire des modifications dans les fichiers
|
|
|
git add fichier_modifie.py fichier_modifie.sqlite3
|
|
|
git commit -m "Implémentation de la fonctionnalité de gestion de la base de données"
|
|
|
git push origin fonct/database
|
|
|
```
|
|
|
et répéter ces opérations de modification tant que nous ne sommes pas satisfait du résultat.
|
|
|
|
|
|
Puis, lorsque la fonctionnalité semble satisfaisante, l'intégrer dans la branche `develop` :
|
|
|
```bash
|
|
|
git checkout develop
|
|
|
git merge --no-ff fonct/database
|
|
|
git branch -d fonct/database # suppression optionnelle de la branche
|
|
|
git push origin develop
|
|
|
```
|
|
|
|
|
|
Enfin, pour que le code soit visible sur le serveur de [`test`](http://radio.lycee-malraux-72.net:81/), il faut fusionner les modification de la branche `develop` dans la branche `test` :
|
|
|
```bash
|
|
|
git checkout test
|
|
|
git merge --no-ff develop
|
|
|
git push origin test
|
|
|
```
|
|
|
|
|
|
## Wiki
|
|
|
# Wiki
|
|
|
Des aides courantes comme celle-ci peuvent trouver leur place dans le **Wiki**. Pour autant, dès lors qu'il s'agit de la documentation du projet, **elle doit être conçue [dans le dépôt réservé](https://framagit.org/webradio-malraux/systeme-information/documentation)** |
|
|
\ No newline at end of file |