From e3f1ef102d3ff728e34f7b6cd30824de7c46644e Mon Sep 17 00:00:00 2001 From: Thomas Faria <57811152+ThomasFaria@users.noreply.github.com> Date: Mon, 13 Nov 2023 11:53:50 +0100 Subject: [PATCH] Relecture git (#448) * fix * reread * re read * Update content/git/exogit.qmd * Apply suggestions from code review --------- Co-authored-by: Lino Galiana --- content/git/exogit.qmd | 113 +++++++++++++++++++-------------------- content/git/introgit.qmd | 16 +++--- 2 files changed, 62 insertions(+), 67 deletions(-) diff --git a/content/git/exogit.qmd b/content/git/exogit.qmd index 605fa478b..cc15f7995 100644 --- a/content/git/exogit.qmd +++ b/content/git/exogit.qmd @@ -59,10 +59,9 @@ pour l'Insee [sur ce site](https://inseefrlab.github.io/formation-bonnes-pratiqu et des ressources de la documentation collaborative sur `R` qu'est `utilitR` ([des éléments sur la configuration](https://www.book.utilitr.org/03_fiches_thematiques/fiche_configurer_git) et [pratique sur RStudio](https://www.book.utilitr.org/03_fiches_thematiques/fiche_git_utilisation)). Toutes -les ressources ne sont donc pas du `Python` car `Git` est un outil tranversal +les ressources ne sont donc pas du `Python` car `Git` est un outil transversal qui doit servir quel que soit le langage de prédilection. -L'idée de ce chapitre est d'amener, progressivement, à la mise en oeuvre de pratiques collaboratives devenues standards dans le domaine de l'_open-source_ mais également de plus en plus communes dans les administrations et entreprises de la _data science_. @@ -96,9 +95,7 @@ le dépôt distant (*remote*) et la copie ou les copies locales (les *clones*) d'un dépôt. Le dépôt distant est généralement stocké sur une forge logicielle (`Github` ou `Gitlab`) et sert à centraliser la version collective d'un projet. Les copies locales sont des copies de travail -qu'on utilise pour faire évoluer un projet: -![](https://www.book.utilitr.org/pics/git/gitlab.png) `Git` est un système de contrôle de version asynchrone c'est-à-dire qu'on n'interagit pas en continu avec le dépôt distant (comme c'est le @@ -109,7 +106,7 @@ de temps en temps. Bien qu'il soit possible d'avoir une utilisation hors-ligne de `Git`, c'est-à-dire un pur contrôle de version local sans dépôt distant, cela est une utilisation -rare et qui comporte un intérêt limite. L'intérêt de `Git` est +rare et qui comporte un intérêt limité. L'intérêt de `Git` est d'offrir une manière robuste et efficace d'interagir avec un dépôt distant facilitant ainsi la collaboration en équipe ou en solitaire. @@ -143,7 +140,7 @@ les fonctionalités coeur de ces deux interfaces qui sont en fait quasi-identiqu ## Première étape: créer un compte `Github` -Les deux premières étapes se font sur `Github`. +Les deux premières étapes se font sur [Github](https://github.com). ::: {.cell .markdown} ```{=html} @@ -151,12 +148,12 @@ Les deux premières étapes se font sur `Github`.

Exercice 1 : Créer un compte Github

``` -1. Si vous n'en avez pas déjà un, créer un compte sur https://github.com +1. Si vous n'en avez pas déjà un, créer un compte sur https://github.com 2. Créer un dépôt vide. Créez ce dépôt **privé**, cela permettra dans l'exercice 2 d'activer notre jeton. Vous pourrez le rendre public après l'exercice 2, c'est comme vous le souhaitez. -*Connexion sur https://github.com/ > + (en haut de la page) > New repository > Renseigner le "Repository name" > Cocher "private" > "Create repository"* +*Connexion sur https://github.com > + (en haut de la page) > New repository > Renseigner le "Repository name" > Cocher "private" > "Create repository"* ```{=html} @@ -236,7 +233,7 @@ connu de vous seuls. ## Créer un jeton La [documentation officielle](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) comporte un certain nombre de captures d'écran expliquant -comme procéder. +comment procéder. Nous allons utiliser le `credential helper` associé à Git pour stocker ce jeton. Ce `credential helper` permet de conserver de manière pérenne @@ -373,7 +370,7 @@ ou dont on ne veut pas suivre les modifications (typiquement les grosses bases d C'est le fichier `.gitignore` qui gère les fichiers exclus du contrôle de version. -1️⃣ Créer un fichier nommé `.gitignore` (:warning: ne pas changer +1️⃣ Créer un fichier nommé `.gitignore` (⚠️ ne pas changer ce nom, et s'assurer que celui-ci n'a pas d'extension) via le bloc note ou votre IDE. Sur la session `Jupyter` d'`Onyxia`, si le `Clic Droit > rename` ne fonctionne pas, vous pouvez faire : `File > New > Text file`après vous être assurés que vous vous situez bien dans le dossier de l'arborescence. Un fichier `untitled.txt` se crée, que vous pouvez renommer en faisant un `cd ` puis `mv untitled.txt .gitignore` dans le terminal. @@ -474,6 +471,8 @@ retrouver un cadre ayant cet aspect (à gauche pour `Jupyter` et à droite pour ![](git-status-ensae.png) ![](git_vscode_1.png) + +Interface graphique Git sous Jupyter (à gauche) et VSCode (à droite) ::: @@ -583,7 +582,7 @@ Sur `VSCode`, il faut au contraire regarder en haut. ![](git_vscode_2.png) -:one: Entrer le titre `Initial commit` et ajouter une description +1️⃣ Entrer le titre `Initial commit` et ajouter une description `Création du fichier .gitignore : tada :` (sans les espaces autour des `:`). `: tada :` (sans les espaces) sera converti en emoji :tada: par `Github` quand on voudra afficher la description du commit[^4]. Sur `VSCode`, le titre du commit correspond à la @@ -599,11 +598,11 @@ Le fait de nommer le premier commit *"Initial commit"* est une habitude, vous n'êtes pas obligé de suivre cette convention si elle ne vous plaît pas. -:two: Cliquer sur `Commit`. Le fichier a disparu de la liste, c'est normal, +2️⃣ Cliquer sur `Commit`. Le fichier a disparu de la liste, c'est normal, il n'a plus de modification à valider. Pour le retrouver dans la liste des fichiers `Changed`, il faudra le modifier à nouveau -:three: Sur `Jupyter`, cliquer sur l'onglet `History` ou sur `VSCode` cliquer +3️⃣ Sur `Jupyter`, cliquer sur l'onglet `History` ou sur `VSCode` cliquer sur l'icône `View Git Graph`. Votre `commit` apparaît à ce niveau. Si vous cliquez dessus, vous obtenez des informations sur le `commit`. @@ -710,7 +709,7 @@ git remote add origin **** Remplacer les astérisques par l'url du dépôt. ----> -:one: +1️⃣ L'objectif est d'envoyer vos modifications vers `origin`. On va passer par la ligne de commande car les boutons `push`/`pull` de l'extension `Jupyter` ne fonctionnent pas de manière systématique. @@ -734,7 +733,7 @@ il faut taper votre identifiant Github et **votre mot de passe correspond au personal access token nouvellement créé** ! -:two: Retournez voir le dépôt sur `Github`, vous devriez maintenant voir le fichier +2️⃣ Retournez voir le dépôt sur `Github`, vous devriez maintenant voir le fichier `.gitignore` s'afficher en page d'accueil. ```{=html} @@ -759,7 +758,7 @@ des fichiers. On rappatriera les résultats en local dans un deuxième temps.

Exercice 7 : Rapatrier des modifs en local

``` -:one: Se rendre sur votre dépôt depuis l'interface . +1️⃣ Se rendre sur votre dépôt depuis l'interface . 2 manières de faire à ce niveau : * Cliquer sur `Add file > Create new file` et appeler le fichier `README.md` @@ -768,7 +767,7 @@ Supprimez tout autre texte si `Github` vous a suggéré un contenu pour le `README` -:two: L'objectif est de +2️⃣ L'objectif est de donner au `README.md` un titre en ajoutant, au début du document, la ligne suivante : ```{python} @@ -786,12 +785,12 @@ Sautez une ligne et entrez le texte que vous désirez, sans ponctuation. Par exe le chêne un jour dit au roseau ~~~ -:three: Cliquez sur l'onglet `Preview` pour voir le texte mis en forme au format `Markdown` +3️⃣ Cliquez sur l'onglet `Preview` pour voir le texte mis en forme au format `Markdown` -:four: Rédiger un titre et un message complémentaire pour faire le `commit`. Conserver +4️⃣ Rédiger un titre et un message complémentaire pour faire le `commit`. Conserver l'option par défaut `Commit directly to the main branch` -:five: Editer à nouveau le `README` en cliquant sur le crayon juste au dessus +5️⃣ Editer à nouveau le `README` en cliquant sur le crayon juste au dessus de l'affichage du contenu du `README`. Ajouter une deuxième phrase et corrigez la @@ -802,11 +801,11 @@ Le Chêne un jour dit au roseau : Vous avez bien sujet d'accuser la Nature ~~~ -:six: Au dessus de l'aborescence des fichiers, vous devriez voir s'afficher le +6️⃣ Au dessus de l'aborescence des fichiers, vous devriez voir s'afficher le titre du dernier commit. Vous pouvez cliquer dessus pour voir la modification que vous avez faite. -:seven: Les résultats sont sur le dépôt distant mais ne sont pas sur votre +7️⃣ Les résultats sont sur le dépôt distant mais ne sont pas sur votre dossier de travail dans `Jupyter` ou `VSCode`. Il faut re-synchroniser votre copie locale avec le dépôt distant : @@ -826,7 +825,7 @@ Cela signifie : *"git récupère (`pull`) les modifications sur la branche `main` vers mon dépôt (alias `origin`)"* -:eight: Regarder à nouveau l'historique des commits. Cliquez sur le +8️⃣ Regarder à nouveau l'historique des commits. Cliquez sur le dernier commit et affichez les changements sur le fichier. Vous pouvez remarquer la finesse du contrôle de version : `Git` détecte au sein de la première ligne de votre texte que vous avez mis des majuscules @@ -891,9 +890,9 @@ Il faut **absolument** bannir les usages de `push force` qui peuvent déstabilis ``` -:one: Ouvrir une *issue* sur `Github`. Signaler qu'il serait bien d'ajouter un emoji chat dans le README. Dans la partie de droite, cliquer sur la petite roue à côté de `Label` et cliquer sur `Edit Labels`. Créer un label `Markdown`. Normalement, le label a été ajouté. +1️⃣ Ouvrir une *issue* sur `Github`. Signaler qu'il serait bien d'ajouter un emoji chat dans le README. Dans la partie de droite, cliquer sur la petite roue à côté de `Label` et cliquer sur `Edit Labels`. Créer un label `Markdown`. Normalement, le label a été ajouté. -:two: Retournez sur votre dépôt local. Vous allez créer une branche nommée +2️⃣ Retournez sur votre dépôt local. Vous allez créer une branche nommée `issue-1` Avec l'interface graphique de JupyterLab, cliquez sur `Current Branch - Main` @@ -913,7 +912,7 @@ git checkout -b issue-1 [^4]: La commande `checkout` est un couteau-suisse de la gestion de branche en `Git`. Elle permet en effet de basculer d'une branche à l'autre, mais aussi d'en créer, etc. -:three: Ouvrez `README.md` et ajoutez un emoji chat (`:cat:`) à la suite du titre. +3️⃣ Ouvrez `README.md` et ajoutez un emoji chat (`:cat:`) à la suite du titre. Faites un commit en refaisant les étapes vues dans les exercices précédents. N'oubliez pas, cela se fait en deux étapes: @@ -929,7 +928,7 @@ git commit -m "ajout emoji chat" ~~~ -:four: Faire un **deuxième commit** pour ajouter un emoji koala (:koala:) puis +4️⃣ Faire un **deuxième commit** pour ajouter un emoji koala (:koala:) puis pousser les modifications locales. Cela peut être fait avec l'interface @@ -942,7 +941,7 @@ Sinon, si vous utilisez la ligne de commande, vous devrez taper git push origin issue-1 ~~~~ -:five: Dans `Github`, devrait apparaître +5️⃣ Dans `Github`, devrait apparaître > `issue-1 had recent pushes XX minutes ago`. @@ -963,7 +962,7 @@ En attendant, vous avez créé un lien entre l'*issue* et la *pull request* Au passage, vous pouvez ajouter le label `Markdown` sur la droite. -:six: En local, retourner sur `main`. Dans l'interface `Jupyter`, il suffit +6️⃣ En local, retourner sur `main`. Dans l'interface `Jupyter`, il suffit de cliquer sur `main` dans la liste des branches. Sur `VSCode`, la liste des branches apparaît en cliquant sur le nom de la branche actuelle (`issue-1` en théorie à ce stade). Si vous êtes en ligne de commande, il faut faire @@ -979,7 +978,7 @@ Ajouter une phrase à la suite de votre texte dans le `README.md` (ne touchez pas au titre !). Vous pouvez remarquer que les emojis ne sont pas dans le titre, c'est normal vous n'avez pas encore fusionné les versions -:seven: Faire un commit et un push. En ligne de commande, cela donne +7️⃣ Faire un commit et un push. En ligne de commande, cela donne ~~~shell git add . @@ -988,7 +987,7 @@ git push origin main ~~~ -:eight: Sur `Github`, cliquer sur `Insights` en haut du dépôt puis, à gauche sur `Network` (cela n'est +8️⃣ Sur `Github`, cliquer sur `Insights` en haut du dépôt puis, à gauche sur `Network` (cela n'est possible que si vous avez rendu public votre dépôt). Vous devriez voir apparaître l'arborescence de votre dépôt. On peut voir `issue-1` comme une ramification et `main` comme le tronc. @@ -1001,7 +1000,7 @@ Une fois que cela est fait, vous pouvez retourner dans `Insights` puis `Network` ![](squashmerge.png) -:nine: Supprimer la branche (*branch > delete this branch*). Puisqu'elle est mergée, elle ne servira plus. La conserver risque d'amener à des `push` involontaires dessus. +9️⃣ Supprimer la branche (*branch > delete this branch*). Puisqu'elle est mergée, elle ne servira plus. La conserver risque d'amener à des `push` involontaires dessus. ```{=html} @@ -1088,9 +1087,9 @@ Cet exercice se fait par groupe de trois ou quatre. Il y aura deux rôles dans c - Une personne aura la responsabilité d'être **mainteneur** - Deux à trois personnes seront **développeurs**. -:one: Le mainteneur crée un dépôt sur `Github`. Il/Elle donne des droits au(x) développeur(s) du projet (`Settings > Manage Access > Invite a collaborator`). +1️⃣ Le mainteneur crée un dépôt sur `Github`. Il/Elle donne des droits au(x) développeur(s) du projet (`Settings > Manage Access > Invite a collaborator`). -:two: Chaque membre du projet, crée une copie locale du projet grâce à la commande `git clone` ou +2️⃣ Chaque membre du projet, crée une copie locale du projet grâce à la commande `git clone` ou avec le bouton `Clone a repository` de `JupyterLab`. Pour cela, récupérer l'url HTTPS du dépôt en copiant l'url du dépôt que vous pouvez trouver, par exemple, dans la page d'accueil du dépôt, en dessous de `Quick setup — if you’ve done this kind of thing before` @@ -1101,7 +1100,7 @@ En ligne de commande, cela donnera: git clone https://github.com//.git ~~~ -:three: Chaque membre du projet crée un fichier avec son nom et son prénom, selon cette structure `nom-prenom.md` en évitant les caractères spéciaux. Il écrit dedans trois phrases de son choix **sans ponctuation ni majuscules** (pour pouvoir effectuer une correction ultérieurement). Enfin, il commit sur le projet. +3️⃣ Chaque membre du projet crée un fichier avec son nom et son prénom, selon cette structure `nom-prenom.md` en évitant les caractères spéciaux. Il écrit dedans trois phrases de son choix **sans ponctuation ni majuscules** (pour pouvoir effectuer une correction ultérieurement). Enfin, il commit sur le projet. Pour rappel, en ligne de commande cela donnera les commandes suivantes à modifier @@ -1110,14 +1109,14 @@ git add nom-prenom.md git commit -m "C'est l'histoire de XXXXX" ~~~ -:four: Chacun essaie d'envoyer (*push*) ses modifications locales sur le dépôt: +4️⃣ Chacun essaie d'envoyer (*push*) ses modifications locales sur le dépôt: ~~~shell git push origin main ~~~ -:five: A ce stade, une seule personne (la plus rapide) devrait ne pas avoir rencontré de rejet du `push`. C'est normal, avant d'accepter une modification `Git` vérifie en premier lieu la cohérence de la branche avec le dépôt distant. Le premier ayant fait un `push` a modifié le dépôt commun ; les autres doivent intégrer ces modifications dans leur version locale (*pull*) avant d'avoir le droit de proposer un changement. +5️⃣ A ce stade, une seule personne (la plus rapide) devrait ne pas avoir rencontré de rejet du `push`. C'est normal, avant d'accepter une modification `Git` vérifie en premier lieu la cohérence de la branche avec le dépôt distant. Le premier ayant fait un `push` a modifié le dépôt commun ; les autres doivent intégrer ces modifications dans leur version locale (*pull*) avant d'avoir le droit de proposer un changement. Pour celui/celle/ceux dont le `push` a été refusé, faire @@ -1127,12 +1126,12 @@ git pull origin main pour ramener les modifications distantes en local. -:six: Taper `git log` et regarder la manière dont a été intégré la modification de votre camarade ayant pu faire son `push` +6️⃣ Taper `git log` et regarder la manière dont a été intégré la modification de votre camarade ayant pu faire son `push` Vous remarquerez que les commits de vos camarades sont intégrés tels quels à l'histoire du dépôt. -:seven: Faire à nouveau +7️⃣ Faire à nouveau ~~~shell git pull origin main @@ -1170,15 +1169,15 @@ Il faut **immédiatement oublier cette solution**, elle crée de nombreux probl Dans la continuité de l'exercice précédent, chaque personne va travailler sur les fichiers des autres membres de l'équipe. -:one: Les deux ou trois développeurs ajoutent la ponctuation et les majuscules du fichier du premier développeur. +1️⃣ Les deux ou trois développeurs ajoutent la ponctuation et les majuscules du fichier du premier développeur. -:two: Ils sautent une ligne et ajoutent une phrase (pas tous la même). +2️⃣ Ils sautent une ligne et ajoutent une phrase (pas tous la même). -:three: Valider les résultats (`git add .` et `commit`) et faire un `push` +3️⃣ Valider les résultats (`git add .` et `commit`) et faire un `push` -:four: La personne la plus rapide n'a, normalement, rencontré aucune difficulté (elle peut s'arrêter temporairement pour regarder ce qui va se passer chez les voisins). Les autres voient leur `push` refusé et doivent faire un `pull`. +4️⃣ La personne la plus rapide n'a, normalement, rencontré aucune difficulté (elle peut s'arrêter temporairement pour regarder ce qui va se passer chez les voisins). Les autres voient leur `push` refusé et doivent faire un `pull`. -:boom: Il y a conflit, ce qui doit être signalé par un message du type: +💥 Il y a conflit, ce qui doit être signalé par un message du type: ~~~shell Auto-merging XXXXXX @@ -1186,9 +1185,9 @@ CONFLICT (content): Merge conflict in XXXXXX.md Automatic merge failed; fix conflicts and then commit the result. ~~~ -:five: Etudier le résultat de `git status` +5️⃣ Etudier le résultat de `git status` -:six: Si vous ouvrez les fichiers incriminés, vous devriez voir des balises du type +6️⃣ Si vous ouvrez les fichiers incriminés, vous devriez voir des balises du type ```{python} #| output: asis @@ -1206,7 +1205,7 @@ totally different content to merge later ) ``` -:seven: Corriger à la main les fichiers en choisissant, pour chaque ligne, la version qui vous convient et en retirant les balises. Valider en faisant: +7️⃣ Corriger à la main les fichiers en choisissant, pour chaque ligne, la version qui vous convient et en retirant les balises. Valider en faisant: ~~~shell git add . && git commit -m "Résolution du conflit par XXXX" @@ -1214,7 +1213,7 @@ git add . && git commit -m "Résolution du conflit par XXXX" Remplacer XXXX par votre nom. La balise `&&` permet d'enchaîner, en une seule ligne de code, les deux commandes. -:eight: Faire un push. Pour la dernière personne, refaire les opérations 4 à 8 +8️⃣ Faire un push. Pour la dernière personne, refaire les opérations 4 à 8 ```{=html} @@ -1230,21 +1229,21 @@ Remplacer XXXX par votre nom. La balise `&&` permet d'enchaîner, en une seule l

