Introduction

Lorsqu’on crée un site web, une application, un script ou tout autre projet informatique, on écrit du code source. Ce code évolue avec le temps : on ajoute des fonctionnalités, on corrige des erreurs, on modifie des fichiers, on travaille parfois à plusieurs.

Sans méthode d’organisation, il devient vite difficile de savoir :

• quelle version du code est la bonne ;
• qui a modifié quoi ;
• quand une erreur a été introduite ;
• comment revenir à une version précédente ;
• comment collaborer sans écraser le travail des autres.

La gestion du code source permet de répondre à ces problèmes. Elle repose principalement sur des outils de versioning, comme Git, et des plateformes de collaboration, comme GitHub.

---

1. Qu’est-ce que le code source ?

Le code source est l’ensemble des instructions écrites par un développeur pour créer un programme informatique, un site web, une application ou un script.

Exemples de fichiers de code source :

index.html
style.css
script.js
main.py
app.php
database.sql

Le code source peut aussi être accompagné d’autres fichiers :

README.md
package.json
.env
.gitignore
images/
docs/

Ces fichiers servent à documenter le projet, configurer l’environnement, gérer les dépendances ou organiser les ressources.

---

2. Pourquoi gérer son code source ?

La gestion du code source permet de travailler de manière organisée, sécurisée et collaborative.

Elle permet notamment de :

• conserver l’historique des modifications ;
• revenir à une ancienne version ;
• comparer deux versions d’un fichier ;
• travailler à plusieurs sur le même projet ;
• éviter de perdre du code ;
• tester de nouvelles fonctionnalités sans casser le projet principal ;
• documenter les changements ;
• publier ou partager un projet.

Exemple simple :
Un étudiant modifie son site web et le casse accidentellement. Grâce à Git, il peut retrouver la version précédente qui fonctionnait.

---

3. Les problèmes sans gestion de version

Sans outil de versioning, on finit souvent avec des fichiers comme :

projet_final.zip
projet_final_v2.zip
projet_final_vrai.zip
projet_final_corrige.zip
projet_final_corrige_bon.zip

Cette méthode pose plusieurs problèmes :

• on ne sait plus quelle version est la plus récente ;
• les fichiers prennent beaucoup de place ;
• il est difficile de savoir ce qui a changé ;
• la collaboration est compliquée ;
• les erreurs sont difficiles à retrouver ;
• le risque de perte est élevé.

Git permet d’éviter cette confusion en enregistrant proprement chaque étape du projet.

---

4. Qu’est-ce que Git ?

Git est un logiciel de gestion de versions. Il permet d’enregistrer l’évolution d’un projet dans le temps.

Git fonctionne localement sur l’ordinateur du développeur. Il garde un historique des changements effectués dans les fichiers.

Avec Git, on peut :

• suivre les modifications ;
• créer des sauvegardes successives appelées commits ;
• créer des branches ;
• fusionner des changements ;
• revenir en arrière ;
• collaborer avec d’autres personnes.

Git est donc l’outil technique de gestion de versions.

---

5. Qu’est-ce que GitHub ?

GitHub est une plateforme en ligne qui héberge des projets Git.

GitHub permet de stocker un projet sur Internet, de le partager, de collaborer avec d’autres personnes et d’utiliser des outils complémentaires.

GitHub permet notamment de :

• héberger des dépôts de code ;
• partager un projet publiquement ou en privé ;
• travailler en équipe ;
• créer des issues pour suivre les tâches ;
• proposer des modifications via des pull requests ;
• relire le code des autres ;
• automatiser des tests ou des déploiements ;
• documenter un projet.

Git est l’outil de versioning.
GitHub est une plateforme qui utilise Git pour collaborer en ligne.

GitHub décrit les pull requests comme un moyen de proposer des changements à un projet, de recevoir des changements proposés par d’autres et de traiter les problèmes liés aux modifications, comme les conflits de fusion. (GitHub Docs)

---

6. Différence entre Git et GitHub

Git	GitHub
Logiciel installé sur l’ordinateur	Plateforme en ligne
Gère les versions du code	Héberge les dépôts Git
Fonctionne localement	Fonctionne via Internet
Permet les commits, branches, merges	Ajoute collaboration, issues, pull requests
Peut être utilisé sans GitHub	Utilise Git comme base

Exemple :
On peut utiliser Git seul sur son ordinateur. Mais pour partager le code avec une équipe, on peut l’envoyer sur GitHub.

---

7. Le dépôt ou repository

