git et github

1. 💻 Git & GitHub/Gitlab
De l'installation à la collaboration
Apprends à versionner, partager et collaborer sur ton code.
Réalisée par : ECHHIBOU Mohamed, EL GHAZY Ayoub

2. SOMMAIRE
1. Introduction à Git et GitHub
Concepts fondamentaux et installation
2. Le cycle de vie Git
3. Branches et collaboration
Gestion des branches et workflows
4. Résolution de conflts et bonnes
pratiques
Gestion des conflits et conseils d'experts
5. Outils collaboratifs GitHub
Issues, Projects, Wiki et Releases
6. Atelier complet : mise en pratique pas à
pas
Application des concepts dans un vrai projet
→ À chaque module correspond une séance de travail pratique

3. Introduction à Git et GitHub
Git
Système de contrôle de version distribué (DVCS)
Outil open-source créé par Linus Torvalds en 2005
Suit toutes les modifications apportées au code
source,documentation..
Permet de fusionner les modifications et de revenir à des
versions antérieures
Chaque développeur dispose d'une copie complète de
l'historique du projet
GitHub
Plateforme de développement de logiciels basée sur le
cloud
Utilise Git pour le contrôle de version
Hébergement de dépôts Git facilitant la collaboration
Permet la gestion de projets pour les individus et les équipes
Devenue une plateforme sociale majeure pour les
communautés de développeurs
Différences clés entre Git et GitHub
Caractéristique Git GitHub
Nature Local En ligne
Fonction Historique du code Collaboration & gestion de projet

4. Installation et configuration
1. Installer Git
Linux : apt-get install git
macOS : brew install git
Windows : winget install git
2. Créer un compte GitHub
Rendez-vous sur github.com et inscrivez-vous pour un compte
gratuit.
3. Configurer Git localement
Après l'installation, configurez votre nom et votre adresse e-mail :
Commandes à exécuter dans le terminal
git config --global user.name "TonNom"
git config --global user.email "ton@email.com"
Ces commandes configurent votre nom et votre adresse e-mail
globalement pour tous vos dépôts.

5. Le cycle de vie Git
1. git init
Initialise un nouveau dépôt Git
dans le répertoire courant, créant
un sous-dossier .git
2. git add .
Ajoute tous les fichiers modifiés ou
nouveaux à la zone de staging
.
3. git commit
Enregistre les modifications de la
zone de staging dans le dépôt local
4. git push
Envoie les commits locaux vers le
dépôt distant (GitHub par exemple)
Le processus typique pour enregistrer et partager ton code suit ce cheminement : init add commit push
→ → →

6. Commandes de Bases Git
Afficher le chemin de fichier
Pwd .
Git init : initialiser notre repository
Creation de nouveau depot git :
Cd: change directory
Pour Changer la direction de notre Output
Git Add/Git status
Ajouter des fichiers au zone d’index / et les
affichées
mKdir: Make Directory
Pour créer un nouveau dossier :
Git Commit
Pour sauvegarder les modifications apportés a notre
fichiers

7. Concept des branches
Qu'est-ce qu'une branche ?
Les branches sont une fonctionnalité fondamentale de Git,
permettant de créer des copies parallèles et indépendantes
de votre projet.
Chaque branche représente une ligne de
développement distincte
Les modifications effectuées sur une branche
n'affectent pas les autres branches
L'isolation est cruciale pour le travail d'équipe et
l'expérimentation
Pourquoi utiliser des branches ?
Isolation du travail
Développez sans impacter la
branche principale
Expérimentation
sécurisée
Testez sans risquer de casser le
code principal
Exemples de nommage de branches :
main/master
Branche principale
dev/develop
Branche de développement
feature/nom
Nouvelle fonctionnalité
bugfix/nom
Correction de bug

8. Commandes de gestion des branches
Créer une branche
git branch nom-de-la-branche
Crée une nouvelle branche avec le nom spécifié
Basculer entre branches
git switch nom-de-la-branche
Bascule vers une branche existante (préférable à git checkout)
Créer et basculer
git checkout -b nom-de-la-branche
Crée une nouvelle branche et bascule immédiatement dessus
Pousser vers le dépôt distant
git push -u origin nom-de-la-branche
Pousse la branche locale vers le dépôt distant et configure le
suivi (upstream)
Conseil : Utilisez git branch sans argument pour lister toutes les branches locales
Page 8/22