Exercice 11 : Gestion des branches

``` -:one: Le mainteneur va contribuer directement dans `main` et ne crée pas de branche. Chaque développeur crée une branche, en local nommée `contrib-XXXXX` où `XXXXX` est le prénom: +1️⃣ Le mainteneur va contribuer directement dans `main` et ne crée pas de branche. Chaque développeur crée une branche, en local nommée `contrib-XXXXX` où `XXXXX` est le prénom: ~~~shell git checkout -b contrib-XXXXX ~~~ -:two: Chaque membre du groupe crée un fichier `README.md` où il écrit une phrase sujet-verbe-complément. Le mainteneur est le seul à ajouter un titre dans le README (qu'il commit dans main). +2️⃣ Chaque membre du groupe crée un fichier `README.md` où il écrit une phrase sujet-verbe-complément. Le mainteneur est le seul à ajouter un titre dans le README (qu'il commit dans main). -:three: Chacun push le produit de son subconscient sur le dépôt. +3️⃣ Chacun push le produit de son subconscient sur le dépôt. -:four: Les développeurs ouvrent, chacun, une `pull request` sur `Github` de leur branche vers `main`. Ils lui donnent un titre explicite. +4️⃣ Les développeurs ouvrent, chacun, une `pull request` sur `Github` de leur branche vers `main`. Ils lui donnent un titre explicite. -:five: Dans la discussion de chaque `pull request`, le mainteneur demande au développeur d'intégrer le titre qu'il a écrit. +5️⃣ Dans la discussion de chaque `pull request`, le mainteneur demande au développeur d'intégrer le titre qu'il a écrit. -:six: Chaque développeur, en local, intègre cette modification en faisant +6️⃣ Chaque développeur, en local, intègre cette modification en faisant ```shell @@ -1255,11 +1254,11 @@ git merge main Régler le conflit et valider (`add` et `commit`). Pousser le résultat. Le mainteneur choisit une des `pull request` et la valide avec l'option `squash commits`. Vérifier sur la page d'accueil le résultat. -:seven: L'auteur (si 2 développeurs) ou les deux auteurs (si 3 développeurs) de la `pull request` non validée doivent à nouveau répéter l'opération 6. +7️⃣ L'auteur (si 2 développeurs) ou les deux auteurs (si 3 développeurs) de la `pull request` non validée doivent à nouveau répéter l'opération 6. -:eight: Une fois le conflit de version réglé et poussé, le mainteneur valide la `pull request` selon la même procédure que précédemment. +8️⃣ Une fois le conflit de version réglé et poussé, le mainteneur valide la `pull request` selon la même procédure que précédemment. -:nine: Vérifier l'arborescence du dépôt dans `Insights > Network`. Votre arbre doit avoir une forme caractéristique de ce qu'on appelle le `Github flow`: +9️⃣ Vérifier l'arborescence du dépôt dans `Insights > Network`. Votre arbre doit avoir une forme caractéristique de ce qu'on appelle le `Github flow`: ![](https://linogaliana.gitlab.io/collaboratif/pics/03_git/flow4_discuss.png) ```{=html} diff --git a/content/git/introgit.qmd b/content/git/introgit.qmd index 51a05ffe8..6534823dd 100644 --- a/content/git/introgit.qmd +++ b/content/git/introgit.qmd @@ -136,10 +136,10 @@ permet aussi de "travailler en équipe avec soi-même" car il permet de retrouve Le fonctionnement de la gestion de version, reposant sur l'archivage structuré des modifications et les commentaires les accompagnant, renforce la qualité des programmes informatiques. Ils sont plus documentés, plus riches et mieux structurés. C'est pour cette raison que le contrôle de version ne doit pas être considéré comme un outil réservé à des développeurs : toute personne travaillant sur des programmes informatiques, gagne à utiliser du contrôle de version. -Les services d'intégration continue permettent de faire des tests automatiques +Les services d'*intégration continue* permettent de faire des tests automatiques de programmes informatiques, notamment de packages, qui renforcent la replicabilité des programmes. Mettre en place des méthodes de travail fondées -sur l'intégration continue rend les programmes plus robustes en forçant +sur l'*intégration continue* rend les programmes plus robustes en forçant ceux-ci à tourner sur des machines autres que celles du développeur du code. @@ -155,18 +155,15 @@ en continu permettent ainsi de : * rendre visible la qualité d'un projet avec des services de *code coverage*, de tests automatiques ou d'environnements intégrés de travail (binder, etc.) qu'on rend généralement visible au moyen de badges -(exemple ici {{< githubrepo >}}) - +(exemple [ici](https://github.com/linogaliana/python-datascientist#python-pour-la-data-science-)) # Comment faire du contrôle de version ? Il existe plusieurs manières d'utiliser le contrôle de version : * en ligne de commande, via [Git Bash](https://gitforwindows.org/), par exemple ; -* avec une interface graphique spécialisée, par exemple [Tortoise Git](https://tortoisegit.org/) ou [GitHub Desktop](https://desktop.github.com/) ; -* avec un logiciel de développement : la plupart des logiciels de développement ([RStudio](https://www.book.utilitr.org/git.html) pour `R`, [PyCharm](https://www.jetbrains.com/help/pycharm/using-git-integration.html), [jupyter](https://annefou.github.io/jupyter_publish/02-git/index.html) ou encore -[Visual Studio (extension GitLens)](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) -pour `Python`, proposent tous des modules graphiques facilitant l'usage de `Git`. +* avec une interface graphique spécialisée, par exemple [GitHub Desktop](https://desktop.github.com/), [Tortoise Git](https://tortoisegit.org/) ou [Sublime Merge](https://www.sublimemerge.com/) ; +* avec un logiciel de développement : la plupart des logiciels de développement proposent des modules graphiques facilitant l'usage de `Git`. [RStudio](https://www.book.utilitr.org/git.html) pour `R`, [PyCharm](https://www.jetbrains.com/help/pycharm/using-git-integration.html), [jupyter](https://annefou.github.io/jupyter_publish/02-git/index.html) ou encore [Visual Studio Code](https://code.visualstudio.com/docs/sourcecontrol/overview) pour `Python` qui peut être couplé par diverses extensions utiles ([git-graph](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph), [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens), etc.). `Git` a été conçu, initialement pour la ligne de commande. Il existe @@ -210,7 +207,6 @@ une **forge logicielle** (`Github` ou `Gitlab`) et sert à centraliser la versi collective d'un projet. Les copies locales sont des copies de travail qu'on utilise pour faire évoluer un projet : -![](https://www.book.utilitr.org/pics/git/gitlab.png) Il est tout à fait possible de faire du contrôle de version sans mettre en place de dépôt distant. Cependant, @@ -238,7 +234,7 @@ la mise en cohérence) avec le dépôt commun alors que la première manipulation `commit` correspond à la modification des fichiers faite pour faire évoluer un projet. -De manière plus précise, il y a trois étapes avant d'envoyer les modifications validées (`commit`) au dépôt. Elles se définissent en fonction des commandes qui permet de les appliquer quand Git est utilisé en ligne de commandes : +De manière plus précise, il y a trois étapes avant d'envoyer les modifications validées (`commit`) au dépôt. Elles se définissent en fonction des commandes qui permettent de les appliquer quand Git est utilisé en ligne de commandes : * `diff` : inspection des modifications. Cela permet de comparer les fichiers modifiés et de distinguer les fichiers ajoutés ou supprimés * `staging area` : sélection des modifications.