diff --git a/source/git/advanced.md b/source/git/advanced.md
index f5083f71189d1bfaa9b79212a9162aa41d6a1b2b..cb46765af84e8cb0a5dbcc94c90131b6da03d85e 100644
--- a/source/git/advanced.md
+++ b/source/git/advanced.md
@@ -7,22 +7,22 @@ Cette partie de la documentation s'adresse principalement aux maintainers et res
Dans certains cas Gitkraken vous proposera de réaliser un force push.
Il faut savoir que cette action est lourde de conséquences et il faut bien être conscient de ce que vous faites en cliquant sur ce bouton.
-Au moment du force push vous considérez que votre dépot est correct et que c'est le dépot distant qui est dans l'erreur, vous écrasez donc l'historique du serveur distant avec le votre **au risque de perdre le commit qui vous a imposé de force push**. De plus vous allez reporter la gestion de conflit sur le développeur qui a push les commits que vous avez écrasé, ou le forcer à réaliser un `git reset --hard` voir pire.
+Au moment de réaliser un force push vous considérez que votre dépôt est correct et que c'est le dépôt distant qui est dans l'erreur, vous écrasez donc l'historique du serveur distant avec le votre **au risque de perdre le commit qui vous a imposé de force push**. De plus vous allez reporter la gestion de conflits sur le développeur qui a push les commits que vous avez écrasé, ou le forcer à réaliser un `git reset --hard` voir pire.
-Dans la majorité des cas le force push n'est pas la solution et posera souvent plus de problème qu'autre chose.
+Dans la majorité des cas le force push n'est pas la solution et posera souvent plus de problèmes qu'autre chose.
-Le plus souvent un simple pull avant de push (et une petite gestion de conflit) vous assurera de ne pas avoir à force push. Pour les binaires ou les projets FME c'est plus complexe, il faut essayer de reporter les modifications ou choisir un candidat viable à la résolution de conflit.
+Le plus souvent un simple pull avant de push (et une petite gestion de conflits) vous assurera de ne pas avoir à force push. Pour les binaires ou les projets FME c'est plus complexe, il faut essayer de reporter les modifications ou choisir un candidat viable à la résolution de conflit.
-**Si vous avez perdu de la donnée** suite à un force push, c'est récupérable si vous n'êtes pas seul sur le dépot, et qu'un autre utilisateur à chekout la branche et qu'il n'a pas pull vos modifications. Il pourra alors gérer le conflit et force push à son tour pour corriger le problème.
+**Si vous avez perdu de la donnée** suite à un force push, c'est récupérable si vous n'êtes pas seul sur le dépôt, et qu'un autre utilisateur à chekout la branche et qu'il n'a pas pull vos modifications. Il pourra alors gérer le conflit et force push à son tour pour corriger le problème.
```{Warning}
- Dans le doute, toujours appeler quelqu'un qui maitrise Git. On préfrera toujours rattraper une petite bétise, que la grosse bétise qui découlera des quinzes tentatives de résolution intermédiaires qui n'auront pas fonctionées avant de nous appeler. Git est un élément fondamentale dans la tenu de notre code, il est primordiale que les dépots restent toujours propres, fonctionnels et que l'on ne perde pas de code.
+ Dans le doute, toujours appeler quelqu'un qui maitrise Git. On préférera toujours rattraper une petite bêtise, que la grosse bêtise qui découlera des quinze tentatives de résolution intermédiaires qui n'auront pas fonctioné avant de nous appeler. Git est un élément fondamental dans la tenue de notre code, il est primordial que les dépôts restent toujours propres, fonctionnels et que l'on ne perde pas de code.
```
## Git Bisect
-Git intégre un outil de recherche d'erreur qui utilise la méthode de [recherche par bissection](https://fr.wikipedia.org/wiki/M%C3%A9thode_de_dichotomie).
-Une recherche par bissection, consiste à prendre un ensemble, le couper en deux et déterminer quelle ensemble contient ce qu'on cherche, puis on réitère l'opération sur le sous-ensemble en question jusqu'à trouver l'élément de l'ensemble d'origine que l'on cherche.
+Git intègre un outil de recherche d'erreur qui utilise la méthode de [recherche par bissection](https://fr.wikipedia.org/wiki/M%C3%A9thode_de_dichotomie).
+Une recherche par bissection, consiste à prendre un ensemble, le couper en deux et déterminer quel ensemble contient ce qu'on cherche, puis on réitère l'opération sur le sous-ensemble en question jusqu'à trouver l'élément de l'ensemble d'origine que l'on cherche.
Voici comment l'algorithme va agir :
@@ -30,15 +30,15 @@ Voici comment l'algorithme va agir :
La commande va faire glisser le commit référencé par le HEAD, entre le commit actuel et un commit identifié comme sain (le commit sain n'est pas obligatoire, git bisect peut aussi l'identifier lors des premiers déplacements).
-La bissection va glisser sur un commit situé légérement au delà de la médiane (environ à 50-60% de la distance entre le commit actuel et le commit cible) et va demander si le bug est présent ou non.
-Si le bug est présent alors l'algorithme ira chercher un commit plus ancien, sinon il prendre un commit plus récent. C'est à vous de dire à git si le bug est présent ou non via les commandes `git bisect good` et `git bisect bad`. La commande `git bisect skip` permet de changer de commit sans répondre à la question en cas de doute.
-Dés que deux commits successifs présenteront un cas sain et un cas d'erreur, alors le commit à l'origine du bug sera identifié.
+La bissection va glisser sur un commit situé légèrement au-delà de la médiane (environ à 50-60% de la distance entre le commit actuel et le commit cible) et va demander si le bug est présent ou non.
+Si le bug est présent alors l'algorithme ira chercher un commit plus ancien, sinon il prendra un commit plus récent. C'est à vous de dire à git si le bug est présent ou non via les commandes `git bisect good` et `git bisect bad`. La commande `git bisect skip` permet de changer de commit sans répondre à la question en cas de doute.
+Dès que deux commits successifs présenteront un cas sain et un cas d'erreur, alors le commit à l'origine du bug sera identifié.
-Exemple : Pour cette exemple j'ai répondu aléatoirement sur les commits situé entre mon head next_app_dtnet et son 50éme parent direct (ce qui représente 283 commits avec les merges)
+Exemple : Pour cet exemple j'ai répondu aléatoirement sur les commits situés entre mon HEAD next_app_dtnet et son 50éme parent direct (ce qui représente 283 commits avec les merges)
-Si la présence du bug est testable avec un script shell, il sera alors possible de passer directement le script à la commande git bisect qui pourra identifier le bug trés rapidement.
+Si la présence du bug est testable avec un script shell, il sera alors possible de passer directement le script à la commande git bisect qui pourra identifier le bug très rapidement.
Exemple : npm build ne fonctionne plus depuis le dernier tag
```shell
@@ -55,9 +55,9 @@ git bisect reset
## Git Rebase et interactive rebase
La commande rebase permet de réécrire l'historique. Rebase une branche sur une autre va en fait réécrire l'historique des deux branches pour les rendre fast-forward.
-C'est un usage trés rare de cette commande, vu que dans notre cas la majorité des fusions de branche passent par des merge requests et donc des merges classiques.
+C'est un usage très rare de cette commande, vu que dans notre cas la majorité des fusions de branches passent par des merge requests et donc des merges classiques.
-En revanche l'interactive rebase est un outil trés utile pour réorganiser ses commits avant de push.
+En revanche l'interactive rebase est un outil très utile pour réorganiser ses commits avant de push.
@@ -67,7 +67,7 @@ en faisant ça, j'arrive sur l'interface de rebase interactif :
-Plusieurs actions sont possible :
+Plusieurs actions sont possibles :
- **pick** : Laisse le commit dans l'état
- **reword** : Permet de modifier le commentaire
- **squash** : Permet de fusionner deux commits adjacents
@@ -75,17 +75,17 @@ Plusieurs actions sont possible :
- **move** : Permet de déplacer un commit
```{Tip}
- Certaines de ces actions sont réalisables via le menu contextuelle en faisant un clique droit sur un commit ou un ensemble de commit sans réaliser un git rebase complet.
+ Certaines de ces actions sont réalisables via le menu contextuel en faisant un clique droit sur un commit ou un ensemble de commits sans réaliser un git rebase complet.
```
-Dans ce cas là j'ai déplacé mon commit pour corriger la faute d'orthographe, j'améliore le message du second commit, et je fusionne mes deux derniers commit en changeant le message qui sera affiché sur le commentaire. Pour finaliser je dois cliquer sur le bouton `start rebase`, ce qui modifiera l'arborescence des commits.
+Dans ce cas-là j'ai déplacé mon commit pour corriger la faute d'orthographe, j'améliore le message du second commit, et je fusionne mes deux derniers commits en changeant le message qui sera affiché sur le commentaire. Pour finaliser je dois cliquer sur le bouton `start rebase`, ce qui modifiera l'arborescence des commits.
```{Warning}
- Réaliser un intéractive rebase sur des commits déjà poussé sur le dépot distant provoquera systématiquement l'appartition d'un force push, ce qui risque de corrompre l'historique global du dépot. Si vous travailler seul sur la branche rebase et que vous maitrisez bien ce que vous faite c'est sans risque.
+ Réaliser un intéractive rebase sur des commits déjà poussés sur le dépôt distant provoquera systématiquement l'apparition d'un force push, ce qui risque de corrompre l'historique global du dépôt. Si vous travaillez seul sur la branche rebase et que vous maitrisez bien ce que vous faites c'est sans risque.
```
## Git Blame, Git History
@@ -98,23 +98,21 @@ Le git blame sur un fichier permet de voir quel est le dernier commit à avoir a
Pour ouvrir l'historique, il suffit de réaliser un clique droit sur le fichier que l'on souhaite analyser et de choisir `File History` ou `File Blame`, qui ouvrira le même composant.
```{Tip}
- Si vous ne voulez pas chercher votre fichier dans la liste des commits pour gagner du temps. Il vous suffit de cocher la checkbox au dessus de l'arborescence, `View all files` pour trouver facilement votre fichier, L'historique partira du premier commit impactant ce fichier, antérieur au commit sélectionné.
+ Si vous ne voulez pas chercher votre fichier dans la liste des commits pour gagner du temps. Il vous suffit de cocher la checkbox au-dessus de l'arborescence, `View all files` pour trouver facilement votre fichier, L'historique partira du premier commit impactant ce fichier, antérieur au commit sélectionné.
```
Sur la partie de gauche, on retrouve donc l'historique des commits sur le fichier, et sur la partie de droite le blame.
-en cliquant dans l'historique on peut voir d'autre version du fichier si necessaire (le blame évoluera en même temps).
+en cliquant dans l'historique on peut voir d'autres versions du fichier si nécessaire (le blame évoluera en même temps).
## Branche courante dans l'invite de commande
-
-
Sous Linux, il faut ajouter le script `~/.git-prompt.sh` disponible sur [Github](https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh)
-il faut éditer votre fichier `~/.bashrc` et modifier la variable PS1
+Il faut éditer votre fichier `~/.bashrc` et modifier la variable PS1
```shell
# Permet de charger les variable nécessaire pour la PS1
@@ -138,7 +136,7 @@ fi
unset color_prompt force_color_prompt
```
-Lorque vous serez dans le dossier d'un dépot Git, la branche et l'état du dépot apparaitra alors au niveau de la CLI :
+Lorque vous serez dans le dossier d'un dépôt Git, la branche et l'état du dépôt apparaitra alors au niveau de la CLI :
@@ -149,31 +147,29 @@ La gestion de l'état se fait via une liste de symbole :
- < : En retard sur la branche distante upstream
- \> : En avance sur la branche distante upstream
- = : La branche distante upstream est au même niveau
-- $ : Présence d'un stash dans le dépot
+- $ : Présence d'un stash dans le dépôt
-Pour windows, Git Bash le fera de lui même, mais si besoin il est possible de configurer le Powershell pour obtenir le même rendu. Une documentation décrit la procédure sur [Git Scm](https://git-scm.com/book/uz/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Powershell)
+Pour Windows, Git Bash le fera de lui-même, mais si besoin il est possible de configurer le Powershell pour obtenir le même rendu. Une documentation décrit la procédure sur [Git Scm](https://git-scm.com/book/uz/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Powershell)
## Fork
-WIP
-
La documentation relative au fork sur Gitlab est disponible via [ce lien](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#project-forking-workflow)
## CI/CD
-Gitlab permet de déclencher des scripts suite à des push, c'est trés interressant dans le cadre de développement en mode DevOps. On parle d'intégration continue (CI) et de déploiement continu (CD).
+Gitlab permet de déclencher des scripts suite à des push, c'est très intéressant dans le cadre de développement en mode DevOps. On parle d'intégration continue (CI) et de déploiement continu (CD).
La documentation spécifique à Gitlab sur la conception de pipeline CI/CD est disponible via [ce lien](https://docs.gitlab.com/ee/ci/).
Pour la documentation, attention toutes les fonctionnalités ne sont pas compatibles avec notre version et notre édition de Gitlab.
-Nous nous en servons, majoritairement pour vérifier qu'un certain niveau de qualité/propreté du code est maintenu en continu sur les dépots, ou pour publier la documentation automatiquement.
+Nous nous en servons, majoritairement pour vérifier qu'un certain niveau de qualité/propreté du code est maintenu en continu sur les dépôts, ou pour publier la documentation automatiquement.
-La fonctionnalité doit être activée sur le dépots via la configuration du projet sur Gitlab.
+La fonctionnalité doit être activée sur le dépôt via la configuration du projet sur Gitlab.
-Une fois la fonctionnalité active, il faut ajouter un fichier `.gitlab-ci.yml` à la racine du dépot.
+Une fois la fonctionnalité active, il faut ajouter un fichier `.gitlab-ci.yml` à la racine du dépôt.
```{Tip}
- Pour créer un CI/CD petit conseil, partez d'une branche master ou proche de master, puis une fois terminer mergez cette branche dans master et master dans les branches type next_version rapidement de façon à propager le CI/CD rapidement et s'éviter des conflit ou des comportement étrange du CI/CD sur GitLab.
+ Pour créer un CI/CD petit conseil, partez d'une branche master ou proche de master, puis une fois terminer mergez cette branche dans master et master dans les branches type next_version rapidement de façon à propager le CI/CD rapidement et s'éviter des conflits ou des comportements étranges du CI/CD sur GitLab.
```
exemple de CI/CD pour le fichier yml : Génération de la documentation de développement (uniquement si modifié sur next_version)
diff --git a/source/git/basics.md b/source/git/basics.md
index 004478e4b501a2de5821ee5392e40f0b5e2d20c9..72179a33a7114faf09bb6ab1b7bb61acd2be339e 100644
--- a/source/git/basics.md
+++ b/source/git/basics.md
@@ -13,10 +13,10 @@ Il faudra ensuite aller dans le menu `SSH`
-Les boutons **Browse** vous permettront de trouver une clé éxistante et de l'associer à GitKraken. \
-Le bouton **Generate** permettra de créer une nouvelle paire de clé SSH.
+Les boutons **Browse** vous permettront de trouver une clé existante et de l'associer à GitKraken. \
+Le bouton **Generate** permettra de créer une nouvelle paire de clés SSH.
-Le bouton à droite de la clé public vous permettra de copier le contenu de la clé publique pour l'étape suivante sur Gitlab.
+Le bouton à droite de la clé publique vous permettra de copier le contenu de la clé publique pour l'étape suivante sur Gitlab.
### Ajout de la clé SSH dans Gitlab
@@ -24,7 +24,7 @@ Une fois connecté à l'interface Web, accéder à **vos préférences** via le
-Dans l'interface des préférences, il y a un menu dédié au clés SSH :
+Dans l'interface des préférences, il y a un menu dédié aux clés SSH :
@@ -32,34 +32,34 @@ Dans le formulaire il faut copier la clé publique uniquement dans le champ pré
```{Tip}
Vous pouvez avoir plusieurs clés SSH, si vous le souhaitez. \
- Si vous utilisez des clés SSH que vous utilisez également en dehors de Veremes ou sur des EC2 de tests, soyez vigilant pour qu'elle ne fuite pas et si ça devait être le cas, pensez à la dissocier de gitlab.
+ Si vous utilisez des clés SSH que vous utilisez également en dehors de Veremes ou sur des EC2, soyez vigilant pour qu'elle ne fuite pas et si ça devait être le cas, pensez à la dissocier de gitlab.
```
-## Cloner un dépot
+## Cloner un dépôt
-Pour cloner un dépot, il faut commencer par récupérer l'url du dépot sur Gitlab.
+Pour cloner un dépôt, il faut commencer par récupérer l'URL du dépôt sur Gitlab.
-Comme on le voit sur le screenshot, il y a deux types d'url, une pour utilisation via SSH et une via HTTPS.
+Comme on le voit sur le screenshot, il y a deux types d'URL, une pour utilisation via SSH et une via HTTPS.
-L'url SSH nécessite d'avoir configuré une clé SSH, par contre sa facilite énormément les interaction avec le dépot distant.
-L'url HTTPS n'a pas de prérequis, par contre il faut saisir le login/password de Gitlab à chaque interaction avec le serveur distant.
+L'URL SSH nécessite d'avoir configuré une clé SSH, par contre cela facilite énormément les interactions avec le dépôt distant.
+L'URL HTTPS n'a pas de prérequis, par contre il faut saisir le login/password de Gitlab à chaque interaction avec le serveur distant.
-Une fois que vous avez cet Url vous pouvez soit lancer la commande `git clone [URL] [Dossier_dest]` par défaut le dossier de destination sera le nom du dépot.
+Une fois que vous avez cet URL vous pouvez soit lancer la commande `git clone [URL] [Dossier_dest]` par défaut le dossier de destination sera le nom du dépôt.
Ou avec GitKraken, `nouvel onglet > Clone a Repo`.
-Choisisser un dossier contenant votre dépot, coller l'url que vous souhaitez utiliser, vous pouvez changer le nom du dossier du dépot, puis cliquer sur clone. A ce moment là un bandeau apparaitra sur le haut de l'application pour savoir si vous souhaitez ouvrir le dépot aprés l'avoir cloné.
+Choisisser un dossier contenant votre dépôt, coller l'URL que vous souhaitez utiliser, vous pouvez changer le nom du dossier du dépôt, puis cliquer sur clone. À ce moment-là un bandeau apparaîtra sur le haut de l'application pour savoir si vous souhaitez ouvrir le dépôt après l'avoir cloné.
```{Tip}
- Je vous conseille de créer un dossier Git sur votre systéme de fichier et de tout stocker dedans.
+ Je vous conseille de créer un dossier Git sur votre système de fichiers et de tout stocker dedans.
- Vous pourrez dire à GitKraken de surveiller ce dossier, il pourra alors vous lister tous les dépot Git à l'intérieur de ce dossier, et vous permettre de les ouvrir rapidement : dans la modale pour ouvrir un dépot, il faut cliquer sur le bouton vert et choisir le dossier, dans la partie de droites vous aurez alors la liste de tous les dépots dans ce dossier.
+ Vous pourrez dire à GitKraken de surveiller ce dossier, il pourra alors vous lister tous les dépôts Git à l'intérieur de ce dossier, et vous permettre de les ouvrir rapidement : dans la modale pour ouvrir un dépôt, il faut cliquer sur le bouton vert et choisir le dossier, dans la partie de droites vous aurez alors la liste de tous les dépôts dans ce dossier.
@@ -68,40 +68,40 @@ Choisisser un dossier contenant votre dépot, coller l'url que vous souhaitez ut
## Workflow Git
Avant de rentrer dans le fonctionnement du workflow et l'usage qu'on en fait petit rappel :
-Une application Web Veremes a son propre dépot qui fait référence a des dépots Git de modules tous contenu dans le dossier src (à minima vitis et un autre module que ce soit gtf, vmap ou autre et potentiellement d'autre modules). Ce qui veut dire qu'une application Web Veremes c'est à minima trois dépots Git.
+Une application Web Veremes a son propre dépôt qui fait référence à des dépôts Git de modules tous contenus dans le dossier src (a minima vitis et un autre module que ce soit gtf, vmap ou autres et potentiellement d'autres modules). Ce qui veut dire qu'une application Web Veremes c'est a minima trois dépôts Git.
### Principe
Veremes utilise un gitflow assez classique en y incorporant des éléments du gitlabflow.
La documentation sur le flow d'origine est disponible à [ce lien](https://docs.gitlab.com/ee/topics/gitlab_flow.html).
-Par convention Veremes, utilise la branche **master** pour livré les releases de ses applications, on peut considérer que c'est équivalent à une branche de production et la branche **next_version** pour les développements de nouvelles fonctionnalités.
-Tous les projet sur Gitlab ont les labels **bug** et **évolutions**
+Par convention Veremes, utilise la branche **master** pour livrer les releases de ses applications, on peut considérer que c'est équivalent à une branche de production et la branche **next_version** pour les développements de nouvelles fonctionnalités.
+Tous les projets sur Gitlab ont les labels **bug** et **évolutions**
-Les versions qui sont représentés avec des tags au niveau du dépot git sont toujours sous cette forme Année.Release.Correctif (ex : 2023.01.01, premier correctif de la première release de l'année 2023).
+Les versions qui sont représentées avec des tags au niveau du dépôt git sont toujours sous cette forme Année.Release.Correctif (ex : 2023.01.01, premier correctif de la première release de l'année 2023).
-Avant de sortir une version c'est à dire de réaliser les tags, il est préférable de créer une branche de pré-release (pre-20XX.XX.XX) pour tester la génération du setup, et la version elle-même.
+Avant de sortir une version c'est-à-dire de réaliser les tags, il est préférable de créer une branche de pré-release (pre-20XX.XX.XX) pour tester la génération du setup, et la version elle-même.
### Contexte d'application
-La branche **master** doit toujours être stable et préte à produire un correctif.
-En cas de remonté de bug on crée une **issue** sur gitlab en lui ajoutant le label **bug**, le maintainer/responsable du projet, viendra assigner cette issue à un milestone en fonction de l'urgence de la demande, voir il y assignera un développeur.
+La branche **master** doit toujours être stable et prête à produire un correctif.
+En cas de remontée de bug on crée une **issue** sur gitlab en lui ajoutant le label **bug**, le maintainer/responsable du projet, viendra assigner cette issue à un milestone en fonction de l'urgence de la demande, voir il y assignera un développeur.
-Le développeur devra alors reporté l'issue sur le ou les bon(s) dépot(s), créer une branche et une merge request correspondantes sur chaque dépots concernés. Un bouton permet de le faire depuis l'issue, il faut laisser le nom par défaut et adapter la source, pour un bug ce sera master, pour un developpement next_version.
+Le développeur devra alors reporter l'issue sur le ou les bon(s) dépôt(s), créer une branche et une merge request correspondantes sur chaque dépôt concerné. Un bouton permet de le faire depuis l'issue, il faut laisser le nom par défaut et adapter la source, pour un bug ce sera master, pour un développement sur next_version.
-Le développeur va ensuite récupérer la branche sur son poste, corriger le problème et envoyer les modifications vers le serveur. Il devra alors passer la merge request en prète (en retirant le **Draft** au début) et l'assigner à un maintainer du dépot.
+Le développeur va ensuite récupérer la branche sur son poste, corriger le problème et envoyer les modifications vers le serveur. Il devra alors passer la merge request en prête (en retirant le **Draft** au début) et l'assigner à un maintainer du dépôt.
-Le maintainer vérifiera alors que le correctif est fonctionnel et jugera de la qualité du code. En fonction de quoi, il renverrra des informations au développeur pour réaliser des modifications ou validera le code. En validant la merge request le maintainer réalisera le merge de la branche du correctif vers master et supprimera la branche du correctif (donc uniquement la référence vers le commit HEAD de cette branche, pas les commit en eux-même).
+Le maintainer vérifiera alors que le correctif est fonctionnel et jugera de la qualité du code. En fonction de quoi, il renverra des informations au développeur pour réaliser des modifications ou validera le code. En validant la merge request le maintainer réalisera le merge de la branche du correctif vers master et supprimera la branche du correctif (donc uniquement la référence vers le commit HEAD de cette branche, pas les commit en eux-mêmes).
Il est également préférable de merger **master** dans **next_version** de façon à impacter le correctif sur la branche de développement également et s'éviter des risques de conflits ultérieurs.
En cas de développement de nouvelles fonctionnalités, c'est exactement la même chose, sauf que le label sur l'issue sera **évolutions** et que la branche source à utiliser au moment de la création de la merge request sera **next_version** (sauf exception cf. vitis pour vmap, ...).
-Une fois le milestone terminé, que ce soit pour un correctif ou des évolutions, le maintainerdevra suivre le processus de sortie de version classique (détaillé ailleurs dans cette documentation).
+Une fois le milestone terminé, que ce soit pour un correctif ou des évolutions, le maintainer devra suivre le processus de sortie de version classique (détaillé ailleurs dans cette documentation).
## Gestion de conflit
@@ -115,17 +115,17 @@ Gitkraken vous permet de le gérer assez facilement :
-Vous pourrez voir via ce composant, quelles fichiers sont en conflit et lesquels ne le sont pas. En cliquant sur un fichier en conflit, vous arriverez sur une interface vous permettant de gérer le conflit sur ce fichier.
+Vous pourrez voir via ce composant, quels fichiers sont en conflit et lesquels ne le sont pas. En cliquant sur un fichier en conflit, vous arriverez sur une interface vous permettant de gérer le conflit sur ce fichier.
-L'interface vous présente alors les deux versions du fichiers, vous pouvez choisir le code à conserver, que ce soit le fichier entièrement, le bloc de code ou à la ligne. Vous pouvez conserver les deux versions des modifications simultanément (l'ordre de sélection sera l'ordre finale dans le fichier).
-Si le merge nécessite de modifier le fichier, vous pouvez soit le faire dans un éditeur externe, soit le gérer dans la troisième version du fichier (sur la partie basse du composant gitKraken), en éditant le texte directement. Une fois le conflit gérer sur le fichier il vous suffit de cliquer sur le bouton `save` pour résoudre le conflit sur ce fichier.
+L'interface vous présente alors les deux versions du fichier, vous pouvez choisir le code à conserver, que ce soit le fichier entièrement, le bloc de code ou à la ligne. Vous pouvez conserver les deux versions des modifications simultanément (l'ordre de sélection sera l'ordre final dans le fichier).
+Si le merge nécessite de modifier le fichier, vous pouvez soit le faire dans un éditeur externe, soit le gérer dans la troisième version du fichier (sur la partie basse du composant gitKraken), en éditant le texte directement. Une fois le conflit géré sur le fichier il vous suffit de cliquer sur le bouton `save` pour résoudre le conflit sur ce fichier.
Une fois tous les fichiers gérés, vous pourrez finaliser votre commit de merge. Si vous n'êtes pas en capacité de merger, vous pouvez annuler le merge en cliquant sur `abort`. Il vous suffit alors de demander à l'autre développeur en cause dans le conflit, ou a quelqu'un avec plus d'expertise que vous sur le sujet de vous aider à résoudre le conflit.
```{Warning}
- Un conflit se manifeste dans le fichier par l'apparition de balise, en cas de mauvaise gestion du conflit (plus exactement en cas d'absence de gestion), les balises resteront et léveront des erreurs de syntaxe.
+ Un conflit se manifeste dans le fichier par l'apparition de balise, en cas de mauvaise gestion du conflit (plus exactement en cas d'absence de gestion), les balises resteront et lèveront des erreurs de syntaxe.
```
@@ -135,14 +135,14 @@ Une fois tous les fichiers gérés, vous pourrez finaliser votre commit de merge
Le fichier .gitignore permet de spécifier à git qu'il ne doit pas surveiller (track) certains fichiers, ça peut être un fichier en particulier, une extension de fichier, un dossier, ...
-le .gitignore peut être placé à plusieurs niveau dans l'arborescence, même s'il est conseillé de n'en avoir qu'un à la racine du dépot.
+le .gitignore peut être placé à plusieurs niveaux dans l'arborescence, même s'il est conseillé de n'en avoir qu'un à la racine du dépôt.
-L'écriture de ce fichier n'est pas trés compliqué et GitKraken vous permet de le gérer facilement en faisant un clique droit dans votre zone de travail.
+L'écriture de ce fichier n'est pas très compliquée et GitKraken vous permet de le gérer facilement en faisant un clique droit dans votre zone de travail.
```{Warning}
- Si vous ajoutez un fichier dans le .gitignore et que ce fichier est déjà présent sur le dépot Git distant et que d'autres utilisateurs l'ont déjà récupéré. Pour que le fichier ne soit plus surveiller il faudra l'ajouter au .gitignore et commit l'effacement du fichier, en faisant ça le fichier sera effacé chez tous les développeurs au moment du pull. c'est pourquoi, il est fortement déconseillé d'ignorer un fichier qui est déjà sur le serveur distant, d'autant plus si sa présence reste nécessaire au fonctionnement de l'application.
+ Si vous ajoutez un fichier dans le .gitignore et que ce fichier est déjà présent sur le dépôt Git distant et que d'autres utilisateurs l'ont déjà récupéré. Pour que le fichier ne soit plus surveillé il faudra l'ajouter au .gitignore et commit l'effacement du fichier, en faisant ça le fichier sera effacé chez tous les développeurs au moment du pull. c'est pourquoi, il est fortement déconseillé d'ignorer un fichier qui est déjà sur le serveur distant, d'autant plus si sa présence reste nécessaire au fonctionnement de l'application.
```
## Commit un dossier vide
@@ -164,47 +164,46 @@ En faisant ça sur deux commits, il set possible de voir les différences entre
-Par exemple au moment de sortir une version, vous pouvez comparer master ou votre branche de pre-release avec le tag précédent pour voir si vous devez regénérer un engine ou non. \
-Autre exemple au moment d'assigner votre merge request à un maintainer, vous pouvez comparer le HEAD de votre branche avec le HEAD de la branche d'origine, pour vérifier que vous n'envoyez que du code utile et qu'il ne reste pas de traces de tests.
+Par exemple au moment de sortir une version, vous pouvez comparer master ou votre branche de pré-release avec le tag précédent pour voir si vous devez générer un engine ou non. \
+Autre exemple au moment d'assigner votre merge request à un maintainer, vous pouvez comparer le HEAD de votre branche avec le HEAD de la branche d'origine, pour vérifier que vous n'envoyez que du code utile et qu'il ne reste pas de trace de tests.
## Processus de sortie de version d'application
-Il faut sortir une version d'une application suite à la finalisation d'un milestone, ou d'une commande et aprés avoir déjà réalisé des tests sur l'application.
+Il faut sortir une version d'une application suite à la finalisation d'un milestone, ou d'une commande et après avoir déjà réalisé des tests sur l'application.
-En ce qui concerne la protection des dépots, seul master et next_version ont un traitement particulier et uniquement en ce qui concerne le push. \
-Pour toutes les autres fonctionnalités de Git, tout le monde peut tout faire. Il est biensur évident que la sortie d'une version se fait en accord avec le responsable du produit ou de la commande, mais vous êtes en capacité de réaliser toutes les étapes ci-dessous, ou de créer des merge-request pour qu'un maintainer puisse vous aider.
+En ce qui concerne la protection des dépôts, seul master et next_version ont un traitement particulier et uniquement en ce qui concerne le push. \
+Pour toutes les autres fonctionnalités de Git, tout le monde peut tout faire. Il est bien sûr évident que la sortie d'une version se fait en accord avec le responsable du produit ou de la commande, mais vous êtes en capacité de réaliser toutes les étapes ci-dessous, ou de créer des merge-request pour qu'un maintainer puisse vous aider.
-1. Création d'une branche de pre-release dont le nom suivra la règle habituelle `pre-20XX.XX.XX`, cette branche pourra venir de next_version si on sort une nouvelle_version ou master s'il s'agit d'un correctif urgent. Dans le cas où il s'agit d'une release d'évolution, il est important de merge également master dedans de façon à récupérer les correctifs qui aurait pu être fait et non ramené dans next_version entre temps. Etape à réaliser sur l'application mais aussi sur les modules.
-1. Modifier le `install_/dependencies.json` de l'application de façon à obtenir les bonnes dépendances (sur vos branche de pre-release ou des tags)
-1. Si des modifications ont eu lieu sur les engines d'un des modules, regénérer l'engine avec jenkins et retoucher le `dependencies.json` du module pour modifier la ressources à utiliser.
-1. Générer un setup avec Jenkins, tester, ... éventuellement faite des correctifs sur la branche de pre-release.
-1. Lorsque tout est bon, on peut alors ramener la branche de pre-release dans master et créer le tag de la version finale. Pour l'application le tag peut être fait directement sur la branche de pre-release, en fonction de la quantité de modifications sur cette dernière (si vous avez changer que les versions dans le fichier json, c'est cohérent de tag directement sur la branche de pre-release).
-1. Regénérer le setup finalen mettant à jour le dépendencies avec les tags et le publier si necessaire.
-1. Merge master dans next_version pour intégrer d'éventuels correctifs dans les futurs évolutions. Eventuellement suite à quoi il faudra remmettre en état les dependencies.json des applications sur master/next_version pour garder une cohérence.
+1. Création d'une branche de pre-release dont le nom suivra la règle habituelle `pre-20XX.XX.XX`, cette branche pourra venir de next_version si on sort une nouvelle_version ou master s'il s'agit d'un correctif urgent. Dans le cas où il s'agit d'une release d'évolution, il est important de merge également master dedans de façon à récupérer les correctifs qui auraient pu être fait et non ramené dans next_version entre-temps. Étape à réaliser sur l'application mais aussi sur les modules.
+1. Modifier le `install_/dependencies.json` de l'application de façon à obtenir les bonnes dépendances (sur vos branches de pré-release ou des tags)
+1. Si des modifications ont eu lieu sur les engines d'un des modules, générer l'engine avec Jenkins et retoucher le `dependencies.json` du module pour modifier la ressource à utiliser.
+1. Générer un setup avec Jenkins, tester, ... éventuellement faite des correctifs sur la branche de pré-release.
+1. Lorsque tout est bon, on peut alors ramener la branche de pre-release dans master et créer le tag de la version finale. Pour l'application le tag peut être fait directement sur la branche de pre-release, en fonction de la quantité de modifications sur cette dernière (si vous avez changé que les versions dans le fichier json, c'est cohérent de tag directement sur la branche de pré-release).
+1. Générer le setup finale en mettant à jour le dépendencies avec les tags et le publier si necessaire.
+1. Merge master dans next_version pour intégrer d'éventuels correctifs dans les futures évolutions. Éventuellement suite à quoi il faudra remettre en état les dependencies.json des applications sur master/next_version pour garder une cohérence.
```{Note}
- Le process vu ici est le processus dans le meilleurs des cas, il peut y avoir des variations. \
- Ne l'apprenez pas par coeur, comprenez le ce sera plus efficace. \
+ Le processus vu ici est le processus dans le meilleur des cas, il peut y avoir des variations. \
L'important c'est d'assimiler les grands principes et la logique du Gitflow qui est derrière.
```
## Processus de documentation
-La documentation est générée automatiquement via un **CI/CD gitlab** en utilisant **Sphinx**.
+La documentation est générée automatiquement via un **CI/CD GitLab** en utilisant **Sphinx**.
On considère que la documentation sur la branche **master** est la documentation à mettre à disposition pour les clients, qui part sur le bucket **documentation.veremes.net**. \
-La documentation sur **next_version** part sur un bucket de tests/pré-production afin de tester la compilation avec Sphinx, à savoir **documentation-dev.veremes.net** (ce bucket n'est accessible que depuis l'IP de Veremes).
+La documentation sur **next_version** part sur un bucket de tests/préproduction afin de tester la compilation avec Sphinx, à savoir **documentation-dev.veremes.net** (ce bucket n'est accessible que depuis l'adresse IP de Veremes).
```{Note}
Exception faite de cette documentation qui n'est disponible que sur le bucket de développement.
```
Il peut arriver que la documentation soit gérée sur une branche **documentation** pour une écriture plus intensive en début de projet. \
-Les issues dédiés à la rédaction de documentation sont habituellement associées au label **documentation**.
+Les issues dédiées à la rédaction de documentation sont habituellement associées au label **documentation**.
L'écriture de la documentation suit le flow habituel en temps normal.
-La documentation est validé avec le responsable produit et le service Marketing si possible.
+La documentation est validée avec le responsable produit et le service Marketing si possible.
-En ce qui concerne la rédaction des documentation des applications, une charte est disponible à [ce lien](http://documentation.veremes.net/charte/index.html).
\ No newline at end of file
+En ce qui concerne la rédaction des documentations des applications, une charte est disponible à [ce lien](http://documentation.veremes.net/charte/index.html).
\ No newline at end of file
diff --git a/source/git/index.rst b/source/git/index.rst
index 46dd7ca2a1bad60543c285d7e1cee65223ac2631..0b9b40458f8e9f2624e5600cfaeaf8ba9caf6af9 100644
--- a/source/git/index.rst
+++ b/source/git/index.rst
@@ -7,9 +7,9 @@ Git
:target: #
-Git est l'outil de versionnement qu'utilise Veremes pour ses développements que ce soit Web, FME ou autre.
+Git est l'outil de versionnement qu'utilise Veremes pour ses développements que ce soit Web, FME ou autres.
-Nous verrons ici les basiques sur l'utilisation de Git et des outils complémentaires, le flow utilisé par Veremes en ce qui concerne les développements, la procédure pour sortir un version, ...
+Nous verrons ici les basiques sur l'utilisation de Git et des outils complémentaires, le flow utilisé par Veremes en ce qui concerne les développements, la procédure pour sortir une version, ...
============================================
diff --git a/source/git/outils.md b/source/git/outils.md
index 9af509481618afc1d3978f60d3520f541bac70c9..f9bdd1265b5f173748bc551c232ca28ff7fed9ce 100644
--- a/source/git/outils.md
+++ b/source/git/outils.md
@@ -8,7 +8,7 @@ c'est à dire qu'il permet de suivre les évolutions faites sur nos fichier de c
Les grande force de Git sont, l'utilisation des branches, sa gestion des modifications et son architecture, qui en font un outil incontournable.
```{Note}
- Git a été conçut par Linus Torvalds, qui est un des concepteurs du noyau Linux, il a notamment développé une bonne partie du système de fichier qu'utilise encore Linux aujourd'hui. Ce qui est interressant c'est que Git fonctionne sensiblement comme un système de fichier.
+ Git a été conçu par Linus Torvalds, qui est un des concepteurs du noyau Linux, il a notamment développé une bonne partie du système de fichier qu'utilise encore Linux aujourd'hui. Ce qui est interressant c'est que Git fonctionne sensiblement comme un système de fichier.
```
### Installation
@@ -29,18 +29,18 @@ Architecture Git classique :
-Ce qui veut dire que chaques développeur à une copie locale du dépot distant, en cas de perte ou indisponibilité du dépot c'est un avantage significatif.
+Ce qui veut dire que chaque développeur à une copie locale du dépôt distant, en cas de perte ou indisponibilité du dépôt c'est un avantage significatif.
-Un dépot Git local peut être lié à plusieurs dépot distant (cas que nous ne verront pas).
+Un dépôt Git local peut être lié à plusieurs dépôts distants (cas que nous ne verront pas).
#### Git, comment ça marche ?
Git ne sait gérer que trois objets :
-- **Les blobs** : représente le contenu d'un fichier ou des modifiations partielles sur un fichier, ainsi qu'une signature (hash SHA1) de ce contenu.
-- **Les arbres** : liste de pointeur sur des blobs et/ou d'autres arbres (stock également les droits linux sur les fichiers), cette liste donne aussi suite à une signature SHA1
-- **Les commits** : Référence sur un arbre et à minima un autre commit (excpetion faite du commit initial), comporte aussi un message (commentaire) et un SHA1, référence un auteur et un commiter (les deux pouvant être différents)
+- **Les blobs** : représente le contenu d'un fichier ou des modifications partielles sur un fichier, ainsi qu'une signature (hash SHA1) de ce contenu.
+- **Les arbres** : liste de pointeur sur des blobs et/ou d'autres arbres (récupère également les droits Linux sur les fichiers), cette liste donne aussi suite à une signature SHA1
+- **Les commits** : Référence sur un arbre et a minima un autre commit (exception faite du commit initial), comporte aussi un message (commentaire) et un SHA1, référence un auteur et un commiter (les deux pouvant être différents)
```{Note}
Le seul objet qui est clairement lisible pour vous au final c'est le commit.
@@ -51,21 +51,21 @@ Git ne sait gérer que trois objets :
```
-Au final un dépot git c'est une arborescence de Commits rien de plus.
+Au final un dépôt git c'est une arborescence de commits rien de plus.
Pour en savoir plus sur le fonctionnement en profondeur de Git, je vous conseille [les chapitres 10.1, 10.2 et 10.3 de la documentation sur Git Scm](https://git-scm.com/book/fr/v2/Les-tripes-de-Git-Plomberie-et-porcelaine).
-Ces objet vont être géré à travers plusieurs zones distinctes.
+Ces objets vont être gérés à travers plusieurs zones distinctes.
1. **Zone de travail (Working area)** : C'est votre dossier de travail tel que vous le voyez basiquement, et vous ne manipulerez manuellement que cette zone.
-1. **Zone de cache/préparation (Staging area)** : Permet en réalité de généré les objets blobs et arbres avant de les associer à un commit
-1. **Dépot local (dossier .git)** : votre arborescence de commit personnelle (toutes les branches sont présentes)
-1. **Dépot distant** : L'arborescence de commit mutualisée, qui est le plus souvent unique et que l'on appelle par convention origin.
+1. **Zone de cache/préparation (Staging area)** : Permet en réalité de générer les objets blobs et arbres avant de les associer à un commit
+1. **Dépôt local (dossier .git)** : votre arborescence de commit personnelle (toutes les branches sont présentes)
+1. **Dépôt distant** : L'arborescence de commit mutualisée, qui est le plus souvent unique et que l'on appelle par convention **origin**.
-L'état de votre Zone de travail sera relatif à un commit, c'est à dire que les différences sont calculés relativement à un commit existant.
-Ce commit c'est ce qu'on appelle le HEAD (c'est le commit courant de votre zone de travail) :
+L'état de votre Zone de travail sera relatif à un commit, c'est-à-dire que les différences sont calculées relativement à un commit existant.
+Ce commit se nomme le HEAD (c'est le commit courant de votre zone de travail) :
@@ -74,56 +74,56 @@ Ce commit c'est ce qu'on appelle le HEAD (c'est le commit courant de votre zone
Quand on parle de Git, on parle systématiquement de branches, de merges et souvent de tags. Hors comme je l'ai dit précédemment en réalité ces objets n'existe pas pour Git.
**Une branche**, est simplement une référence à un commit existant qui va servir d'origine (de parent), qui sera le point de divergence. La branche sera un ensemble de commits qui aura pour but de corriger un bug ou de développer une fonctionnalité. Ce qui veut dire que le commit référence de la branche évoluera en même temps que le HEAD.
-Un branche existera souvent en deux exemplaires dans vos dépot, une branche locale qui appartient uniquement à votre dépot local et une branche distante qui appartient à la fois à votre dépot local et au dépot distant. Ces deux branches sont bien deux branches distinctes pour votre dépot git, en revanche git sait qu'il y a un lien entre les deux branche on parle de **tracking de branche ou de branche upstream**.
+Une branche existera souvent en deux exemplaires dans vos dépôts, une branche locale qui appartient uniquement à votre dépôt local et une branche distante qui appartient à la fois à votre dépôt local et au dépôt distant. Ces deux branches sont bien deux branches distinctes pour votre dépôt git, en revanche git sait qu'il y a un lien entre les deux branches on parle de **tracking de branche ou de branche upstream**.
-Une branche peut être **mergé/fusionné** dans une autre branche, ce qui donne lieu à un **commit de merge**, c'est à dire un commit ayant deux parents.
+Une branche peut être **mergé/fusionné** dans une autre branche, ce qui donne lieu à un **commit de merge**, c'est un commit ayant deux parents.
Dans le cas de branches **fast-forward** on pourra aussi réaliser un rebase plutôt qu'un merge (il s'agit d'une réécriture de l'historique, dans la pratique on fait rarement ça).
-Lors d'un merge complexe il est probable de rencontrer des **conflits**, un conflit survient lors d'un merge lorsque des modifications ont eues lieu sur les même lignes d'un même fichier. Il faut alors gérer les conflits, et finaliser le merge ou l'annuler (abort) si c'est trop complexe.
-La gestion des modifications au niveau de la ligne dans le fichier est incroyable en ce qui concerne le code, en revanche ça devient problèmatique sur des fichier généré comme les projets FME ou sur des binaires, mais ça reste possible.
+Lors d'un merge complexe il est probable de rencontrer des **conflits**, un conflit survient lors d'un merge lorsque des modifications ont eu lieu sur les mêmes lignes d'un même fichier. Il faut alors gérer les conflits, et finaliser le merge ou l'annuler (abort) si c'est trop complexe.
+La gestion des modifications au niveau de la ligne dans le fichier est incroyable en ce qui concerne le code, en revanche ça devient problématique sur des fichiers générés comme les projets FME ou sur des binaires, mais ça reste possible.
**Un tag**, au même titre qu'une branche est une référence sur un commit existant, à la différence que la référence n'évoluera pas en même temps que le HEAD.
Un tag peut être annoté ou non (on parle de tag **annoté** ou **léger/lightweight**).
-**Le stash** permet de mettre en attente des modification en cours dans une sorte de cinquième zone de travail. Le stash est uniquement présent sur votre dépot local, il est lié à un parent mais peut être appliqué sur un autre commit si nécessaire. On peut réaliser trois actions sur un stash :
-- **Apply** : on applique les modifications contenu dans le stash sur notre HEAD, en plus de ce qui est déjà en cours de modification (au risque de prendre un conflit).
-- **Delete** : La suppression su stash et donc potentiellement la perte des mdofication si non appliqué avant.
+**Le stash** permet de mettre en attente des modifications en cours dans une sorte de cinquième zone de travail. Le stash est uniquement présent sur votre dépôt local, il est lié à un parent mais peut être appliqué sur un autre commit si nécessaire. On peut réaliser trois actions sur un stash :
+- **Apply** : on applique les modifications contenues dans le stash sur notre HEAD, en plus de ce qui est déjà en cours de modification (au risque de prendre un conflit).
+- **Delete** : sa suppression du stash et donc potentiellement la perte des modifications si elles ne sont pas appliquées avant.
- **Pop** : Qui est en fait un combo de l'apply suivi du delete.
```{Tip}
- Par retour d'expérience, je préconise de dissocier l'apply et le delete plutôt que d'utiliser pop. Il se peut que dans le cas du pop, la récupération des modifications ne se fasse pas bien et que le delete s'applique quand même auquel cas vos modification seront partiellement ou totalement perdues.
+ Par retour d'expérience, je préconise de dissocier l'apply et le delete plutôt que d'utiliser pop. Il se peut que dans le cas du pop, la récupération des modifications ne se fasse pas bien et que le delete s'applique quand même auquel cas vos modifications seront partiellement ou totalement perdues.
```
-**Le cherry-pick** copie un commit existant pour l'appliquer sur votre HEAD, dans ce cas là, l'auteur du commit d'origine est aussi l'auteur du commit final, en revanche vous devenez le commiter à la place du commiter d'origine. Le cherry-pick est trés interressant pour déplacer des commit dans l'arborescence en revanche il est à double tranchant, **Cherry-pick un commit sur une branche qui sera mergé avec la branche d'origine entrainera systématiquement un conflit ou une perte de code.**
+**Le cherry-pick** copie un commit existant pour l'appliquer sur votre HEAD, dans ce cas-là, l'auteur du commit d'origine est aussi l'auteur du commit final, en revanche vous devenez le commiter à la place du commiter d'origine. Le cherry-pick est très intéressant pour déplacer des commits dans l'arborescence en revanche il est à double tranchant, **Cherry-pick un commit sur une branche qui sera mergée avec la branche d'origine entrainera systématiquement un conflit ou une perte de code.**
```{Warning}
- Je passe sous silence les notions trés avancées, comme les submodule/subtree qui ne sont plus utilisées aujourd'hui. Par retour d'expérience, c'est pénible à utiliser, rajoute énormément de compléxité sur les tâches simples et n'est pas adapté à nos architecture de développement.
+ Je passe sous silence les notions très avancées, comme les submodules/subtrees qui ne sont plus utilisées aujourd'hui. Par retour d'expérience, c'est pénible à utiliser, rajoute énormément de complexité sur les tâches simples et n'est pas adapté à nos architectures de développement.
```
-**Les hook** sont des scripts qui peuvent s'éxécuter à différents moments (pre-pull, post-pull, pre-push, post-push, ...). avec un hook, il est possible de détecter des changements, d'automatiser des actions sur votre postes, ou autre. Les hooks peuvent être locaux ou distant, sachant que vous ne pourrez pas agir sur un hook distant (ex : système de prtection de branche de Gitlab).
+**Les hooks** sont des scripts qui peuvent s'exécuter à différents moments (pre-pull, post-pull, pre-push, post-push, ...). avec un hook, il est possible de détecter des changements, d'automatiser des actions sur votre poste, ou autres. Les hooks peuvent être locaux ou distants, sachant que vous ne pourrez pas agir sur un hook distant (ex : système de protection de branche de Gitlab).
### Commandes
Une fiche récapitulative des commandes est disponible à [ce lien](http://documentation-dev.veremes.net/dev/fr/_static/ressources/git/git-cheat-sheet.pdf).
-Dans ces commande quand je parle de référence, ça veut dire que la commande attend un commit, ça veut dire qu'il prendra une branche, un tag, une référence relative au HEAD, un identifiant sha1 de commit, ...
+Dans ces commandes quand je parle de référence, ça veut dire que la commande attend un commit, ça veut dire qu'il prendra une branche, un tag, une référence relative au HEAD, un identifiant sha1 de commit, ...
-- **init** : Créer un nouveau dépot local
-- **clone** : Récupére un dépot distant en local
+- **init** : Créer un nouveau dépôt local
+- **clone** : Récupère un dépôt distant en local
- **checkout** : Permet de déplacer le HEAD sur une référence (permet notamment de passer en HEAD détaché)
-- **add** : Permet de passer des modification en cours dans la staging area (créer les blobs et les arbres)
+- **add** : Permet de passer des modifications en cours dans la staging area (créer les blobs et les arbres)
- **commit** : créer un nouveau commit avec le contenu de la staging area
-- **fetch** : Met à jour les branches distante sur le dépot local depuis le dépot distant
+- **fetch** : Met à jour les branches distantes sur le dépôt local depuis le dépôt distant
- **merge** : Fusionne deux branches via un commit de merge
-- **rebase** : Permet de réécrire l'historique en agissant sur l'arbre, il y a plusieurs type de rebase
-- **pull** : réalise un fetch pour mettre à jour toutes les branches distante du dépot local depuis le distant, puis enchaine sur un merge via le lien de branche upstraeam pour mettre à jour votre branche local.
-- **push** : Merge la branche locale dans sa branche distante upstream localement et envoi le résultat sur le serveur distant pour que ce soit disponible pour tout le monde
+- **rebase** : Permet de réécrire l'historique en agissant sur l'arbre, il y a plusieurs types de rebase
+- **pull** : réalise un fetch pour mettre à jour toutes les branches distantes du dépôt local depuis le distant, puis enchaine sur un merge via le lien de branche upstream pour mettre à jour votre branche locale.
+- **push** : Merge la branche locale dans sa branche distante upstream localement et envoie le résultat sur le serveur distant pour que ce soit disponible pour tout le monde
- **reset** : Permet de déplacer le HEAD de la branche courante sur un autre commit, en conservant les modifications ou non
-- **revert** : créer un commit opposé à un commit existant, ce qui aura pour effet d'annuler complétement le commit ciblé (**ATTENTION!** avec les merge).
-- **stash** : Permet de créer puis de gérer vos stash
+- **revert** : créer un commit opposé à un commit existant, ce qui aura pour effet d'annuler complètement le commit ciblé (**ATTENTION!** avec les merges).
+- **stash** : Permet de créer puis de gérer vos stashs
- **bisect** : Permet de détecter le commit à l'origine d'une erreur
Je ne rentre pas dans le détail des commandes car 99,99999999999999999% du temps vous vous servirez de Git à travers GitKraken.
@@ -140,53 +140,53 @@ Je ne rentre pas dans le détail des commandes car 99,99999999999999999% du temp
- Ne pas cherry-pick un commit entre deux branches amenées à être mergées.
- Mise à jour **régulière** des branches de travail **avant de merge** dans la branche principale pour éviter les **conflits complexes** à résoudre.
- **Nettoyage régulier** des branches locales et distantes.
-- Utilisation du **même nom** pour les branches **locales** et **distantes** liées (la branche distante préfixé par origin/).
-- Ne **pousser** sur le dépot distant que du **code utile** pour le projet, pas de code temporaire.
-- Ne **jamais réécrire l'historique** d'une branche qui est déjà poussée sur le dépots distant.
+- Utilisation du **même nom** pour les branches **locales** et **distantes** liées (la branche distante préfixée par origin/).
+- Ne **pousser** sur le dépôt distant que du **code utile** pour le projet, pas de code temporaire.
+- Ne **jamais réécrire l'historique** d'une branche qui est déjà poussée sur le dépôt distant.
- Limiter au maximum l'utilisaton du force push.
- Utiliser un workflow de gestion des branches : **GitlabFlow**.
-- **Toujours mettre à jour le dépot local (git pull) avant de pousser les modification sur le dépot distant (git push)**.
+- **Toujours mettre à jour le dépôt local (git pull) avant de pousser les modifications sur le dépôt distant (git push)**.
## GitLab
-Il existe plusieurs gestionnaire de dépot distant pour Git (Github, GitLab, BitBucket, ...).
+Il existe plusieurs gestionnaires de dépôts distants pour Git (Github, GitLab, BitBucket, ...).
Nous avons choisi GitLab pour sa similarité avec GitHub, et la possibilité d'en avoir une version on-premise.
```{Warning}
Gitlab existe aussi en SaaS, au moment de créer votre compte attention de bien vous inscrire sur le [Gitlab de Veremes](https://gitlab.veremes.net/).
- Votre compte devra être valider par administrateur ce qui pourra prendre un peu de temps.
+ Votre compte devra être validé par administrateur ce qui pourra prendre un peu de temps.
```
### Fonctionnalités
-Gitlab est un gestionnaire de dépot distant basé sur Github à l'origine. Il apporte une interface Web permettant d'intéragir avec les dépots Git et énormément de fonctionnalités additionnnels. Comme le suivi de ticket via son système d'issue, l'automatisation de processus via les CI/CD, ou la simplification des revue de code via son système de Merge Request, ou encore simplement l'organisation des dépot sous une arborescence, ainsi que la gestion trés simple de l'accés aux dépots.
+Gitlab est un gestionnaire de dépôt distant basé sur Github à l'origine. Il apporte une interface Web permettant d'interagir avec les dépôts Git et énormément de fonctionnalités additionnels. Comme le suivi de ticket via son système d'issue, l'automatisation de processus via les CI/CD, ou la simplification des revues de code via son système de Merge Request, ou encore simplement l'organisation des dépôts sous une arborescence, ainsi que la gestion très simple de l'accès aux dépôts.
-Dans gitlab, **un projet** est un dépot. Un projet est lié à **un groupe**, qui pourra contenir plusieurs projets, ce qui va permettre d'obtenir une arborescence simplifiant la navigation.
+Dans gitlab, **un projet** est un dépôt. Un projet est lié à **un groupe**, qui pourra contenir plusieurs projets, ce qui va permettre d'obtenir une arborescence simplifiant la navigation.
-Un projet/groupe peut avoir un accés public ou restreint à certains utilisateurs (qui auront différents niveaux de droits). La quasi-totalité des sous-objets pourront être géré soit sur le projet, soit sur le groupe (droits, labels, fonctionnalités, ...), ce qui dans ce dernier cas impactera tous les projets lui appartenant.
+Un projet/groupe peut avoir un accès public ou restreint à certains utilisateurs (qui auront différents niveaux de droits). La quasi-totalité des sous-objets pourront être géré soit sur le projet, soit sur le groupe (droits, labels, fonctionnalités, ...), ce qui dans ce dernier cas impactera tous les projets lui appartenant.
-Il y aura cinq niveaux d'accéssibilités pour les utilisateurs (et un sixième en comptant l'administration GitLab), vous trouverez le détail des droits de chacun dans la [documentation de GitLab](https://docs.gitlab.com/ee/user/permissions.html).
+Il y aura cinq niveaux d'accessibilités pour les utilisateurs (et un sixième en comptant l'administration GitLab), vous trouverez le détail des droits de chacun dans la [documentation de GitLab](https://docs.gitlab.com/ee/user/permissions.html).
-Gitlab permet de suivre et tracer les bugs/évolutions via un système d'issue, qui pourront être clairement identifier via des **labels** et regroupper dans des **milestone/jalons** ce qui nous sert de roadmap pour nos développements.
+Gitlab permet de suivre et tracer les bugs/évolutions via un système d'issue, qui pourront être clairement identifié via des **labels** et regrouper dans des **milestone/jalons** ce qui nous sert de roadmap pour nos développements.
-**Les merge request** permettent de gérer le merge directement sur le dépot distant ou de réaliser un merge classique sur notre poste, ce qui est aussi un gros gain de temps. L'interface permet de faire une revue de code assez rapidement, de gagner en réactivité et améliore le suivi des dévelopements.
+**Les merge request** permettent de gérer le merge directement sur le dépôt distant ou de réaliser un merge classique sur notre poste, ce qui est aussi un gros gain de temps. L'interface permet de faire une revue de code assez rapidement, de gagner en réactivité et améliore le suivi des développements.
-Gitlab intégre également une interface d'édition des fichiers directement sur l'interface Web, avec des fonctionnalités trés basiques.
+Gitlab intégre également une interface d'édition des fichiers directement sur l'interface Web, avec des fonctionnalités très basiques.
## GitKraken
Veremes a choisi d'utiliser Gitkraken comme outil graphique pour gérer Git sur nos postes.
-GitKraken est un outil trés puissant, qui s'adapte aux habitudes de chacun et aux pratiques de l'entreprise.
-Il est trés utilisé dans le monde et présente l'avantage d'être compatible sur Windows et Linux.
+GitKraken est un outil très puissant, qui s'adapte aux habitudes de chacun et aux pratiques de l'entreprise.
+Il est très utilisé dans le monde et présente l'avantage d'être compatible sur Windows et Linux.
La documentation de GitKraken est disponible via [ce lien](https://help.gitkraken.com/gitkraken-client/gitkraken-client-home/)
### Installation
-Il faut récupérer le package linux ou l'installeur windows directement sur le site de [Axosoft](https://www.gitkraken.com/git-client).
+Il faut récupérer le package Linux ou l'installeur Windows directement sur le site de [Axosoft](https://www.gitkraken.com/git-client).
Pour linux, il suffit de lancer `sudo dpkg -i mon_paquet_gitkraken.deb`.
@@ -202,13 +202,13 @@ Il est possible d'avoir des interfaces plus ou moins différentes avec GitKraken
-Les rectangles rouges délimitent les zones que je vais expliqué par la suite :
-1. Le fil d'arianne, permet de savoir sur quel dépot vous êtes, la branche actuellement en cours d'utilisation ou le commit utilisé comme HEAD, et eventuellement le submodules, ... dans certains cas d'utilisation. Cette partie permet également d'alterner entre les dépots/branches (au prix d'un chargement)
-1. Contient la liste des branches locales, c'est à dire présente uniquement sur votre poste (ça peut inclure des branches lié à des branches distantes)
+Les rectangles rouges délimitent les zones que je vais expliquer par la suite :
+1. Le fils d'Ariane, permet de savoir sur quel dépôt vous êtes, la branche actuellement en cours d'utilisation ou le commit utilisé comme HEAD, et éventuellement le submodules, ... dans certains cas d'utilisation. Cette partie permet également d'alterner entre les dépôts/branches (au prix d'un chargement)
+1. Contient la liste des branches locales, c'est-à-dire présente uniquement sur votre poste (ça peut inclure des branches liées à des branches distantes)
1. La liste des branches disponibles sur le serveur distant
1. La liste des tags
1. Boutons permettant les actions principales, pull, fetch, push, gestion des stash
-1. Arborescence de commit sur tout le dépot
+1. Arborescence de commit sur tout le dépôt
1. Ce dernier bloc, vous permet de voir ce qui est en cours de modification dans votre dossier de travail, d'interagir avec votre zone de cache et de commit
@@ -228,9 +228,9 @@ Pour y accéder il vous suffit d'ouvrir un nouvel onglet et choisir `GitKraken C
-En navigant via l'invite de commande, si vous entrez dans un dossier contenant un dépot Git alors Gitkraken chargera automatiquement les infosrmations de ce dépot. Ce qui vous permet par exemple de passer d'une application à un de ses module ou une autre application en faisant vous déplaçant simplement. De plus se terminal fonctionnant comme un terminal normal vous pouvez lancer d'autre commande comme `code mon_dossier` qui permet d'ouvrir directement Visual Studio Code, ...
+En navigant via l'invite de commande, si vous entrez dans un dossier contenant un dépôt Git alors Gitkraken chargera automatiquement les informations de ce dépôt. Ce qui vous permet par exemple de passer d'une application à un de ses modules ou une autre application en faisant vous déplaçant simplement. De plus ce terminal fonctionnant comme un terminal normal vous pouvez lancer d'autre commande comme `code mon_dossier` qui permet d'ouvrir directement Visual Studio Code, ...
-En revanche l'interface étant moins compléte, il faudra régulièrement utiliser des commandes git trés simple comme :
+En revanche l'interface étant moins complète, il faudra régulièrement utiliser des commandes git très simples comme :
- git pull
- git push
- git checkout ma_branche
@@ -238,22 +238,22 @@ En revanche l'interface étant moins compléte, il faudra régulièrement utilis
- git stash
- git branch --all
-Par contre l'invite de commande a une auto complétion qui vous aide avec les commande GitKraken et Git qui est vraiment trés utile.
+Par contre l'invite de commande a une auto complétion qui vous aide avec les commandes GitKraken et Git qui est vraiment très utile.
Les interactions avec la zone de gestion des commit ou l'arborescence est identique à l'interface classique.
#### Workspaces
-GitKraken permet de regrouper des dépots et d'en faire un workspace, ce qui vu notre architecture est trés pratique. Ces workspace peuvent être locaux (depuis la version 9.1.0 de GitKraken) ce qui les rend bien plus souple, les workspace cloud ne peuvent avoir qu'une seul fois le même dépot, par exemple il faut relocaliser Vitis à chaque changement de workspaces.
+GitKraken permet de regrouper des dépôts et d'en faire un workspace, ce qui vu notre architecture est très pratique. Ces workspaces peuvent être locaux (depuis la version 9.1.0 de GitKraken) ce qui les rend bien plus souples, les workspaces cloud ne peuvent avoir qu'une seule fois le même dépôt, par exemple il faut relocaliser Vitis à chaque changement de workspaces.
-Par défaut le premier onglet de gotre GitKraken vous permet de gérer vos workspace, cliquer ensuite sur le bouton `New Workspace`, une modale s'ouvre.
+Par défaut le premier onglet de votre GitKraken vous permet de gérer vos workspaces, cliquer ensuite sur le bouton `New Workspace`, une modale s'ouvre.
-En cliquant sur `browse repositories` vous pourrez naviguer dans votre systéme de fichier pour trouver les dépots.
+En cliquant sur `browse repositories` vous pourrez naviguer dans votre système de fichiers pour trouver les dépôts.
```{Tip}
- Pour gagner du temps, naviguer une fois jusqu'à l'application, copier le chemin et valider le premier dépots. Puis relancez la navigation, coller le chemin de l'application et sélectionnez directement le dossier src, ça importera tous les dépots de modules en même temps.
+ Pour gagner du temps, naviguer une fois jusqu'à l'application, copier le chemin et valider le premier dépôt. Puis relancez la navigation, coller le chemin de l'application et sélectionnez directement le dossier src, ça importera tous les dépôts de modules en même temps.
```
Vous pourrez ensuite ouvrir le workspace.
@@ -261,19 +261,19 @@ Vous pourrez ensuite ouvrir le workspace.
Le workspace présente plusieurs avantages :
-- Fetch tous les dépots en même temps
-- Visualiser l'état de vos branche courante pour chaques dépot en même temps
-- Ouvrir un onglet par dépots facilement
-- Ouvrir VS code sur un dépot ou tous facilement
+- Fetch tous les dépôts en même temps
+- Visualiser l'état de vos branches courantes pour chaque dépôt en même temps
+- Ouvrir un onglet par dépôt facilement
+- Ouvrir VS code sur un dépôt ou tous facilement
-Le fait d'avoir un workspace par Application permet de basculer rapidement d'une application à une autre. Le seul manque à mon sens est le manque d'intégration avec Gitlab que l'on a avec des workspaces de type Cloud, ce serait vraiment top.
+Le fait d'avoir un workspace par application permet de basculer rapidement d'une application à une autre. Le seul manque à mon sens, est l'intégration avec Gitlab que l'on a avec des workspaces de type Cloud, ce serait vraiment top.
## Autres outils graphiques pour Git
-Je ne rentre pas dans le détails de ces outils car leurs utilisations actuellement est trés ponctuelles, mais ce sont des alternative à GitKraken en cas de manques de licences ou si on a besoin d'un outil plus simple à utiliser.
+Je ne rentre pas dans le détail de ces outils car leurs utilisations actuellement sont très ponctuelles, mais ce sont des alternatives à GitKraken en cas de manques de licences ou si on a besoin d'un outil plus simple à utiliser.
-- [SourceTree](https://www.sourcetreeapp.com/) : Trés similaire à GitKraken, il a moins d'intégration avec Gitlab car développer par Atlassian, le propriétaire de BitBucket
-- [Github Desktop](https://desktop.github.com/) : Beaucoup plus simpliste, ça fera largement l'affaire pour un utilisateur qui utilise Git rarement ou qui ne fait que des actions trés simples (pull, push, commit), pour corriger/écrire de la documentation.
-- [Tortoise Git](https://tortoisegit.org/) : Pour les anciens cramponnés à SVN ou pour avoir un gestionnaire ultra léger.
-- [Git Lens](https://www.gitkraken.com/gitlens) : également développer par Axosoft, c'ets un outil complémentaire à Gitkraken, qui peut le remplacer sur des usages trés simpliste, directement dans Visual Studio Code.
\ No newline at end of file
+- [SourceTree](https://www.sourcetreeapp.com/) : Très similaire à GitKraken, il a moins d'intégration avec Gitlab car développé par Atlassian, le propriétaire de BitBucket
+- [Github Desktop](https://desktop.github.com/) : Beaucoup plus simpliste, ça fera largement l'affaire pour un utilisateur qui utilise Git rarement ou qui ne fait que des actions très simples (pull, push, commit), pour corriger/écrire de la documentation.
+- [Tortoise Git](https://tortoisegit.org/) : Pour les anciens cramponnés à SVN ou pour avoir un gestionnaire ultra-léger.
+- [Git Lens](https://www.gitkraken.com/gitlens) : également développer par Axosoft, c'ets un outil complémentaire à Gitkraken, qui peut le remplacer sur des usages très simplistes, directement dans Visual Studio Code.
\ No newline at end of file