|
|
|
Architecture du dépôt
|
|
|
|
==================
|
|
|
|
=====================
|
|
|
|
|
|
|
|
Actuellement, il y a trois branches protégées :
|
|
|
|
- `Production` qui est la version en ligne sur www.cof.ens.fr, seuls les webmasters touchent à ça.
|
|
|
|
- `master`, la version la plus récente du projet. De temps en temps, on merge `master` sur `Production`. En théorie, dev.cof.ens.fr suit
|
|
|
|
cette branche.
|
|
|
|
- `k-fet` qui suit un chemin parallèle à `master`. Elle est gérée à part car elle correspond à l'appli `kfet` développée bien
|
|
|
|
après le reste par @delobell qui est le seul à connaître bien la codebase pour l'instant.
|
|
|
|
- `Production` qui est la version en ligne sur www.cof.ens.fr, seuls les
|
|
|
|
webmasters touchent à ça.
|
|
|
|
- `master`, la version la plus récente du projet. De temps en temps, on merge
|
|
|
|
`master` sur `Production`. En théorie, dev.cof.ens.fr suit cette branche.
|
|
|
|
|
|
|
|
Pour affecter ces branches, il faut passer par une merge request (cf plus bas). Toute autre branche est gérée librement par les
|
|
|
|
personnes qui travaillent dessus.
|
|
|
|
Pour affecter ces branches, il faut passer par une merge request (cf plus bas).
|
|
|
|
Toute autre branche est gérée librement par les personnes qui travaillent
|
|
|
|
dessus.
|
|
|
|
|
|
|
|
Merge requests
|
|
|
|
=============
|
|
|
|
|
|
|
|
Le fonctionnement des dépots cof-geek se fait par merge requests, qui doivent être reviewées par une personne expérimentée (= Master, cf plus bas) qui n'a pas participé à l'écriture du code. En pratique pour faire une merge request, après avoir cloné le dépot, il faut faire une branche séparée avec `git checkout -b login/ma-branche` où `login` est votre pseudo et `ma-branche` un nom simple décrivant les modifications que vous souhaitez apporter. Ensuite faites vos modifications, puis poussez sur le GitLab. Là vous pouvez aller sur l'interface Web et cliquer sur le bouton "faire une merge request" qui apparaît.
|
|
|
|
|
|
|
|
Une fois la merge request effectuée, un Master lira et commentera votre code. Une merge request est une discussion entre l'auteur du code et le reviewer,
|
|
|
|
ne vous pliez pas juste aux demandes du reviewer, votre point de vue compte ! Par ailleurs c'est plus à vous de modifier le code qu'au reviewer, mais cela
|
|
|
|
dépend des situations.
|
|
|
|
|
|
|
|
En cas de manque de reviewer (exemple : un seul master actif), pour que le travail avance, on peut être contraint de faire des entorses à la règle ci-dessus.
|
|
|
|
N'hésitez pas à regarder les merge requests des autres, même sans être master. C'est mieux que rien et toute remarque constructive est bonne à prendre.
|
|
|
|
De plus, c'est une bonne façon de se familiariser avec le code (et pourquoi pas devenir master un jour ;D).
|
|
|
|
==============
|
|
|
|
|
|
|
|
Le fonctionnement des dépots cof-geek se fait par merge requests, qui doivent
|
|
|
|
être reviewées par une personne expérimentée (= Master, cf plus bas) qui n'a pas
|
|
|
|
participé à l'écriture du code. En pratique pour faire une merge request, après
|
|
|
|
avoir cloné le dépot, il faut faire une branche séparée avec
|
|
|
|
`git checkout -b login/ma-branche` où `login` est votre pseudo et `ma-branche`
|
|
|
|
un nom simple décrivant les modifications que vous souhaitez apporter. Ensuite
|
|
|
|
faites vos modifications, puis poussez sur le GitLab. Là vous pouvez aller sur
|
|
|
|
l'interface Web et cliquer sur le bouton "faire une merge request" qui apparaît.
|
|
|
|
|
|
|
|
Une fois la merge request effectuée, un Master lira et commentera votre code.
|
|
|
|
Une merge request est une discussion entre l'auteur du code et le reviewer, ne
|
|
|
|
vous pliez pas juste aux demandes du reviewer, votre point de vue compte ! Par
|
|
|
|
ailleurs c'est plus à vous de modifier le code qu'au reviewer, mais cela dépend
|
|
|
|
des situations.
|
|
|
|
|
|
|
|
N'hésitez pas à regarder les merge requests des autres, même sans être master,
|
|
|
|
toute remarque constructive est bonne à prendre. De plus, c'est une bonne façon
|
|
|
|
de se familiariser avec le code (et pourquoi pas devenir master un jour ;D).
|
|
|
|
|
|
|
|
### Quelques outils pour review son code ou celui des autres
|
|
|
|
|
|
|
|
- [Pylint](https://www.pylint.org/) fait un tas de vérifications et permet notamment d'éviter un certain nombre d'erreurs.
|
|
|
|
- [Flake8](https://pypi.python.org/pypi/flake8) vérifie que les conventions de la [PEP8](https://www.python.org/dev/peps/pep-0008/)
|
|
|
|
(et quelques autres) sont bien respectées. Ce n'est pas une nécessité mais ça peut être une bonne habitude à prendre.
|
|
|
|
- [Pylint](https://www.pylint.org/) fait un tas de vérifications et permet
|
|
|
|
notamment d'éviter un certain nombre d'erreurs.
|
|
|
|
- [Flake8](https://pypi.python.org/pypi/flake8) vérifie que les conventions de
|
|
|
|
la [PEP8](https://www.python.org/dev/peps/pep-0008/) (et quelques autres) sont
|
|
|
|
bien respectées. Ce n'est pas une nécessité mais ça peut être une bonne
|
|
|
|
habitude à prendre. À noter: Django est testé avec flake8 et recommande son
|
|
|
|
usage
|
|
|
|
(https://docs.djangoproject.com/en/1.11/internals/contributing/writing-code/coding-style/)
|
|
|
|
|
|
|
|
Membres
|
|
|
|
========
|
|
|
|
=======
|
|
|
|
|
|
|
|
Il y a trois types de contributeurs à cof-geek.
|
|
|
|
|
|
|
|
Extérieurs
|
|
|
|
--
|
|
|
|
----------
|
|
|
|
|
|
|
|
Les extérieurs sont des gens avec un compte sur le GitLab mais non membres de cof-geek. Ils peuvent contribuer en forkant le dépot et en faisant une merge request. Ils n'ont aucun droit particulier sur le dépôt.
|
|
|
|
Les extérieurs sont des gens avec un compte sur le GitLab mais non membres de
|
|
|
|
cof-geek. Ils peuvent contribuer en forkant le dépot et en faisant une merge
|
|
|
|
request. Ils n'ont aucun droit particulier sur le dépôt.
|
|
|
|
|
|
|
|
Developer
|
|
|
|
--
|
|
|
|
---------
|
|
|
|
|
|
|
|
Le titre de Developer indique un membre de cof-geek, c'est-à-dire quelqu'un présent sur la ML et qui contribue activement (ou pas) du code. Les Developers peuvent accéder au dépôt commun, créer des branches, etc : ce sont donc des gens en qui une certaine confiance est placée.
|
|
|
|
Le titre de Developer indique un membre de cof-geek, c'est-à-dire quelqu'un
|
|
|
|
présent sur la ML et qui contribue activement (ou pas) du code. Les Developers
|
|
|
|
peuvent accéder au dépôt commun, créer des branches, etc : ce sont donc des gens
|
|
|
|
en qui une certaine confiance est placée.
|
|
|
|
|
|
|
|
Master
|
|
|
|
--
|
|
|
|
|
|
|
|
Les membres possédant le titre de Master sont des gens qui connaissent bien au moins une partie du code. Ils ont quelques droits supplémentaires par rapport aux Developers ; en particulier ils peuvent modifier la branche principale (`master`). Ce sont eux qui mergent les merge request. Attention : être master n'est pas une raison suffisante pour pusher ses changements sur la branche `master` sans vergogne ! Ils doivent tout de même être reviewés par un autre Master, voir la section Merge requests. |
|
|
\ No newline at end of file |
|
|
|
------
|
|
|
|
|
|
|
|
Les membres possédant le titre de Master sont des gens qui connaissent bien au
|
|
|
|
moins une partie du code. Ils ont quelques droits supplémentaires par rapport
|
|
|
|
aux Developers ; en particulier ils peuvent modifier la branche principale
|
|
|
|
(`master`). Ce sont eux qui mergent les merge request. Attention : être master
|
|
|
|
n'est pas une raison suffisante pour pusher ses changements sur la branche
|
|
|
|
`master` sans vergogne ! Ils doivent tout de même être reviewés par un autre
|
|
|
|
Master, voir la section Merge requests. |
