1---
  2title: Organiser le développement en équipe avec git
  3theme: ./_themes/5ika.css
  4verticalSeparator: <!--v-->
  5revealOptions:
  6  transition: 'fade'
  7---
  8
  9# **Organiser le développement en équipe avec git**
 10
 11À la fin de la master class, les participants seront en mesure de :
 12- Comprendre comment et pourquoi utiliser un modèle de branche git
 13- Utiliser les outils de gestion de projet de GitHub liés à la base de code
 14- Effectuer des tâches simples avec Docker
 15
 16---
 17
 18# Tim Izzo
 19
 20- Ingénieur IT et développeur
 21- Travail chez [Octree](https://octree.ch) et en tant qu'indépendant
 22- Enseigne les réseaux et la sécurité IT
 23- Approche minimaliste et écologique du développement
 24
 25🦌 [5ika.ch](https://5ika.ch)<br/>
 26✉️ [tim@5ika.ch](mailto:tim@5ika.ch)<br/>
 27👔 [LinkedIn](https://www.linkedin.com/in/tim-izzo/)
 28
 29---
 30
 31Qui êtes-vous ?
 32
 33---
 34
 35**Vous êtes membre d'une équipe de développement devant développer un site web.**
 36
 37Vous avez besoin de:
 38
 391. Organiser le développement à plusieurs pour ne pas vous marcher sur les pieds
 402. Tester votre site web pendant le développement pour s'assurer que tout fonctionne à chaque étape
 413. Déployer votre site web en production une fois qu'une version est prête
 42
 43---
 44
 45Pour comprendre les différentes étapes, nous allons toutes et tous collaborer
 46sur une même base de projet:
 47
 48https://github.com/5ika/Deer
 49
 50<center>
 51
 52![Capture d'écran du site](img/Sika%20deer.png)
 53
 54</center>
 55
 56---
 57
 58# Créer un projet git
 59
 60```bash
 61# Je me déplace dans le dossier qui contient mon site
 62cd /home/tim/projets/Deer
 63# J'initialise git pour ce dossier
 64git init
 65# J'ajoute toutes les modifications à la zone de staging
 66git add -A
 67# Je crée un premier commit
 68git commit -m "🎉 First commit"
 69```
 70
 71> Pas besoin de réaliser cette étape de votre côté.
 72> Elle est à faire une seule fois par la personne qui initialise le projet.
 73
 74---
 75
 76# Synchroniser le projet avec GitHub
 77
 78Dans un premier temps, je crée un nouveau projet sur GitHub
 79puis je connecte mon dépôt local avec le dépôt distant.
 80
 81```bash
 82# Je configure un dépôt distant (en utilisant l'adresse SSH plutôt que HTTP)
 83git remote add origin git@github.com:5ika/Deer.git
 84# Je push la branche locale 'main' sur le dépôt distant
 85git push -u origin main
 86```
 87
 88Le dépôt local correspond au dossier sur ma machine tandis que le dépôt distant correspond au projet GitHub.
 89
 90> Pas besoin de réaliser cette étape de votre côté.
 91> Elle est à faire une seule fois par la personne qui initialise le projet.
 92
 93---
 94
 95# Récupérer le projet sur sa machine
 96
 97🫵 **À vous !**
 98
 99En tant que collaborateur/trice, vous pouvez récupérer le code du site
100sur votre machine en le *clonant*.
101
102```bash
103# Je me déplace sur ma machine à l'endroit où je place mes projets
104cd /home/tim/projets
105# Je récupère le projet commun depuis GitHub
106git clone git@github.com:5ika/Deer.git
107# Je me déplace dans le nouveau dossier contenant le code
108cd Deer
109```
110
111---
112
113# Exploration
114
115Les commandes suivantes nous permettent de constater ce qui se passe:
116
117```bash
118# Lister les fichiers et dossiers présents dans le projet
119ls -la
120# Voir les commits déjà faits sur le projet
121git log
122# Voir les modifications pas encore dans un commit
123git status
124```
125
126Ces commandes ne modifient rien. Elles servent juste à voir.
127On peut en abuser 😁
128
129---
130
131Nous avons désormais toutes et tous une copie du même projet
132sur notre machine avec un seul commit: celui que j'ai fait.
133
134Maintenant, **comment ajouter du nouveau code dans notre projet ?**
135
136Que se passe-t-il si chacun.e fait un commit et le push sur GitHub ? 🤔
137
138---
139
140<center>
141
142![](img/git_parallel.png)
143
144</center>
145
146---
147
148# Les branches
149
150Comme les commits forment une suite ordonnée, on appelle un ensemble de commits une **branche**.
151
152Le dernier commit correspond à la version la plus actuelle de notre code.
153On nomme ce commit le *HEAD*. C’est le bout de la branche.
154
155![](img/git_branch.png)
156
157Par défaut, quand rien n'est précisé, les commits sont automatiquement ajoutés à la branche nommée *main*.
158
159---
160
161# Les branches
162
163Il est possible de créer plusieurs branches pour paralléliser le travail sur une même base de code.
164
165![](img/git_branches.png)
166
167---
168
169# Créer une nouvelle branche
170
171La commande suivante crée une nouvelle branche `my-new-branch` à partir du dernier
172commit de la branche `main`.
173
174```bash
175git checkout -b my-new-branch
176```
177
178Tous les commits qui seront faits ensuite seront placés sur cette nouvelle branche.
179
180---
181
182# Se déplacer entre les branches
183
184Si on retire le `-b` dans la commande, on indique qu'on souhaite juste se déplacer
185d'une branche à une autre.
186
187```bash
188# Je me trouve sur la branche `my-new-branch`
189git checkout main
190# Je me trouve maintenant sur la branche `main`
191git checkout my-new-branch
192# Je me trouve sur la branche `my-new-branch`
193git checkout one-more-branch # Erreur car la branche `one-more-branch` n'existe pas
194git checkout -b  one-more-branch
195# Je me trouve sur la branche `one-more-branch`
196```
197
198---
199
200Pour voir sur quelle branche on se trouve, on peut utiliser la commande suivante:
201
202```
203git branch
204```
205
206Cela retourne par exemple:
207
208```bash
209* main
210  my-new-branch
211  one-more-branch
212```
213
214J'ai donc 3 branches actuellement et je me trouve sur la branche *main* (celle indiquée par un `*`).
215
216---
217
218# Supprimer une branche
219
220Pour supprimer une branche locale:
221
222```bash
223# D'abord, je me déplace sur une branche autre
224git checkout main
225# Ensuite, je retire la branche
226git branch -d one-more-branch
227# On peut vérifier avec
228git branch
229```
230
231---
232
233# Pusher une nouvelle branche
234
235Quand on crée un nouvelle branche, elle n'existe que localement dans un premier temps.
236Comme un commit, il faut la *pusher* sur GitHub pour qu'elle soit visible par les autres devs.
237
238```bash
239git push -u origin my-new-branch
240```
241
242Ici, on indique que l'on veut pusher la branche `my-new-branch` vers le dépôt distant
243nommé `origin`.
244
245`origin` est un alias correspondant à notre projet commun sur GitHub.
246
247---
248
249🫵 À vous maintenant de **créer une nouvelle branche** à partir de la branche *main* et de la **pusher sur GitHub**.
250
251Pour qu'on puisse s'y retrouver, nommer cette branche avec votre prénom, sans accent, sans majuscule et sans espace.
252
253Il faut donc entrer deux commandes que l'on a vu dans les slides précédentes.
254
255> Vous pouvez constater sur GitHub que votre branche s'y trouve bien pour vérifier.
256
257---
258
259# Faire un commit
260
261Désormais, nous avons toutes et tous une branche à notre nom sur notre machine et sur GitHub.
262
263Pour le moment, cette branche est identique à la branche *main* car nous n'avons pas fait de
264commit dessus.
265
266🫵 De votre côté:
2671. Modifiez un petit peu le CSS ou le HTML du projet. Par exemple, changer la couleur de la tête du cerf ou un autre élément.
2682. Créez un nouveau commit avec votre modification (sur votre branche, pas sur *main*)
2693. Pusher ce commit sur GitHub
2704. Constater sur GitHub que votre commit est présent **au niveau de votre branche**
271
272---
273
274# Faire un commit
275
276<center>
277
278![](img/git_steps.png)
279
280</center>
281
282---
283
284# Code review: C'est quoi ?
285
286Dans une équipe de développement, pour assurer une bonne **qualité de code**
287et éviter que chaque dev porte seul.e la responsabilité du code qu'il ou elle produit,
288il est courant de faire du *code review*.
289
290Cela consiste à faire relire son code par une autre personne de l'équipe afin de
291s'assure que le code est bien fait, les choix sont bons, les règles de l'équipe
292sont respectées et que le cahier des charges est remplie.
293
294> Dans certains projets, il y a une personne spécifique qui s'occupe de faire
295> tout le code review. On la nomme *Mainteneur/euse"*.
296
297---
298
299# Code review: C'est quand ?
300
301En tant que dev, nous faisons généralement du code review au moment où nous souhaitons
302que les modifications faites sur notre branche soient ajoutées sur la branche principale
303(*main*).
304
305Pour ce faire, nous créons une **Pull Request** sur GitHub. Une Pull Request est la
306manière de demander à l'équipe de dev de **merger** notre branche dans la branche principale.
307
308Cette fonctionnalité permet à des centaines de devs de collaborer sur un projet, notamment
309dans le monde de l'Open-Source.
310
311=> [Exemple avec le projet Caroster](https://github.com/octree-gva/caroster)
312
313---
314
315# Créer une Pull Request
316
317On crée une Pull Request directement sur l'interface de GitHub, dans le menu *Pull Requests* du projet.
318
319On nous demande d'indiquer deux branches:
320- Un branche **source** qui correspond à la branche que l'on souhaite merger.
321- Une branche **destination** qui correspond à la branche qui doit recevoir les changements. Généralement, c'est *main*.
322
323🫵 **À vous** de créer une Pull Requests au niveau du projet GitHub commun pour demander que l'on merge
324votre branche dans la branche *main*.
325
326Note: Repasser sur quelques Pull Requests faites pour montrer la page d'une Pull Request et le système de commentaires
327
328---
329
330Imaginez la situation suivante :
331
3321. Alice a modifié la couleur de la tête du cerf ([ligne 101 de style.css](https://github.com/5ika/Deer/commit/be7f148d518c61fc77d18eab2154dcf6443be185#diff-b78be019f1dc6d57753ea900c3805b114cd53ab7c0db836cc081836df1b99b7aR101)) dans sa branche
3332. Bob a également modifié la couleur de la tête à la même ligne dans sa propre branche
3343. Les deux devs font une Pull Requests pour demander que l'on merge leur branche dans *main*
335
336Est-ce que vous voyez un problème ? 🤔
337
338---
339
340# Conflits
341
342Cette situation s'appelle un **conflit**:
343
344Comme Alice et Bob travaillent en même temps, ils ne savent pas ce que l'autre fait.
345Quand on demande à git de merger leur travail, le programme ne sait pas comment faire car la machine
346est incapable de définir lequel des deux à le + raison.
347
348Il est donc nécessaire de passer par une action humaine pour résoudre cela.
349
3501. On merge une première branche dans *main* (disons, celle d'Alice). GitHub nous indique un conflit au niveau de la branche de Bob.
3512. Bob merge *main* (avec les modifications d'Alice) dans sa branche à lui.
3523. Bob résout les conflits entre l'état actuel de *main* et ses modifications puis push les corrections.
3534. On merge la deuxième branche dans *main*
354
355---
356
357# Éviter les conflits
358
359Les conflits git ne sont pas désirables et en tant que dev, on cherche à en avoir le moins souvent possible.
360Pour cela, quelques règles à respecter:
361
362- Pullez souvent pour mettre à jour votre copie locale avec ce qu'il y a dans le dépôt commun
363- Il est préférable de faire beaucoup de petits commits avec peu de modifications que des commits avec énormément de modification: plus facile à débugger, à lire, à commenter et à revenir en arrière
364- Avoir une bonne gestion de projet pour éviter que deux personnes de l'équipe travaillent sur la même chose en même temps
365
366---
367
368# Gestion de projet avec GitHub
369
370Suivant l'approche Agile / SCRUM, GitHub propose des outils au niveau d'un projet pour organiser le projet autour du code.
371
372Il y a notamment deux outils très utiles :
373
374- Les **Issues** qui permettent de lister des fonctionnalités à développer ou déclarer des bugs/problèmes
375- Les "**Projects**" qui permettent d'organiser les issues
376
377---
378
379# Issues
380
381Les issues sont très utilisées. Très grossièrement, cela correspond à la liste des tâches de développement à faire
382pour faire avancer un projet.
383
384Leur utilisation est très flexible et chaque projet s'organise comme il le souhaite.
385En exemple dans ce cours, nous allons voir une utilisation compatible avec une approche Agile/SCRUM.
386
387---
388
389# Étape 1: Créer les issues
390
391En début de projet, on crée une issue pour chaque fonctionnalité qu'on souhaite implémenter
392dans l'itération Agile à venir.
393
394🫵 Par équipe de 2, créez une issue décrivant une fonctionnalité originale à faire.
395Évitez d'avoir la même qu'un autre binôme.
396
397> Pas besoin de voir trop compliqué. Cela doit pouvoir être fait rapidement, en quelques lignes de CSS, HTML ou JS.
398
399Une fois l'issue créée:
400- Assignez les deux membres du binôme au niveau du champ *Assignees*
401- Assignez l'issue au *projet* "Développement du site web"
402- Au niveau du [projet Développement du site web](https://github.com/users/5ika/projects/1), glissez votre issue dans la colonne "In Progress"
403
404Note: Faire un exemple en //
405
406---
407
408# Étape 2: Créer une branche
409
410À chaque fois qu'on implémente une nouvelle fonctionnalité, décrite dans une issue, on crée une nouvelle branche
411dans le dépôt avec un nom clair. Ces branches qui concernent de nouvelles fonctionnalités s'appellent
412des **feature branches**.
413
414🫵 Créez une branche sur laquelle vous allez prochainement modifier le code pour implémenter la fonctionnalité décrite
415dans votre issue. Vous pouvez donnez un nom clair à la branche. Par exemple `ajout-3e-oeil`.
416
417> Un seul des deux membres du binôme doit faire le travail mais les deux doivent comprendre ce qui est fait.
418
419---
420
421# Étape 3: Développer !
422
423🫵 Sur votre machine, développez la fonctionnalité sur la bonne branche et pushez le ou les commits sur
424GitHub.
425
426---
427
428# Étape 4: Créer une Pull Request
429
430🫵
431
4321. Créer une Pull Request pour merger votre branche dans *main*
4332. Assigner le membre du binôme qui n'a pas fait le développement à la PR (Pull Request)
4343. Sur la page projet "Développement du site web", glissez votre issue dans "In Review"
435
436---
437
438# Étape 5: Code Review
439
440🫵 La personne assignée à la PR peut maintenant relire le code et éventuellement faire des commentaires
441si le travail est incomplet ou incorrect.
442
443Une fois que tout est bon, elle peut *merger* la Pull Request pour l'ajouter à *main*. Puis, on peut
444déplacer l'issue dans la colonne "Done" sur le projet.
445
446> À cette étape, il y aura surement des conflits et des résolutions à faire. Nous allons gérer cela
447> au cas par cas.
448
449---
450
451# Bravo 🎉
452
453Nous avons développé ensemble une nouvelle version du site web.
454
455Le travail pratique d'aujourd'hui n'est pas si loin de la réalité.
456
457En général:
458- La création des issues est faite de manière plus réflechie en impliquant le Product Owner, le client et d'autres
459rôles
460- Le code review est une étape qui prend du temps et qui peut nécessiter plusieurs aller-retours
461
462---
463
464# Liaison entre commits et issues
465
466Quand on crée une issue, il lui est attribué un numéro.
467Par exemple, l'issue https://github.com/5ika/Deer/issues/1 a obtenu le numéro `1`.
468
469Quand on fait un commit, dans le *commit message* on peut ajouter `#1` pour indiquer
470que ce commit est lié à notre issue. GitHub est ensuite capable de comprendre cela
471et de faire des liens sur l'interface.
472
473C'est facultatif mais c'est très utile quand on avance dans un projet afin de
474garder un historique cohérent et de pouvoir s'y retrouver dans le futur.
475
476Note: Faire une démonstration
477
478---
479
480# Bugs 🐛
481
482Les bugs font parties intégrantes du développement.
483Ils peuvent être trouvés par différentes personnes: devs, testeurs, clients, utilisateurs/trices,
484contributeurs/trices,...
485
486Les issues servent également à relever et gérer les bugs: quand une personne rencontre un souci,
487elle peut créer une issue détaillant son bug.
488On peut ensuite gérer un bug comme une feature avec notre gestion de projet.
489
490La modification du code relatif est faite sur une *fix branch* qui sera aussi soumise à
491travers une Pull Request.
492
493Note: Montrer des exemples d'issues bug dans un projet Open-Source sur GitHub
494
495---
496
497![Exemple de mauvaise issue de bug](img/bug_bad.png)
498
499---
500
501# Relever un bug
502
503Quand on crée une issue de bug, il est important d'être le plus clair possible pour
504faciliter la résolution.
505
506Il est important de fournir:
507
508- Une description claire du bug
509- Les étapes permettant de **reproduire** le problème
510- Une description de ce qui est attendu
511- Des captures d'écran ou une vidéo pour montrer
512
513[Exemple de bug dans le projet Strapi](https://github.com/strapi/strapi/issues/16539)
514
515---
516
517Sur un projet git, tout le monde est libre de créer des branches et les nommer comme il ou elle veut.
518Quand on travaille à plusieurs et/ou sur une longue période, cela devient vite chaotique 💥.
519
520![Branches chaos](img/branches_chaos.png)
521
522---
523
524En équipe, il faut donc se mettre d'accord sur une manière de gérer les branches afin
525de rester efficaces.
526
527On appelle cela un **modèle de branche** 🌳
528
529---
530
531Le modèle de branche le plus utilisé est le *Feature Branch Worflow*.
532
533![](https://wac-cdn.atlassian.com/dam/jcr:09308632-38a3-4637-bba2-af2110629d56/07.svg?cdnVersion=1004)
534
535... et c'est celui que nous avons déjà appris précédemment.
536
537C'est le fait d'utiliser une autre branche que la principale pour faire des modifications:
538feature branch, fix branch,...
539
540> Ce modèle est la base des autres modèles, il est donc important de bien le comprendre.
541> [Cette documentation](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow) est
542> particulièrement bien faite pour comprendre (en anglais).
543
544---
545
546# Feature Branch Worfklow
547
5481. Je crée une branche annexe (feature ou fix) dans laquelle je fais mes modifications
5492. Je crée une Pull Request pour demander que l'on merge ma branche dans *main*
5503. Une autre personne vérifie mon code et je l'affine si nécessaire
5514. L'autre personne valide la Pull Request et les commits de ma branche sont ajoutés à *main*
5525. Je supprime ma branche annexe (si ce n'est pas fait automatiquement)
553
554---
555
556# L'ancien modèle 'Gitflow'
557
558![Ancien modèle Gitflow](https://wac-cdn.atlassian.com/dam/jcr:34c86360-8dea-4be4-92f7-6597d4d5bfae/02%20Feature%20branches.svg?cdnVersion=1004)
559
560---
561
562# Et dans les projets Open-Source ?
563
564Dans les projets Open-Source, il n'y a pas une équipe précise qui travaille sur le code car
565tout le monde peut participer et proposer des modifications.
566
567**Mais comment faire pour autoriser tout le monde à modifier le code sans perdre le contrôle de son app ?**
568
569---
570
571# Fork ! 🍴
572
573GitHub nous permet de *forker* des projets.
574
575"Forker" signifie *copier tout le projet et son historique vers son propre espace*.
576
577En forkant un projet, j'obtiens une copie de tout le code de ce projet sur laquelle
578j'ai le droit de faire ce que je veux.
579
580Note: Faire un exemple de fork de Caroster
581
582---
583
584# Forking workflow
585
586Le forking workflow est un modèle de branche très semblable au feature branch workflow
587mais considère des branches qui ne sont pas dans le même projet.
588
589---
590
591Par exemple, je souhaite proposer une modification de code au projet Strapi.
592Voilà les étapes qui je réalise:
593
5941. Je fork le [dépôt de Strapi](https://github.com/strapi/strapi) pour obtenir [ma propre copie](https://github.com/5ika/strapi)
5952. Sur la branche *main* de mon dépôt, je push des commits
5963. Une fois que je suis satisfait des modifications, je crée [une Pull Request](https://github.com/strapi/strapi/pull/14280) au niveau du dépôt officiel de Strapi pour demander
597aux devs de Strapi de merger la branche *main* de mon dépôt (`5ika:main`) dans la branche *main* du dépôt officiel (`strapi:main`)
598
599Ensuite, un mainteneur de Strapi va regarder ce que je propose comme modification et me faire des commentaires.
600Selon ses retours, je vais ajuster mon code jusqu'à ce que ça corresponde aux attentes du projet officiel
601jusqu'à ce que la branche soit mergée.
602
603---
604
605🫵 Forkez le projet [Deer](https://github.com/5ika/Deer/) avec votre utilisateur GitHub et remarquez ce qui fait.
606
607Vous pouvez maintenant modifier le code comme vous voulez, sur les branches que vous voulez car
608vous êtes sur une copie du projet principal.
609
610---
611
612🫵 Faites un commit sur la branche *main* de vôtre copie de dépôt Deer avec une petite modification de code
613puis créez une Pull Request au niveau du [dépôt principal](https://github.com/5ika/Deer/) pour me soumettre
614votre proposition de changement.
615
616---
617
618Des questions concernant git et l'utilisation des branches ❓
619
620---
621
622# Oh Shit, Git !?! 💩
623
624Git est puissant et très élastique mais il peut arriver qu’on se perde dans son utilisation et dans les pires des cas, qu’on perde des modifications.
625
626Un site référencie les plus grosses mauvaises manipulations et comment les résoudre:
627http://ohshitgit.com/