Un dépôt, appelé aussi repository ou repo, est un dossier de projet suivi par Git.

Il contient :

• les fichiers du projet ;
• l’historique des modifications ;
• les branches ;
• les commits ;
• parfois une documentation ;
• parfois des paramètres GitHub.

Exemple de structure :

mon-projet/
├── index.html
├── style.css
├── script.js
├── README.md
└── images/

Sur GitHub, chaque projet est généralement stocké dans un dépôt.

---

8. Dépôt local et dépôt distant

Dépôt local

Le dépôt local se trouve sur l’ordinateur du développeur.

C’est là que l’on modifie les fichiers et que l’on crée les commits.

Dépôt distant

Le dépôt distant se trouve sur une plateforme en ligne, comme GitHub.

Il permet de sauvegarder le projet en ligne et de le partager avec d’autres personnes.

Exemple

Ordinateur personnel = dépôt local
GitHub = dépôt distant

Les commandes Git permettent de synchroniser les deux.

---

9. Les trois états principaux d’un fichier avec Git

Git distingue plusieurs états pour les fichiers.

1. Fichier modifié

Le fichier a été changé, mais Git n’a pas encore préparé cette modification pour l’enregistrement.

2. Fichier ajouté à l’index

Le fichier est placé dans la zone de préparation, appelée staging area.

3. Fichier validé

Le fichier est enregistré dans l’historique grâce à un commit.

Schéma simplifié :

Modification du fichier
        ↓
git add
        ↓
Zone de préparation
        ↓
git commit
        ↓
Historique du projet

---

10. Le commit

Un commit est une sauvegarde claire d’un état du projet.

Il correspond à un point précis dans l’historique.

Selon la documentation GitHub, un commit enregistre les changements faits dans un ou plusieurs fichiers d’une branche. Git lui attribue un identifiant unique, appelé SHA ou hash, qui permet d’identifier les changements, leur date et leur auteur. (GitHub Docs)

Chaque commit contient :

• les fichiers modifiés ;
• l’auteur ;
• la date ;
• un identifiant unique ;
• un message explicatif.

Exemple de message de commit :

Ajout de la page de contact

Autre exemple :

Correction du formulaire d’inscription

---

11. Bonnes pratiques pour les commits

Un bon commit doit être :

• clair ;
• logique ;
• limité à une modification cohérente ;
• accompagné d’un message compréhensible.

Il vaut mieux faire plusieurs petits commits qu’un seul gros commit contenant tout.

Mauvais message de commit

modifs

test

final

Bon message de commit

Ajout du menu de navigation

Correction du bug de connexion

Mise à jour du fichier README

Un bon historique Git doit permettre de comprendre l’évolution du projet.

---

12. Les branches

Une branche est une version parallèle du projet.

Elle permet de travailler sur une fonctionnalité ou une correction sans modifier directement la version principale.

Exemple :

main
 ├── feature-login
 ├── correction-menu
 └── test-design

La branche principale s’appelle souvent main.

On crée une branche pour :

• développer une nouvelle fonctionnalité ;
• corriger un bug ;
• tester une idée ;
• travailler à plusieurs ;
• éviter de casser la version stable.

GitHub permet aussi de protéger des branches importantes avec des règles qui empêchent certaines actions, comme la suppression ou le force push, et qui peuvent exiger des validations ou des tests avant modification. (GitHub Docs)

---

13. La branche main

La branche main représente généralement la version principale du projet.

Elle doit rester stable.

On évite de travailler directement dessus lorsque le projet est collaboratif. On préfère créer une branche séparée, puis proposer les changements.

Exemple :

main = version stable
feature-contact-form = nouvelle fonctionnalité en cours

---

14. Fusionner des branches

Quand le travail sur une branche est terminé, on peut fusionner cette branche avec la branche principale.

Cette opération s’appelle un merge.

Exemple :

feature-login → main

Cela signifie que les changements de la branche feature-login sont intégrés dans la branche main.

---

15. Les conflits de fusion

Un conflit de fusion apparaît lorsque Git ne sait pas automatiquement quelle version conserver.

Cela arrive souvent quand deux personnes ont modifié la même partie d’un fichier.

Exemple :

<<<<<<< HEAD
Bienvenue sur notre site
=======
Bienvenue sur mon site web
>>>>>>> feature-title

Le développeur doit alors choisir manuellement la bonne version.

Les conflits sont normaux dans le travail collaboratif. Ils ne sont pas une erreur grave, mais ils doivent être résolus avec attention.