9. Comprendre les conflits de fusion
Qu'est-ce qu'un conflit de fusion ?
Un conflit de fusion se produit lorsque Git ne parvient pas à
intégrer automatiquement les modifications de deux branches.
Cela arrive généralement quand :
• Deux développeurs modifient la même ligne de code
• Un fichier est supprimé dans une branche et modifié dans
l'autre
Comment Git détecte les conflits
Git arrête le processus de fusion et marque les fichiers concernés.
Vous devrez résoudre manuellement les conflits avant de pouvoir
finaliser la fusion.
Exemple de marqueurs de conflit
<*<< < < < < < HEAD
// Version A : Modifications de la branche actuelle (HEAD)
=======
// Version B : Modifications de la branche à fusionner
>*> > > > > feature-readme
HEAD représente la version de votre branche actuelle, et feature-
readme (ou le nom de l'autre branche) représente la version de la
branche que vous tentez de fusionner.
Conseil : Les conflits sont normaux et faciles à résoudre quand on les comprend !

10. Résolution des conflits
1. Identifier les fichiers en conflit
Utilisez la commande git status pour lister les fichiers concernés
2. Éditer manuellement le fichier
Ouvrez le fichier en conflit dans votre éditeur de texte
3. Choisir la bonne version
Décidez quelle version du code vous souhaitez conserver
4. Supprimer les marqueurs
Retirez les lignes <<<<<<< HEAD, ======= et >>>>>> nom-de-la-
branche
5. Stager et committer la résolution
Après correction, utilisez git add . puis git commit -m "Résolution
du conflit"
Conseil
Lorsque Git détecte un conflit, il insère des marqueurs spéciaux dans
le fichier pour indiquer les sections en désaccord.
→ La résolution des conflits est une compétence essentielle pour la collaboration efficace

11. Bonnes pratiques Git
Commits petits et clairs
Effectuez des commits fréquents avec des messages concis et descriptifs. Chaque commit devrait correspondre à une
modification logique et atomique. Cela rend l'historique plus facile à comprendre et simplifie la résolution des conflits.
Toujours git pull avant git push
Avant de pousser vos modifications, assurez-vous de récupérer les dernières mises à jour du dépôt distant (git pull) pour
intégrer le travail des autres et résoudre les conflts localement avant de les publier.
Supprimer les branches fusionnées
Une fois qu'une branche de fonctionnalité a été fusionnée dans la branche principale et que le travail est validé,
supprimez-la pour garder votre dépôt organisé et éviter la accumulation de branches inutiles.

12. Outils collaboratifs GitHub
Issues (Suivi des tâches)
Éléments de suivi pour signaler les bugs, proposer des
fonctionnalités et gérer le travail. Peuvent être assignés à
des membres de l'équipe, catégorisés par labels et
regroupés en jalons.
Projects (Tableaux Kanban)
Tableaux de bord personnalisables pour organiser et suivre
le travail. Configurables comme des tableaux Kanban ("To
Do", "Doing", "Done") ou des feuilles de route.
Wiki (Documentation)
Espace dédié à la documentation du projet, idéal pour
héberger la documentation technique, les guides
d'utilisation et les spécifications. Le contenu est versionné
comme le code source.
Releases (Publication de versions)
Outils pour marquer des points stables et livrables dans
l'historique du projet. Associés à des tags Git, ils peuvent
inclure des notes de version détaillées et des fichiers
binaires.
Intégrations
GitHub s'intègre avec des outils externes et des applications de bureau. GitHub Desktop offre une interface graphique pour interagir avec
les dépôts Git sans utiliser la ligne de commande. L'intégration Git de VS Code permet de gérer les opérations Git directement depuis
l'éditeur de code, y compris la résolution des conflts de fusion.

13. Conclusion - Culture de collaboration
"Git n'est pas qu'un outil technique : c'est une culture de collaboration et de
confiance."
Piliers de la collaboration
Git et GitHub transforment la manière dont les équipes
conçoivent et réalisent des projets.
Valorisation du partage
La gestion de versions permet de valoriser le travail
d'équipe et la transparence.
Confiance par la transparence
La traçabilité des modifications crée un environnement de
confiance au sein des équipes.
Efficiency et innovation
Les outils de collaboration facilitent l'efficacité et stimulent
l'innovation dans les projets.
Merci ! Questions ? @votre-compte-github

14. Exercice - Créer une Pull Request
1. Créer une nouvelle branche
Utilise la commande suivante dans ton terminal :
git checkout -b ma-branche-readme
2. Modifier le fichier README.md
Ouvre le fichier README.md et ajoute une ligne :
echo "Ce projet est en cours de développement par [Ton
Nom]." >> README.md
3. Stager et commiter tes modifications
Utilise les commandes suivantes :
git add README.md
git commit -m "Ajout de mon nom au README"
4. Pousser ta branche sur GitHub
Utilise la commande suivante :
git push -u origin ma-branche-readme
5. Créer une Pull Request sur GitHub
Rends-toi sur la page de ton dépôt GitHub et :
• GitHub détectera automatiquement ta nouvelle branche
• Clique sur "Compare & pull request"
• Donne un titre clair à ta PR (ex: "Ajout de mon nom au README")
• Clique sur "Create pull request"
.

15. Exercice - Utiliser les outils GitHub
1 Créer une Issue
Sur votre dépôt GitHub, créez une nouvelle Issue pour une tâche
simple, par exemple "Ajouter une section FAQ au README".
2 Lier l'Issue à une Pull Request
Créez une nouvelle branche, modifiez le README.md pour ajouter une
section FAQ, commitez vos changements, puis ouvrez une Pull
Request. Dans la description de la PR, référencez l'Issue que vous
venez de créer (par exemple, en utilisant #numéro_issue).
3 Ajouter une note Wiki
Accédez à la section Wiki de votre dépôt et ajoutez une page simple
expliquant comment contribuer au projet.
Rappel
GitHub, c'est un écosystème complet de collaboration.
Cet exercise vous permet de découvrir les outils collaboratifs de
GitHub et de comprendre comment ils s'intègrent dans le
workflow de développement.
→ Ces outils vous permettront de gérer efficacement vos projets collaboratifs

16. Phase 1 - Initialiser un projet existant
1 Ouvrir le projet dans VS Code
Accède au répertoire de ton projet via le terminal ou directement
dans VS Code.
2 Initialiser le dépôt Git
Exécute la commande suivante dans le terminal :
3 Vérifier l'état des fichiers
Utilise la commande git status pour voir les fichiers modifiés et non
suivis.
4 Stager tous les fichiers
Ajoute tous les fichiers modifiés et non suivis à la zone de staging
avec git add .
5 Enregistrer les modifications
Crée un commit initial avec un message descriptif : git commit -m
"Initialisation du projet existant"
terminal
$ git init
Initialized empty Git repository in /chemin/vers/projet/.git/
$ git status
sur working tree dirty: modified: fichier.py
$ git add .
$ git commit -m "Initialisation du projet existant"
[main (root-commit) abc1234] Initialisation du projet existant
1 file changed, 10 insertions(+)
Astuce : Le point (.) après git add indique d'ajouter tous les changements du répertoire courant.

17. Phase 2 - Connecter à GitHub
1. Créer un dépôt distant
Sur GitHub, créez un nouveau dépôt vide sans ajout de fichier
README.md ni de .gitignore.
2. Lier les dépôts
Connectez votre dépôt local à GitHub en utilisant la commande
suivante (remplacez l'URL par celle de votre dépôt) :
3. Pousser les modifications
Téléchargez vos commits locaux vers la branche main de GitHub :
Commandes à exécuter
git remote add origin
https://github.com/votre-utilisateur/votre-repo.git
# Établit un lien entre votre dépôt local et le dépôt distant
git push -u origin main
# Pousse les commits locaux vers la branche main distante et configure le suivi
Dépôt maintenant publié sur GitHub
La prochaine phase explique le travail quotidien avec Git et GitHub

18. Phase 3 - Flux de travail quotidien
Le cycle de base du travail quotidien
1. Avant de coder
Toujours faire un git pull pour récupérer les dernières
modifications
git pull origin main
2. Enregistrer ses modifications
Stager et commiter ses changements avec un message clair
git add .
git commit -m "Message clair"
3. Publier ses changements
Pousser les commits locaux vers le dépôt distant
git push origin main
Bonnes pratiques pour les messages de
commit
Courts et précis
Les messages de commit doivent être concis et décrire
l'objectif du changement
Au présent de l'indicatif
Utilisez le présent de l'indicatif (ex: "Ajoute la fonctionnalité X"
plutôt que "J'ai ajouté la fonctionnalité X")
Décrivez le "quoi" et le "pourquoi"
Expliquez non seulement ce qui a été changé, mais aussi
pourquoi ce changement est important
# Exemple de bon message de commit
git commit -m "Corrige le bug d'affichage sur la page d'accueil"

19. Phase 4 - Gestion avancée des branches
Création des branches fonctionnalités
Conventions de nommage pour les branches :
feature/ pour les nouvelles fonctionnalités
bugfix/ pour les corrections de bugs
git checkout -b feature-readme
Développement et synchronisation
Avant de coder, toujours synchroniser
git pull origin main
Travailler localement sans impact sur main
Stager et commiter régulièrement
git add . && git commit -m "Message clair"
Pull Request et fusion
1 Pousser la branche sur GitHub
git push -u origin feature-readme
2 Créer une Pull Request sur GitHub
Via l'interface ou en ligne de commande
3 Fusionner la PR après validation
Via GitHub Desktop ou ligne de commande
git merge feature-readme
Nettoyage des branches
Supprimer la branche locale après fusion
Supprimer la branche distante pour garder le dépôt propre
git branch -d feature-readme && git push origin --delete feature-
readme
Conseil : Une branche = une fonctionnalité

20. Phase 5 - Résolution pratique des conflits
1. Détection du conflit
Tentative de fusion avec git merge détecte les conflits
$ git merge feature-filter
Auto-merging data.py
CONFLICT (content): Merge conflict in data.py
Automatic merge failed; fix conflicts and then commit the result.
2. Résolution manuelle
Modifier le fichier en conflit et supprimer les marqueurs
<<<<<<< HEAD
def process_data(data):
return [d.upper() for d in data]
=======
def process_data(data):
return [d.lower() for d in data]
>>>>>>> feature-filter
$ git status
On branch main
Changes to be committed:
modified: data.py
$ git commit -m "Résolution du conflit"
[main 1234567] Résolution du conflit
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), done.
3. Finalisation
git add . + git commit -m "Résolution du conflit" + git push
• Stager le fichier résolu
• Créer un commit de fusion
• Pousser la résolution vers le dépôt distant
Conseil : Toujours vérifier l'état des fichiers avant de pousser

21. Phase 6 - Collaboration en équipe
1. Ajout de collaborateurs
• Ajoutez des collaborateurs via les paramètres du dépôt
GitHub
• Les droits d'accès peuvent être configurés (lecture,
écriture)
• Les collaborateurs reçoivent une notification par email
2. Clonage des dépôts
• Chaque membre de l'équipe clone le dépôt via HTTPS
ou SSH
• Utilisez git clone <URL>
• Le clonage créer une copie locale du dépôt complet
3. Workflow de collaboration
• Chaque développeur crée sa propre branche locale
• Travaillez sur des fonctionnalités isolées dans vos
branches
• Push des branches vers le dépôt distant
• Création de Pull Requests pour fusionner les
changements
4. Bonnes pratiques en équipe
• Toujours faire un git pull avant de commencer à coder
• Utiliser des messages de commit clairs et descriptifs
• Les Pull Requests doivent être revues avant fusion
• Supprimer les branches après fusion pour garder le
dépôt propre
Dev 1 Dev 2 GitHub Dev 1

22. Phase 7 - Récapitulatif des bonnes pratiques
✅ git pull avant tout travail
Récupérez toujours les dernières modifications du dépôt distant avant de commencer à travailler pour éviter les conflts.
✅ Une branche = une fonctionnalité
Créez une nouvelle branche pour chaque nouvelle fonctionnalité ou correction de bug. Ne jamais travailler directement sur la branche
principale.
✅ Commits clairs et petits
Effectuez des commits fréquents avec des messages concis et descriptifs. Chaque commit devrait correspondre à une modification logique
et atomique.
✅ Toujours via PR (Pull Request)
Proposez vos modifications via une Pull Request pour revue de code avant de les fusionner dans la branche principale.