|
|
Architecture du dépôt
|
|
Architecture du dépôt
|
|
|
==================
|
|
=====================
|
|
|
|
|
|
|
|
Actuellement, il y a trois branches protégées :
|
|
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.
|
|
- `Production` qui est la version en ligne sur www.cof.ens.fr, seuls les
|
|
|
- `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
|
|
webmasters touchent à ça.
|
|
|
cette branche.
|
|
- `master`, la version la plus récente du projet. De temps en temps, on merge
|
|
|
- `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
|
|
`master` sur `Production`. En théorie, dev.cof.ens.fr suit cette branche.
|
|
|
après le reste par @delobell qui est le seul à connaître bien la codebase pour l'instant.
|
|
|
|
|
|
|
|
|
|
Pour affecter ces branches, il faut passer par une merge request (cf plus bas). Toute autre branche est gérée librement par les
|
|
Pour affecter ces branches, il faut passer par une merge request (cf plus bas).
|
|
|
personnes qui travaillent dessus.
|
|
Toute autre branche est gérée librement par les personnes qui travaillent
|
|
|
|
dessus.
|
|
|
|
|
|
|
|
Merge requests
|
|
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.
|
|
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
|
|
|
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,
|
|
participé à l'écriture du code. En pratique pour faire une merge request, après
|
|
|
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
|
|
avoir cloné le dépot, il faut faire une branche séparée avec
|
|
|
dépend des situations.
|
|
`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
|
|
|
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.
|
|
faites vos modifications, puis poussez sur le GitLab. Là vous pouvez aller sur
|
|
|
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.
|
|
l'interface Web et cliquer sur le bouton "faire une merge request" qui apparaît.
|
|
|
De plus, c'est une bonne façon de se familiariser avec le code (et pourquoi pas devenir master un jour ;D).
|
|
|
|
|
|
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
|
|
### 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.
|
|
- [Pylint](https://www.pylint.org/) fait un tas de vérifications et permet
|
|
|
- [Flake8](https://pypi.python.org/pypi/flake8) vérifie que les conventions de la [PEP8](https://www.python.org/dev/peps/pep-0008/)
|
|
notamment d'éviter un certain nombre d'erreurs.
|
|
|
(et quelques autres) sont bien respectées. Ce n'est pas une nécessité mais ça peut être une bonne habitude à prendre.
|
|
- [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
|
|
Membres
|
|
|
========
|
|
=======
|
|
|
|
|
|
|
|
Il y a trois types de contributeurs à cof-geek.
|
|
Il y a trois types de contributeurs à cof-geek.
|
|
|
|
|
|
|
|
Extérieurs
|
|
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
|
|
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
|
|
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. |
|
Les membres possédant le titre de Master sont des gens qui connaissent bien au
|
|
\ No newline at end of file |
|
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. |