---

16. Les commandes Git essentielles

Voici les commandes les plus courantes.

Initialiser un dépôt

git init

Cette commande transforme un dossier en dépôt Git.

---

Vérifier l’état du projet

git status

Cette commande montre les fichiers modifiés, ajoutés ou non suivis.

---

Ajouter un fichier à l’index

git add fichier.html

Pour ajouter tous les fichiers modifiés :

git add .

---

Créer un commit

git commit -m "Ajout de la page d’accueil"

Cette commande enregistre les changements dans l’historique.

---

Voir l’historique

git log

Version simplifiée :

git log --oneline

---

Créer une branche

git branch nouvelle-branche

---

Changer de branche

git checkout nouvelle-branche

Commande plus récente :

git switch nouvelle-branche

---

Créer et changer de branche en une commande

git switch -c feature-contact

---

Fusionner une branche

git merge feature-contact

---

Connecter un dépôt local à GitHub

git remote add origin URL_DU_DEPOT

---

Envoyer le code vers GitHub

git push

Souvent, au premier envoi :

git push -u origin main

---

Récupérer les changements depuis GitHub

git pull

---

Cloner un projet existant

git clone URL_DU_DEPOT

---

17. Le fichier README.md

Le fichier README.md est souvent la première page visible d’un dépôt GitHub.

Il sert à présenter le projet.

Il peut contenir :

• le nom du projet ;
• une description ;
• les objectifs ;
• les technologies utilisées ;
• les instructions d’installation ;
• les commandes utiles ;
• des captures d’écran ;
• les auteurs ;
• la licence.

Exemple simple :

# Mon projet

Ce projet est un site web de présentation.

## Technologies utilisées

- HTML
- CSS
- JavaScript

## Installation

Ouvrir le fichier index.html dans un navigateur.

Un bon README rend le projet plus clair et plus professionnel.

---

18. Le fichier .gitignore

Le fichier .gitignore indique à Git les fichiers à ne pas suivre.

Il est utile pour éviter d’envoyer sur GitHub :

• des fichiers temporaires ;
• des mots de passe ;
• des fichiers de configuration locale ;
• des dossiers lourds ;
• des dépendances installées automatiquement ;
• des fichiers générés par l’ordinateur.

Exemple :

node_modules/
.env
.DS_Store
*.log

Le fichier .env contient souvent des informations sensibles. Il ne doit généralement pas être publié sur GitHub.

---

19. Les données sensibles dans le code source

Il ne faut jamais publier dans un dépôt GitHub :

• mots de passe ;
• clés API ;
• identifiants de base de données ;
• tokens d’accès ;
• fichiers .env ;
• informations clients confidentielles ;
• données personnelles non anonymisées.

Même dans un dépôt privé, il faut rester prudent.

Si une clé secrète a été publiée par erreur, il ne suffit pas de la supprimer du fichier. Elle peut encore exister dans l’historique Git. Il faut généralement la révoquer et en créer une nouvelle.

---

20. GitHub public et privé

Sur GitHub, un dépôt peut être public ou privé.

Dépôt public

Un dépôt public est visible par tout le monde.

Il est utile pour :

• partager un projet open source ;
• montrer son portfolio ;
• publier des exercices ;
• collaborer publiquement ;
• rendre un projet consultable.

Dépôt privé

Un dépôt privé est visible uniquement par les personnes autorisées.

Il est utile pour :

• les projets professionnels ;
• les projets confidentiels ;
• les travaux non terminés ;
• le code contenant une logique métier ;
• les projets d’équipe internes.

---

21. Les issues

Une issue est une fiche de suivi dans GitHub.

Elle peut servir à signaler :

• un bug ;
• une amélioration ;
• une tâche ;
• une question ;
• une demande de fonctionnalité ;
• un problème de documentation.

Exemple d’issue :

Titre : Le bouton de connexion ne fonctionne pas

Description :
Quand l’utilisateur clique sur le bouton, rien ne se passe.
Navigateur : Chrome
Page concernée : login.html

Les issues permettent d’organiser le travail.

GitHub indique que les issues et les pull requests peuvent être filtrées, triées et recherchées afin de retrouver les informations importantes d’un dépôt. (GitHub Docs)

---

22. Les pull requests

Une pull request, souvent abrégée en PR, est une demande d’intégration de changements.

Elle permet de proposer que le code d’une branche soit ajouté à une autre branche, souvent main.

Une pull request permet :

