Skip to content
Snippets Groups Projects

Update README.md

Merged Update README.md
racaillou-master-patch-87197 into master
Merged Kerrian Le Caillec requested to merge racaillou-master-patch-87197 into master
Compare
and
1 file
+ 34
− 24
Compare changes
  • Side-by-side
  • Inline
README.md
+ 34
− 24
# TP: introduction à Git
Bienvenu à toi, lecteur ! Ce TP a pour objectif de t'aider à prendre en main Git en mettant les mains dans le cambouis. Mais surtout pas de panique si tu n'as jamais utilisé Git ! Ce TP reprend tout de plus le début, mais a été pensé pour faire suite à une (courte) présentation théorique. Je te conseille de consulter les slides disponibles [ici](https://viarezo.fr/formations) avant de te lancer dans ce TP.
Bienvenu à toi, lecteur ! Ce TP a pour objectif de t'aider à prendre en main Git en mettant les mains dans le cambouis. Mais surtout pas de panique si tu n'as jamais utilisé Git ! Ce TP reprend tout de plus le début, mais a été pensé pour faire suite à une présentation théorique.
## Prérequis
Pour pouvoir faire ce TD, il te faudra le logiciel Git installé sur ton ordinateur :
* Si tu es sous Linux ou Mac, git est normalement déjà installé.
* Si tu es sous Windows, je te conseille d'installer [GitBash](https://gitforwindows.org/). Tu peux aussi utiliser [WSL2](https://www.thomasmaurer.ch/2019/06/install-wsl-2-on-windows-10/) qui est plus complet mais un peu plus compliqué à installer.
* Si tu es sous Windows, je te conseille d'installer [GitBash](https://gitforwindows.org/).
Ce TP va aussi utiliser l'éditeur de code [VSCode](https://code.visualstudio.com/). Je te conseille de l'utiliser aussi pour plus de clarté mais tu peux utiliser un autre éditeur de code.
@@ -29,17 +29,17 @@ Git sait maintenant qui tu es et le nom choisi sera associé aux modifications q
### Paramètre de connexion au serveur Gitlab
Lorsque l'on utilise Git, le code est stocké sur un serveur distant, le Gitlab. Dans ce TP, tu utiliseras le Gitlab de ViaRézo, accessible à [cette adresse](https://gitlab.viarezo.fr).
Lorsque l'on utilise Git, le code est stocké sur un serveur distant, le [GitLab](https://gitlab.viarezo.fr).
Dans le cas où le projet Gitlab n'est pas public, il faudra s'authentifier pour pouvoir synchroniser les fichiers entre le serveur Gitlab et ton ordinateur. Gitlab propose deux manières de s'authentifier :
* L'indentification par nom d'utilisateur/mot de passe. Par défaut, Gitlab demandera un identifiant (de la forme 2016vandammejc) et un mot de passe lorsque ce sera nécessaire.
* Il n'est pas très confortable de devoir entrer à chaque fois identifiant et mot de passe. Il existe alors une deuxième méthode pour s'authentifier : le protocole ssh. Si cette solution t'intéresse, je t'invite à regarder l'encadré suivant pour la mettre en place.
* L'indentification par nom d'utilisateur/mot de passe. Par défaut, Gitlab demandera un identifiant (2022nompr) et un mot de passe lorsque ce sera nécessaire, l'accès au répo par cette méthode a été bloquée sur ce GitLab (c'est pas une grande perte). De fait, on passe par la seconde méthode.
* Il existe alors une deuxième méthode pour s'authentifier : le protocole ssh. Les étapes pour s'identifier sont détaillées en-dessous.
---
**Optionnel : Paramétrer l'authentification par clé ssh**
### Paramétrer l'authentification par clé ssh
* Crée une clé ssh en suivant par exemple [ce tutoriel](https://inchoo.net/dev-talk/how-to-generate-ssh-keys-for-git-authorization/).
* Ajoute ta clé dans ton profil Gitlab en te rendant dans `Settings` (disponibles après avoir cliqué sur le logo en haut à droite) puis `SSH Keys`.
* Ajoute ta clé dans ton profil Gitlab en te rendant dans `Edit profile` (disponibles après avoir cliqué sur le logo en haut à droite) puis `SSH Keys`.
* Tu pourras maintenant t'authentifier via SSH.
![ajout d'une clé ssh dans les paramètres](photos/ssh_key.png)
@@ -68,11 +68,11 @@ C'est l'heure de créer ton premier fork. Rendez-vous sur [ce projet Gitlab](htt
* Après un temps de chargement, ton projet personnel apparaît. Tu peux vérifier que c'est bien le tiens en regardant dans l'url. Il devrait y avoir ton nom d'utilisateur.
* Comme tu viens de faire un fork, il est encore possible de faire des modifications sur ton projet et sur le projet original. Il faut donc désactiver cette option pour avoir un projet indépendant. Clique sur ***Settings*** dans la barre de gauche puis dans la sous-catégorie ***Advanced***, clique ***Remove fork relationship***. Confirme l'opération en entrant le nom du projet.
Félicitations, tu as maintenant un projet indépendant dans lequel tu feras la suite du TP !! Il ne reste plus qu'à récupérer une copie local (c'est à dire sur ton ordinateur) des fichiers.
Il ne reste plus qu'à récupérer une copie local (c'est à dire sur ton ordinateur) des fichiers.
### Clone du repo
* Sur la page d'accueil de ton projet, clique sur le bouton ***clone*** et copie le lien pour cloner avec `HTTPS` (sauf si tu suivi l'étape pour paramétrer l'authentification par `SSH`).
* Sur la page d'accueil de ton projet, clique sur le bouton ***clone*** et copie le lien pour cloner avec `SSH` (cf. l'étape du dessus s'il existe des problèmes de permissions).
* Ouvre un GitBash (Windows) ou un terminal (Mac et Linux) à l'endroit où tu veux enregistrer les fichiers du repo git.
* Entre la commande `git clone <lien copié>`. Git va alors créer un dossier et téléchargement le contenu du projet sur le serveur. Tu as maintenant une copie locale du code !
@@ -93,17 +93,15 @@ Maintenant que tu as une copie locale des fichiers, tu peux commencer à les éd
Dans un repo git, l'édition des fichiers se fait comme dans un dossier classique. Mais cette modification en local doit ensuite être synchronisée avec le serveur.
Voici-ci dessous une ligne moche et inutile. Sauras-tu la supprimer ? (Tu peux t'aider de la slide de conclusion pour te guider)
Voici-ci dessous une ligne moche et inutile. Sauras-tu la supprimer ? (Le bilan des actions comme décrit sur le diapo te sera utile si tu bloques)
**Cette ligne est moche est inutile, supprime là !**
Bravo pour avoir réussi à supprimer la ligne ! Il existe aussi un module git intégré à VSCode, je t'encourage à essayer de l'utiliser pour supprimer la deuxième ligne moche et inutile ci-dessous.
Il existe aussi un module git intégré à VSCode, je t'encourage à essayer de l'utiliser pour supprimer la deuxième ligne moche et inutile ci-dessous.
**Cette ligne est aussi moche et inutile, supprime là !**
Tu peux vérifier que les lignes du fichier ont bien disparu du repo distant via l'interface web de Gitlab. Attention à bien regarder sur ta copie personnelle du projet et pas sur le projet originel.
Merci d'avoir pris le temps de nettoyer ce fichier en enlevant ces lignes en trop ! Tu peux passer à la mission suivante.
Tu peux vérifier que les lignes du fichier ont bien disparu du repo distant via l'interface web de Gitlab sur ta copie personnelle.
### Mission 2 : Ajouter un fichier
@@ -118,7 +116,7 @@ L'extension de fichier `.md` signifie *Markdown*. Ce format permet de faire un p
Une fois le fichier créé, n'oublie pas de créer un commit et de le synchroniser avec le serveur Gitlab !
### Mission 3 : Supprimer un fichier
### Mission 3 : Supprimer un fichier (facultatif)
Dernière mission pour la route, il y a dans le repo un fichier nommé `fichier_inutile`. Sauras-tu le supprimer du repo Gitlab ?
@@ -126,13 +124,13 @@ Tu peux vérifier que le fichier a bien disparu du repo distant via l'interface
Les quelques commandes que tu viens d'utiliser (`git status`, `git add`, `git commit`, `git pull`, `git push`) sont les commandes que tu utiliseras 95% du temps.
Je t'invite à aller voir le graphe du repo depuis l'interface web disponible dans ***Repository > Graph***. Tu peux y retrouver l'historique de tes commits. Note bien l'importance du message de commit clair qui permet de te souvenir de ce qui a changé entre chaque commit ! On voit bien ici que Git permet de versionner le code facilement. Mais qu'en est-il de la collaboration ?
Je t'invite à aller voir le graphe du repo depuis l'interface web disponible dans ***Repository > Graph***. Tu peux y retrouver l'historique de tes commits. Note bien l'importance du message de commit clair qui permet de te souvenir de ce qui a changé entre chaque commit ! Mais qu'en est-il de la collaboration ?
![example de graphe linéaire](photos/commits_lineaires.png)
## Partie 3 : Collaboration, branches et merge requests
Pour pouvoir travailler séparément sur des features différentes on utilise des branches, cette fonctionnalité est particulièrement pratique pour faire avancer en même temps plusieurs versions du même code qui implémentent des fonctionnalités différentes. D'autant plus qu'on ne veut garder sur la branche master que du code 100% fonctionnel.
Pour pouvoir travailler séparément sur des features différentes on utilise des branches, cette fonctionnalité est particulièrement pratique pour faire avancer en même temps plusieurs versions du même code qui implémentent des fonctionnalités différentes.
### Mission 1 : Créer une branche
@@ -148,13 +146,13 @@ Il faut installer le module emoji avec la commande `python3 -m pip install -r re
---
* Complète le dictionnaire `wordToEmoji` avec quelques emojis supportés. Tu peux trouver la liste [ici](https://www.webfx.com/tools/emoji-cheat-sheet/).
* Si tu as exécuté le fichier python `code/main.py`, tu as peut être pu remarquer l'apparition du dossier `code/__pycache__`. Ces fichiers ne sont pas intéressants à gitter (car pas nécessaires à l'exécution du fichier `code/main.py`). Il faut donc ajouter un gitignore pour les ignorer : ***crée un fichier nommé*** `.gitignore` ***à la racine du repo*** et ajoute les dossiers et fichiers que tu veux ignorer (ici: `code.__pycache__`).
* Commit et push tes changements. Remarque que le dossier `code/__pycacche__` n'a pas été synchronisé.
* Si tu as exécuté le fichier python `code/main.py`, tu as peut être pu remarquer l'apparition du dossier `code/__pycache__`. Ces fichiers ne sont pas intéressants à gitter (car pas nécessaires à l'exécution du fichier `code/main.py`). Il faut donc ajouter un `gitignore` pour les ignorer : ***crée un fichier nommé*** `.gitignore` ***à la racine du repo*** et ajoute les dossiers et fichiers que tu veux ignorer (ici: `code.__pycache__`).
* Commit et push tes changements. Remarque que le dossier `code/__pycache__` n'a pas été synchronisé.
---
**Je n'arrive pas à push les changements**
Comme tu as créé une branche en local, Git n'arrive pas à trouver la branche correspondant sur le serveur. Il faut donc la créer avce une option spéciale. **Pas de panique ! Git te donne la commande à copier-coller dans le message d'erreur (les erreurs avec Git sont souvent assez explicite pense bien à les lire en cas de problème).**
Comme tu as créé une branche en local, Git n'arrive pas à trouver la branche correspondante sur le serveur. Il faut donc la créer avce une option spéciale. **Git te donne la commande à copier-coller dans le message d'erreur (les erreurs avec Git sont souvent assez explicite pense bien à les lire en cas de problème).**
---
@@ -163,9 +161,9 @@ Comme tu as créé une branche en local, Git n'arrive pas à trouver la branche
Il est temps de rajouter ce changement de code dans la branche principale !
Sur l'interface Web du Gitlab, il y a un menu déroulant sous le nombre de commit permettant de sélectionner une branche. Choisis la branche que tu viens de push. Tu peux y voir tes changements mais ils disparaissent si tu repasses sur la branche master. L'objectif est d'intégrer les changements à master. Il faut pour cela créer une **merge request**.
Sur l'interface Web du Gitlab, il y a un menu déroulant sous le nombre de commits permettant de sélectionner une branche. Choisis la branche que tu viens de push. Tu peux y voir tes changements mais ils disparaissent si tu repasses sur la branche master. L'objectif est d'intégrer les changements à master. Il faut pour cela créer une **merge request**.
* À gauche, clique sur le 4ème icon ***Merge Requests*** puis clique sur ***New merge request***.
* À gauche, clique sur l'icone ***Merge Requests*** puis clique sur ***New merge request***.
* Choisis ta branche en tant que ***Source branch*** et master en tant que ***Target branch***. Puis clique sur ***Compare branches and continue***
* Remplis un titre et une description. Tu peux aussi ajouter des labels personnalisés pour catégoriser facilement les merge requests.
* Tout en bas tu trouves 2 onglets : ***Commits*** et ***Changes***. Ils te permettent de voir l'historique et les changements entre les 2 branches.
@@ -198,7 +196,19 @@ Une fois la merge request créée. Tu peux voir sur le résumé de la merge requ
Tu peux maintenant revenir dans l'onglet ***Merge requests***.
Comme il y a déjà eu des changements sur le même fichier, il faut **rebase** la branche sur master. Pas de panique, il suffit de cliquer sur le bouton ***Rebase*** sur la page de la merge request. Une fois le rebase effectué, tu peux review le code et merge. Encore, une fois, n'oublie pas de regarder le graphe pour bien visualiser les opérations que tu viens de faire.
Comme il y a déjà eu des changements sur le même fichier, il faut **rebase** la branche sur master. Pas de panique, il suffit de cliquer sur le bouton ***Rebase*** sur la page de la merge request.
---
### Cherry-pick (facultatif)
Si tu retournes encore une fois dans l'onglet ***Repository > Branches***, tu verras qu'il existe une branche nommée `branche-avec-truc-style`. Elle apporte des améliorations au code. Notre objectif est de ramener l'unique commit de cette branche sur la branche `branche-a-rebase`.
On va donc utiliser `git cherry-pick <nom du commit>`, depuis la branche `branche-a-rebase`.
Tu auras besoin du commit SHA, pour ce faire, sur le projet Gitlab, va dans ***Repository > Commits***, puis choisis la branche `branche-avec-truc-style`, il apparaitra à droite, tu peux directement le copier avec le bouton juxtaposé.
---
Une fois le rebase (et le cherry-pick) effectué(s), tu peux review le code et merge. Encore, une fois, n'oublie pas de regarder le graphe pour bien visualiser les opérations que tu viens de faire.
## Conclusion
@@ -206,4 +216,4 @@ Comme il y a déjà eu des changements sur le même fichier, il faut **rebase**
Enfin, dernier conseil : Git réserve parfois quelques situations un peu complexes, notamment lorsque des conflits se créent entre deux modifications. Il faut alors les résoudre à la main (heureusement VSCode aide en affichant les conflits). Mais surtout pas de panique ! Comme dans beaucoup de messages d'erreur, Git donne la démarche à suivre pour résoudre l'erreur dans le message d'erreur. **Il faut donc bien faire attention à ce que Git te communique !**
Sur ce j'espère que tu as apprécié ce TP, il ne me reste plus qu'à te souhaiter une bonne utilisation de Git en Coding Weeks, pour le site de ton asso, ou dans à ViaRézo :wink: !
Sur ce j'espère que tu as apprécié ce TP, il ne me reste plus qu'à te souhaiter une bonne utilisation de Git en Coding Weeks, pour le site de ton asso, ou à ViaRézo :wink: !