From ccb90ef8b939fd5076524425b3ea400a692814ae Mon Sep 17 00:00:00 2001 From: viennet Date: Thu, 30 Dec 2021 10:15:20 +0100 Subject: [PATCH 1/4] mise en forme --- docs/GuideDeveloppeurs.md | 151 ++++++++++++++++++++++++-------------- 1 file changed, 94 insertions(+), 57 deletions(-) diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md index 19e0b4fa..bb6eae89 100644 --- a/docs/GuideDeveloppeurs.md +++ b/docs/GuideDeveloppeurs.md @@ -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//.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//.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/.git``` +``` + git remote add nom_remote https://scodoc.org/git/ScoDoc/.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) From e7ae9a6a91844c6f8b056b81e6b0e69d54559daa Mon Sep 17 00:00:00 2001 From: viennet Date: Thu, 30 Dec 2021 10:55:32 +0100 Subject: [PATCH 2/4] blocs de code: mode bash --- docs/GuideDeveloppeurs.md | 79 ++++++++++++++++++++------------------- 1 file changed, 40 insertions(+), 39 deletions(-) diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md index bb6eae89..2ae3b9bd 100644 --- a/docs/GuideDeveloppeurs.md +++ b/docs/GuideDeveloppeurs.md @@ -86,8 +86,9 @@ basique: Vous travaillez dans votre branche `ma_branche`. Pour lui appliquer les mises à jour de `master` (remote): - +```bash git pull origin master +``` #### Commandes utiles, en vrac @@ -97,19 +98,19 @@ jour de `master` (remote): #### Refactoring Lint tous les fichiers modifiés: -``` +```bash git status | grep modified | grep .py | awk '{print $2}' | xargs pylint -E ``` Restore les modes au besoin (SAMBA les changent parfois): -``` +```bash 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: -``` +```bash 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: -``` +```bash 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 \' @@ -152,7 +153,7 @@ 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, entrez la commande: -``` +```bash git remote add nom_remote https://scodoc.org/git/ScoDoc/.git ``` @@ -162,7 +163,7 @@ 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 : -``` +```bash git remote -v ``` @@ -171,13 +172,13 @@ La commande vous exposant tous les dépôts connus est : 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) +pour cela (attention cela va écraser les éventuels fichiers modifiés) : +```bash + git reset --hard officiel/master + git checkout -b ma_modif ``` -git reset --hard officiel/master -git checkout -b ma_modif -``` -À partir de la vous pouvez modifier, tester, développer, commit. +À partir de là vous pouvez modifier, tester, développer, commit. #### Suivi @@ -194,16 +195,16 @@ modifications de la branche principale. Ceci peut se faire de deux façons. le plus à jour de la branche principal (il en résulte un historique plus linéaire). -Les commandes git correspondantes: +Les commandes git correspondantes : -``` -git fetch officiel -git merge officiel/master +```bash + git fetch officiel + git merge officiel/master ``` ou -``` -git fetch officiel -git rebase officiel/merge +```bash + git fetch officiel + git rebase officiel/merge ``` #### La livraison @@ -214,9 +215,9 @@ la branche locale `ma_modif`). ##### Étape 1 : faire l'inventaire des fichiers impliqués -``` -git fetch officiel/master -git diff --name-only officiel/master +```bash + git fetch officiel/master + git diff --name-only officiel/master ``` ##### Étape 2 : passer black sur les fichiers modifiés @@ -224,20 +225,20 @@ git diff --name-only officiel/master 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: +À défaut les lignes suivantes réalisent le même travail : -``` -for fn in $(git diff --name-only officiel/master) -do - python3 -m black $fn -done +```bash + for fn in $(git diff --name-only officiel/master) + 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. Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple) -``` -git diff officiel/master app/fichier.py +```bash + git diff officiel/master app/fichier.py ``` Utilisateurs Windows: Vérifiez bien que les réglages de fin de ligne suivant @@ -252,17 +253,17 @@ nécessaires à votre correctif. Repérez le point de divergence de votre branche locale avec officiel/master (normalement `git merge-base ma_branche officiel/master`) -Demander un `rebase` interactif depuis ce point: +Demander un `rebase` interactif depuis ce point : -``` -git rebase -i $(git merge-base HEAD officiel/master) +```bash + 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): +peut varier) : -``` +```bash pick eb8cbec modif 1 pick 83eb79e modif 2 @@ -303,7 +304,7 @@ toutes les lignes avec la première en remplaçant le 'pick' à partir de la lig (commande `reword` sur la première ligne). Vous construirez par exemple: -``` +```bash reword eb8cbec Correctif: Api - gestion des formation fixup 83eb79e modif 2 ... @@ -311,7 +312,7 @@ fixup 83eb79e modif 2 Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées. -À ce niveau là de la procédure: +À ce niveau là de la procédure : * vous avez un seul commit pour l'ensemble du correctif proposé; @@ -322,8 +323,8 @@ Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées. 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 +```bash + git push --set-upstream perso ma_branche ``` Si vous avez déjà fait cette opération auparavant il est possible que le push From 126c034c585a34929bfe578acd235a4b7bfde28f Mon Sep 17 00:00:00 2001 From: Jean-Marie PLACE Date: Thu, 30 Dec 2021 11:28:45 +0100 Subject: [PATCH 3/4] =?UTF-8?q?typos=20+=20compl=C3=A9ments?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/GuideDeveloppeurs.md | 87 +++++++++++++++++++++++++-------------- 1 file changed, 55 insertions(+), 32 deletions(-) diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md index 2ae3b9bd..7c146d37 100644 --- a/docs/GuideDeveloppeurs.md +++ b/docs/GuideDeveloppeurs.md @@ -129,25 +129,25 @@ Les remarques de cette section visent à obtenir une relecture facile de votre demande d'ajout (*pull request*, dite "PR"): * É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 + [`black`](https://black.readthedocs.io/) est obligatoire : elle permet de normaliser la présentation + du code. cela évite de générer des différences ne représentant que des + changements 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). + les PR courantes - peu volumineuses). * 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 -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 quatre phases du développement : l'installation, +la mise en place, le suivi et 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//.git`) et +Il est pratique d'avoir en ligne les deux dépôts git distants que vous pouvez +utiliser : votre dépôt personnel (`https://scodoc.org/git//.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, entrez @@ -159,7 +159,7 @@ la commande: 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 +cloné l'un des deux dépôts, la référence vers le dépot d'origine existe et a pour nom `origin`. La commande vous exposant tous les dépôts connus est : @@ -172,13 +172,14 @@ La commande vous exposant tous les dépôts connus est : 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) : +pour cela (**attention cela va écraser les éventuels fichiers modifiés**. Si vous souhaitez conserver les +modifications en cours, encadrez les lignes suivantes par `git stash` (avant) et `git stash apply` (après) : ```bash git reset --hard officiel/master git checkout -b ma_modif ``` -À partir de là vous pouvez modifier, tester, développer, commit. +À partir de là, vous pouvez modifier, tester, développer et commit votre travail. #### Suivi @@ -188,11 +189,11 @@ 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. - - Une fusion (`merge`) applique toutes les modifications en une seul commit). + - Une fusion (`merge`) applique toutes les modifications en un 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 + le plus à jour de la branche principale (il en résulte un historique plus linéaire). Les commandes git correspondantes : @@ -209,9 +210,9 @@ ou #### La livraison -Ça y est. vous avez terminé le développement. IL n'y a plus qu'à demander +Ç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`). +la branche locale `ma_modif` et toutes vos modifications ont été commitées). ##### Étape 1 : faire l'inventaire des fichiers impliqués @@ -233,7 +234,8 @@ l'équivalent sous *pyCharm*). python3 -m black $fn done ``` -faire une première lecture rapide pour vérifier qu'il n'y ait pas de fichiers + +Faire une première lecture rapide pour vérifier qu'il ne reste pas de fichiers modifiés accidentellement. Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par exemple) @@ -241,26 +243,47 @@ Pour obtenir la modification sur un fichier spécifique (`app/fichier.py` par ex 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 suivent +bien les règles Linux (pas de retour chariot (noté CR ou `\r`) en fin de ligne mais un seul caractère line feed +(noté LF ou `\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 +À ce niveau là de la procèdure, vous n'avez plus dans votre branche locale que les différences strictement 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`) +(normalement `git merge-base HEAD officiel/master`) Demander un `rebase` interactif depuis ce point : ```bash git rebase -i $(git merge-base HEAD officiel/master) -``` +*Explications*: +_Le rebase interactif permet d'enregistrer un suite de manipulation de commit dans un seul fichier texte._ +_Le fichier texte qui reprend tels quels tous les commits concernés (et donc qui ne fait rien)_ +_est préparé par la commande `-i` de la commande_ `git rebase` + +_Vous pouvez ensuite modifier ce fichier dans votre editeur favori (ou pas) (à régler par `git config`) pour décrire_ +_votre intention (réordonner, changer le message, fusionner, ...) sur l'ensemble des commits_ + +_Quand votre édition est terminée, git reprend la main est excécute chacune de vos opérations. Il est possible_ +_(bien que très rare) que des conflits apparaissent à ce moment-là. Les commandes habutelles de correction accompagnées des commandes:_ +```bash +git rebase --continue # pour poursuivre le processus +git rebase --abort # pour tout abandonner +``` +_vous permettront de résoudre ces problèmes excptionnels_ + +Application: + +```bash +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 +début du développement sous cette forme (c'est un exemple : le nombre de lignes peut varier) : ```bash @@ -303,7 +326,7 @@ toutes les lignes avec la première en remplaçant le 'pick' à partir de la lig 2 par `fixup`. Optionnellement, vous pouvez reformuler le message de commit (commande `reword` sur la première ligne). -Vous construirez par exemple: +Vous construirez par exemple : ```bash reword eb8cbec Correctif: Api - gestion des formation fixup 83eb79e modif 2 @@ -312,14 +335,14 @@ fixup 83eb79e modif 2 Quand vous sortez de l'éditeur, git effectue toutes les opérations demandées. -À ce niveau là de la procédure : +À 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. -##### Étape 4: +##### Étape 4 : Vous pouvez maintenant pousser votre branche locale sur votre dépôt personnel (vers une branche de même nom): @@ -332,15 +355,15 @@ soit refusé (car le rebase a modifié des commits qui avaient déjà été pous 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](https://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, il vous reste à formuler + une demande d'intégration (pull request). En remplissant les informations demandées. ### Tests et tests unitaires From 7e32332f4c435f157ea9426593e1d19f47157841 Mon Sep 17 00:00:00 2001 From: viennet Date: Thu, 30 Dec 2021 13:40:30 +0100 Subject: [PATCH 4/4] mise en forme --- docs/GuideDeveloppeurs.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/GuideDeveloppeurs.md b/docs/GuideDeveloppeurs.md index 7c146d37..6be84be9 100644 --- a/docs/GuideDeveloppeurs.md +++ b/docs/GuideDeveloppeurs.md @@ -260,6 +260,7 @@ Demander un `rebase` interactif depuis ce point : ```bash git rebase -i $(git merge-base HEAD officiel/master) +``` *Explications*: _Le rebase interactif permet d'enregistrer un suite de manipulation de commit dans un seul fichier texte._ @@ -269,13 +270,14 @@ _est préparé par la commande `-i` de la commande_ `git rebase` _Vous pouvez ensuite modifier ce fichier dans votre editeur favori (ou pas) (à régler par `git config`) pour décrire_ _votre intention (réordonner, changer le message, fusionner, ...) sur l'ensemble des commits_ -_Quand votre édition est terminée, git reprend la main est excécute chacune de vos opérations. Il est possible_ -_(bien que très rare) que des conflits apparaissent à ce moment-là. Les commandes habutelles de correction accompagnées des commandes:_ +_Quand votre édition est terminée, git reprend la main est exécute chacune de vos opérations. Il est possible_ +_(bien que très rare) que des conflits apparaissent à ce moment-là. Les_ +_commandes habituelles de correction accompagnées des commandes :_ ```bash git rebase --continue # pour poursuivre le processus git rebase --abort # pour tout abandonner ``` -_vous permettront de résoudre ces problèmes excptionnels_ +_vous permettront de résoudre ces problèmes exceptionnels_. Application: @@ -317,7 +319,6 @@ pick 83eb79e modif 2 # # However, if you remove everything, the rebase will be aborted. # -~ ``` Vous pouvez réorganiser tous les commits (changer l'ordre, fusionner) en @@ -363,9 +364,9 @@ assurez-vous avant d'être le seul à travailler sur cette branche. * À 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, il vous reste à formuler - une demande d'intégration (pull request). En remplissant les informations demandées. + une demande d'intégration (*pull request*). En remplissant les informations demandées. -### Tests et tests unitaires +## Tests et tests unitaires Voir [TestsScoDoc](TestsScoDoc.md)