• de présenter les changements ;
• de discuter du code ;
• de demander une relecture ;
• de détecter des erreurs ;
• de lancer des tests automatiques ;
• de valider avant fusion.

GitHub explique que l’onglet Conversation d’une pull request affiche la description des changements, les événements, les commentaires et les revues de collaborateurs. L’onglet Commits affiche les commits de la branche dans l’ordre chronologique. (GitHub Docs)

---

23. Exemple de workflow GitHub simple

Voici un processus classique :

1. Créer une issue
2. Créer une branche
3. Modifier le code
4. Faire des commits
5. Envoyer la branche sur GitHub
6. Créer une pull request
7. Relire le code
8. Corriger si nécessaire
9. Fusionner dans main
10. Fermer l’issue

Ce workflow permet de garder une organisation claire.

---

24. Lier une pull request à une issue

GitHub permet de lier une pull request à une issue.

Cela montre qu’une correction ou une fonctionnalité est en cours.

On peut utiliser certains mots-clés dans la description d’une pull request ou dans un message de commit :

fixes #12
closes #12
resolves #12

Quand la pull request est fusionnée dans la branche par défaut, l’issue liée peut être automatiquement fermée. (GitHub Docs)

---

25. La revue de code

La revue de code consiste à faire relire les modifications par une autre personne avant de les intégrer au projet principal.

Elle permet de :

• détecter des erreurs ;
• améliorer la qualité du code ;
• partager les connaissances ;
• vérifier le respect des consignes ;
• éviter les failles de sécurité ;
• améliorer la lisibilité.

Une revue de code ne doit pas être vue comme une critique personnelle. Elle sert à améliorer le projet.

---

26. Les bonnes pratiques de collaboration

Pour bien collaborer avec GitHub, il faut :

• créer une branche par fonctionnalité ;
• faire des commits réguliers ;
• écrire des messages clairs ;
• créer des pull requests compréhensibles ;
• décrire ce qui a été modifié ;
• relire le code avant fusion ;
• éviter de travailler directement sur main ;
• synchroniser régulièrement son dépôt local ;
• résoudre les conflits avec attention ;
• respecter les conventions de l’équipe.

---

27. GitHub Desktop

GitHub Desktop est une application graphique qui permet d’utiliser GitHub sans passer uniquement par la ligne de commande.

Elle permet de :

• cloner un dépôt ;
• voir les fichiers modifiés ;
• créer des commits ;
• changer de branche ;
• pousser les changements vers GitHub ;
• récupérer les changements ;
• gérer certaines opérations Git plus facilement.

C’est une bonne solution pour les débutants, même si connaître les commandes Git reste important.

---

28. GitHub Codespaces

GitHub Codespaces permet de travailler dans un environnement de développement en ligne.

Au lieu d’installer tous les outils sur son ordinateur, on peut ouvrir un environnement prêt à l’emploi dans le navigateur.

Cela peut être utile pour :

• travailler depuis plusieurs ordinateurs ;
• éviter les problèmes d’installation ;
• démarrer rapidement un projet ;
• uniformiser l’environnement d’une équipe ;
• tester un projet sans configurer sa machine.

---

29. GitHub Actions

GitHub Actions permet d’automatiser certaines tâches.

Exemples :

• lancer des tests automatiquement ;
• vérifier la qualité du code ;
• construire une application ;
• déployer un site web ;
• envoyer une notification ;
• publier une nouvelle version.

Ce principe s’appelle souvent CI/CD.

CI signifie intégration continue.
CD signifie déploiement continu ou livraison continue.

Exemple :
À chaque pull request, GitHub Actions peut lancer automatiquement les tests pour vérifier que le projet fonctionne encore.

---

30. Les releases et les versions

Une release est une version publiée d’un projet.

Elle permet d’identifier une étape importante.

Exemples :

v1.0.0
v1.1.0
v2.0.0

Une bonne gestion des versions permet de savoir quelles fonctionnalités sont disponibles dans chaque version.

Exemple :

v1.0.0 : première version stable
v1.1.0 : ajout du formulaire de contact
v1.2.0 : correction de bugs

---

31. Les licences

Une licence indique ce que les autres personnes ont le droit de faire avec le code.

Elle peut préciser si le code peut être :

• utilisé ;
• copié ;
• modifié ;
• redistribué ;
• utilisé commercialement.

Exemples de licences courantes :

MIT
Apache 2.0
GPL
BSD

Sans licence claire, les droits d’utilisation du code peuvent être ambigus.

