Introduction

Bienvenue

• Les questions
• Where is Brian?
• Le chauve

Objectif

• Kécécé ?
• Pourquoi ?
• Comment ?
• GitHub
• GitLab

Présentation de Git

Kécécé ?

Système de Contrôle de Version Distribué
Décentraliser la gestion de projet, dépôts locaux
Contexte historique
Linus Torvalds

Pourquoi ?

• Versionning
  • contrôle
  • rollback
• Collaboration : branches
• Moins de risques
  • dépôts locaux
  • merge conflicts

Concepts de base

• Dépôt (repository) : local et distant
• Commit : capture d’un état du projet
• Branches : lignes parallèles de développement
• Fusion (merge) : combinaison de branches

Cas d’utilisations

• Collaboration sur des projets étudiants en équipe
• Gestion de code pour un projet personnel
• Travail sur des projets open source

Méthodes communes et conventions

Commandes essentielles

• Initialisation :

git init

• Clonage :

git clone {url}

• Ajout de fichiers au suivi :

git add {fichiers}

• Création d’un commit :

git commit -m "message"

• Envoi des modifications :

git push (origin) (main)

• Récupération des modifications :

git pull

• Vérification du statut du dépôt local :

git status

• Vérification des différences entre les fichiers

git diff [fichiers]

Exemple 1 : Création de dépôt

Exemple 2 : Session de travail sur la branche main

Merge conflicts

Démonstration

Rebase, Merge et Squash

Merge

Méthode par défaut

• Kécécé ?
  • commit de fusion
  • historique combiné
• Avantages
  • Conserve un historique complet et détaillé
  • Utile pour les projets où l’historique dois refléter tous les changements (collaboration en équipe)
• Quand l’utiliser
  • Fusions fréquentes sur un projet en équipe
  • chaque commit apporte une information importante

Rebase

Réécrire l’histoire

• Kécécé ?
  Appliquer les commits d’une branche (feature) sur la branche cible (main), comme si les modifications avaient été créées directement à partir de la branche cible.
• Avantage
  Historique linéaire et clair, plus simple pour les gros projets
• Quand l’utiliser
  • Projet solo
  • Besoin d’un historique le plus linéaire possible
  • Pour “rejouer” une branche

Squash

tout fusionner en 1 commit

• Kécécé ?
  Tous les commits d’une branche (feature) sont fusionnés un un seul commit lors de la fusion avec la branche cible (main)
• Avantage
  Réduire le bruit dans l’historique
• Inconvénient
  L’historique détaillé des commits individuels de la branche est perdu
• Quand l’utiliser
  • Branches de petite envergure, correctifs simples
  • Commits intermédiaires non pertinents

Note

Lors d’une pull request, le mainteneur choisit la méthode de fusion. Le contributeur peut suggérer.

Situation	Merge	Rebase	Squash
Collaboration en équipe	✅ Historique détaillé	⚠️ Risque de conflits	❌ Trop simplifié
Projet solo	⚠️ Trop verbeux	✅ Historique propre	✅ Résumé concis
Corrections rapides	⚠️ Trop lourd	❌ Complexe	✅ Idéal
Historique lisible à long terme	❌ Historique encombré	✅ Linéaire et clair	⚠️ Perte de détail

Exemple 3 : Résolution de bug

Conventions

• Messages de commit clairs et concis
  • ✅"fix: correct typo in README.md"
  • ✅"feature: user can send message with ENTER key"
  • ❌"update stuff"
  • ❌"c’est mieux comme ça"

fix, feature, refactor, style, chore, perf, revert, docs

• Noms de branche descriptifs

  • main, master
  • prod, preprod, dev …
  • android, iOS …
  • fix/bug-42 …

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

GitHub

Kécécé ?

• Plateforme d’hébergement de dépôts Git
• Fonctionnalités additionnelles
  • Pull Requests
  • Issues
  • CI/CD : “actions”

Collaborer sur GitHub

• Créer et gérer des Pull Requests
• Utiliser les Issues pour le suivi des tâches

GitHub Desktop

Démonstration

GitLab

Kécécé ?

• Plateforme similaire à GitHub mais open-core
• Auto-hébergement pour les entreprises ou les projets sensibles

Cas d’utilisation

• Projets nécessitant un contrôle total sur les données
• Entreprises ou équipes ayant des exigences spécifiques de sécurité

Conclusion

Git, c’est bien.
Des questions ?