mise en forme

This commit is contained in:
Emmanuel Viennet 2021-12-30 10:15:20 +01:00
parent 78a51f8697
commit ccb90ef8b9

View File

@ -97,62 +97,79 @@ jour de `master` (remote):
#### Refactoring
Lint tous les fichiers modifiés:
```
git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E
```
Restore les modes au besoin (SAMBA les changent parfois):
```
git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply
```
Affiche les variables non définies dans un fichier:
```
pylint --disable=all -e E sco_parcours_dut.py | grep undefined-variable | awk '{print $4;}' | sort | uniq | tr -d \'
```
Prépare un sed pour renommer les variables non définies:
```
for f in *.py
do
pylint --disable=all -e E "$f" | grep undefined-variable | awk '{print "sed -i .bak s/"$4"/scu."$4"/ '$f'";}' | sort | uniq | tr -d \'
done
```
Note pour travailler sur VirtualBox:
addgroup scodoc vboxsf
#### Préparation d'un PR
### Préparation d'une PR (Pull Request)
##### Principes généraux
#### Principes généraux
L'essentiel des remarques/procédures de cette section vise à obtenir une relecture facile des modifications:
Les remarques de cette section visent à obtenir une relecture facile de votre
demande d'ajout (*pull request*, dite "PR"):
* Éviter les modifications de forme sans substance sémantique. L'utilisation de [`black`](https://black.readthedocs.io/) permet de normaliser la présentation du code.
* Éviter les modifications de forme qui ne changent pas le sens du code. L'utilisation de
[`black`](https://black.readthedocs.io/) est obligatoire: elle de normaliser la présentation
du code. cela évite d'e générer des différences ne représentant que des
changement de mise en forme (indentation, passages à la ligne). Cela évite
aussi au développeur d'avoir à y réfléchir, autant de temps gagné !
* Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour les PR courantes (peu volumineuses)
* Avoir un nombre d'étapes de validation faible (idéalement un seul commit pour
les PR courantes (peu volumineuses).
* La PR doit toujours être énoncé par rapport au dernier commit de la branche master officielle
* La PR doit toujours être énoncée par rapport au dernier commit de la branche
que vous visez (en général `master` du dépôt original).
##### Manipulations
#### Manipulations
Les manipulations sont décrites selon 4 phases du développement: l'installation, la mise en place, le suivi, la livraison.
Les manipulations sont décrites selon 4 phases du développement: l'installation,
la mise en place, le suivi, la livraison.
###### l'installation
Il est pratique d'avoir en ligne les deux dépôt git distant que vous pouvez utiliser: votre dépôt personnel (`https://scodoc.org/git/<user>/<dépôt>.git`)
et le dépôt officiel (`https://scodoc.org/git/ScoDoc/ScoDoc.git`)
##### l'installation
Il est pratique d'avoir en ligne les deux dépôt git distant que vous pouvez
utiliser: votre dépôt personnel (`https://scodoc.org/git/<user>/<dépôt>.git`) et
le dépôt officiel (`https://scodoc.org/git/ScoDoc/ScoDoc.git`).
pour ajouter une référence (et lui donner un nom) vers un dépôt distant, envoyez la commande:
pour ajouter une référence (et lui donner un nom) vers un dépôt distant, entrez
la commande:
```git remote add nom_remote https://scodoc.org/git/ScoDoc/<dépôt>.git```
```
git remote add nom_remote https://scodoc.org/git/ScoDoc/<dépôt>.git
```
Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`) et une référence vers le dépôt officiel (`officiel`). L'un des deux
si vous avez initialement cloné l'un des deux dépôts, la référence vers celui-ci existe et a pour nom `origin`.
Par la suite vous aurez donc une référence vers votre dépôt personnel (`perso`)
et une référence vers le dépôt officiel (`officiel`). Si vous avez initialement
cloné l'un des deux dépôts, la référence vers celui-ci existe et a pour nom
`origin`.
La commande vous exposant tous les dépôts connus est :
```
git remote -v
```
`git remote -v`
#### Mise en place
##### Mise en place
L'objectif de ce paragraphe est de créer une branche locale basée sur le master du dépôt officiel et bien sur de lui donner un nom.
L'objectif de ce paragraphe est de créer une branche locale basée sur le master
du dépôt officiel et bien sur de lui donner un nom.
pour cela (attention cela va écraser les éventuels fichiers modifiés)
@ -162,15 +179,20 @@ git checkout -b ma_modif
```
À partir de la vous pouvez modifier, tester, développer, commit.
##### Suivi
#### Suivi
Si votre développement prend plusieurs jours, il est probable que la branche principale évolue pendant ce temps.
Si votre développement prend plusieurs jours, il est probable que la branche
principale évolue pendant ce temps.
Pour garder la cohérence, il est nécessaire de réintégrer en local les modifications de la branche principale. Ceci peut se faire de deux façons.
Pour garder la cohérence, il est nécessaire de réintégrer en local les
modifications de la branche principale. Ceci peut se faire de deux façons.
- Une fusion (`merge`) applique toutes les modifications en une seul commit). C'est la méthode couramment utilisée
- Une fusion (`merge`) applique toutes les modifications en une seul commit).
C'est la méthode couramment utilisée.
- Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état le plus à jour de la branche principal (il en résulte un historique plus linéaire)
- Un `rebase` rejoue tous les commits de la nouvelle branche par dessus l'état
le plus à jour de la branche principal (il en résulte un historique plus
linéaire).
Les commandes git correspondantes:
@ -184,20 +206,23 @@ git fetch officiel
git rebase officiel/merge
```
##### La livraison
#### La livraison
Ça y est. vous avez terminé le développement. IL n'y a plus qu'à demander l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur la branche locale `ma_modif`).
Ça y est. vous avez terminé le développement. IL n'y a plus qu'à demander
l'intégration. Ceci se fait en plusieurs étapes (vous êtes bien sûr toujours sur
la branche locale `ma_modif`).
###### Étape 1 : faire l'inventaire des fichiers impliqués
##### Étape 1 : faire l'inventaire des fichiers impliqués
```
git fetch officiel/master
git diff --name-only officiel/master
```
###### Étape 2 : passer black sur les fichiers modifiés
##### Étape 2 : passer black sur les fichiers modifiés
Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé l'équivalent sous *pyCharm*)
Cette étape est automatique avec les bons réglages sous VSCode (pas trouvé
l'équivalent sous *pyCharm*).
À défaut les lignes suivantes réalisent le même travail:
@ -207,20 +232,22 @@ do
python3 -m black $fn
done
```
faire une première lecture rapide pour vérifier qu'il n'y ait pas de fichiers modifiés accidentellement.
faire une première lecture rapide pour vérifier qu'il n'y ait pas de fichiers
modifiés accidentellement.
pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple)
Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple)
```
git diff officiel/master app/fichier.py
```
Utilisateurs Windows:
Vérifiez bien que les réglages de fin de ligne suivant bien les règles Linux (pas de CR ou `\r` en fin de ligne juste les LF `\n`).
Le cas échéant réglez votre IDE pour cela
Utilisateurs Windows: Vérifiez bien que les réglages de fin de ligne suivant
bien les règles Linux (pas de CR ou `\r` en fin de ligne juste les LF `\n`). Le
cas échéant réglez votre IDE pour cela.
À ce niveau là vous n'avez dans votre branche locales que les différences nécessaires à votre correctif.
À ce niveau là vous n'avez dans votre branche locales que les différences
nécessaires à votre correctif.
###### Étape 3: résumez tous les commits depuis le point de divergence en un seul commit
##### Étape 3: résumez tous les commits depuis le point de divergence en un seul commit
Repérez le point de divergence de votre branche locale avec officiel/master
(normalement `git merge-base ma_branche officiel/master`)
@ -231,7 +258,9 @@ Demander un `rebase` interactif depuis ce point:
git rebase -i $(git merge-base HEAD officiel/master)
```
Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le début du développement sous cette forme (c'est un exemple le nombre de lignes peut varier)
Vous devez obtenir dans un éditeur de texte la liste des commits opéré depuis le
début du développement sous cette forme (c'est un exemple le nombre de lignes
peut varier):
```
pick eb8cbec modif 1
@ -267,9 +296,11 @@ pick 83eb79e modif 2
~
```
vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en changeant la commande pick au début de chaque ligne
l idée ici est de fusionner toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne 2 par `fixup`.
optionnellement, vous pouvez reformuler le message de commit (commande `reword` sur la première ligne).
Vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en
changeant la commande pick au début de chaque ligne. L'idée ici est de fusionner
toutes les lignes avec la première en remplaçant le 'pick' à partir de la ligne
2 par `fixup`. Optionnellement, vous pouvez reformuler le message de commit
(commande `reword` sur la première ligne).
Vous construirez par exemple:
```
@ -278,33 +309,39 @@ fixup 83eb79e modif 2
...
```
Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées
Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées.
À ce niveau là de la procédure:
* vous avez un seul commit pour l'ensemble du correctif proposé
* vous avez un seul commit pour l'ensemble du correctif proposé;
* toutes les différences entre officiel/master et votre branche locale sont signifiantes
* toutes les différences entre officiel/master et votre branche locale sont
signifiantes.
###### Étape 4:
Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel (vers une branche de même nom):
##### Étape 4:
Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel
(vers une branche de même nom):
```
git push --set-upstream perso ma_branche
```
Si vous avez déjà fait cette opération auparavant il est possible que le push soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
Dans ce cas l'option `--force` du push vous permette de passer outre, mais assurez-vous avant d'être le seul à travailler sur cette branche.
Si vous avez déjà fait cette opération auparavant il est possible que le push
soit refusé (car le rebase a modifié des commits qui avaient déjà été poussés).
Dans ce cas l'option `--force` du push vous permette de passer outre, mais
assurez-vous avant d'être le seul à travailler sur cette branche.
###### Etape 5: La dernière étape se passe sur le site scodoc.org/git
##### Etape 5: La dernière étape se passe sur le site scodoc.org/git
* Identifiez-vous
* Placez-vous sur la branche nouvellement créée
* À l'aide de l'interface du serveur vous pouvez comparer l'état de votre branche par rapport au master officiel, et si cela vous convient de formuler une demande d'intégration (pull request)
* À l'aide de l'interface du serveur vous pouvez comparer l'état de votre
branche par rapport au master officiel, et si cela vous convient de formuler
une demande d'intégration (pull request).
### Tests
### Tests et tests unitaires
Voir [TestsScoDoc](TestsScoDoc.md)