---

32. Exemple complet d’utilisation de Git et GitHub

Imaginons un projet de site web.

Étape 1 : créer un dossier

mkdir mon-site
cd mon-site

Étape 2 : initialiser Git

git init

Étape 3 : créer les fichiers

index.html
style.css
README.md

Étape 4 : vérifier l’état

git status

Étape 5 : ajouter les fichiers

git add .

Étape 6 : créer un commit

git commit -m "Initialisation du projet"

Étape 7 : créer un dépôt sur GitHub

Sur GitHub :

New repository → nom du projet → Create repository

Étape 8 : connecter le dépôt local au dépôt GitHub

git remote add origin https://github.com/utilisateur/mon-site.git

Étape 9 : envoyer le code

git push -u origin main

Le projet est maintenant disponible sur GitHub.

---

33. Exemple de travail avec une branche

Créer une branche

git switch -c ajout-contact

Modifier le fichier

contact.html

Ajouter les changements

git add .

Créer un commit

git commit -m "Ajout de la page contact"

Envoyer la branche sur GitHub

git push -u origin ajout-contact

Créer une pull request

Sur GitHub :

Compare & pull request

Après relecture, la branche peut être fusionnée dans main.

---

34. Sécurité du compte GitHub

Un compte GitHub doit être protégé, car il peut donner accès à du code important.

Bonnes pratiques :

• utiliser un mot de passe fort ;
• activer l’authentification à deux facteurs ;
• ne pas partager son compte ;
• vérifier les accès aux dépôts ;
• supprimer les anciens tokens inutilisés ;
• éviter de publier des secrets ;
• utiliser des permissions limitées ;
• surveiller les connexions suspectes.

---

35. Erreurs fréquentes des débutants

Oublier de faire des commits

Il faut faire des commits régulièrement pour garder un historique utile.

Faire des commits trop vagues

Un message comme test ou modif n’aide pas à comprendre l’historique.

Travailler directement sur main

Cela peut casser la version principale du projet.

Publier des mots de passe

C’est une erreur grave. Les secrets ne doivent jamais être versionnés.

Ne jamais faire de pull

Avant de travailler, il faut récupérer les dernières modifications du dépôt distant.

Ignorer les conflits

Un conflit mal résolu peut casser le projet.

Ne pas documenter le projet

Un projet sans README est plus difficile à comprendre et à reprendre.

---

36. Vocabulaire essentiel

Terme	Définition
Code source	Instructions écrites par le développeur
Git	Outil de gestion de versions
GitHub	Plateforme d’hébergement et de collaboration Git
Repository	Dépôt contenant le projet
Commit	Enregistrement d’un état du projet
Branch	Version parallèle du projet
Merge	Fusion de deux branches
Pull request	Demande d’intégration de changements
Issue	Tâche, bug ou demande à suivre
Clone	Copie d’un dépôt distant sur son ordinateur
Push	Envoi des changements vers GitHub
Pull	Récupération des changements depuis GitHub
README	Fichier de présentation du projet
.gitignore	Fichier indiquant quoi ignorer
Conflict	Désaccord entre deux modifications
Release	Version publiée d’un projet

---

37. Synthèse

La gestion du code source est essentielle pour travailler proprement sur un projet informatique.

Elle permet de :

• conserver l’historique ;
• retrouver les anciennes versions ;
• collaborer efficacement ;
• éviter les pertes de code ;
• tester sans casser le projet ;
• documenter les changements ;
• améliorer la qualité du travail.

Git est l’outil qui permet de gérer les versions du code.
GitHub est la plateforme qui permet de stocker, partager et collaborer autour de ce code.

Pour un bon usage de GitHub, il faut retenir :

• faire des commits clairs ;
• utiliser des branches ;
• créer des pull requests ;
• protéger la branche principale ;
• documenter le projet ;
• éviter de publier des données sensibles ;
• utiliser les issues pour organiser le travail ;
• sécuriser son compte.

---

Conclusion

La gestion du code source n’est pas réservée aux grands projets professionnels. Elle est utile dès les premiers exercices de programmation.

Git et GitHub permettent de travailler de manière plus organisée, plus sûre et plus professionnelle. Ils facilitent la collaboration, la sauvegarde, la correction d’erreurs et le suivi de l’évolution d’un projet.

Maîtriser GitHub est aujourd’hui une compétence importante pour tout développeur, étudiant en informatique, créateur de site web ou personne amenée à gérer un projet numérique.