SUPPORT DE COURS — MODULE 6
GitHub : héberger, connecter, collaborer
Passer d'un dépôt Git local à un projet hébergé sur GitHub, partagé et collaboratif : remotes, fork, Pull
Requests, Issues et revue de code.
1. Créer un compte et un premier repository
Étape Détail
1. Créer un compte [Link] -> Sign up (email universitaire éligible à des avantages étudiants via
GitHub Education)
2. Créer un repository Bouton "New" -> nom, description, visibilité (public/privé)
3. Initialiser Cocher "Add a README file" et choisir un .gitignore adapté au langage
4. Ajouter une licence Facultatif mais recommandé pour un projet destiné à être partagé/réutilisé
Le [Link] est la première chose que voient les visiteurs d'un repository : y décrire clairement l'objectif du
projet, comment l'installer et comment contribuer.
2. Lier un dépôt local à GitHub
git push
Dépôt local GitHub (origin)
sur votre machine dépôt distant
git pull / fetch
Figure 1 — git push envoie vos commits locaux vers GitHub ; git pull (ou git fetch) récupère les commits distants vers votre
machine.
# Associer votre dépôt local à un repository GitHub existant
git remote add origin [Link]
git push -u origin main # -u lie durablement main à origin/main
# Ensuite, au quotidien :
git push # envoie vos nouveaux commits
git pull # récupère et fusionne les commits distants
git fetch # récupère sans fusionner (pour inspecter avant)
3. Fork vs Clone
Pull Request vers upstream
Dépôt original Fork Votre fork Clone Votre clone local
upstream (pas le vôtre) copie sur votre compte GitHub sur votre machine
Figure 2 — Workflow de contribution par fork : on forke le dépôt original, on clone son propre fork, puis on propose ses
changements via une Pull Request vers l'original.
Le fork est le mécanisme standard pour contribuer à un projet auquel vous n'avez pas accès en écriture directe
(la plupart des projets open source). Après un fork, on ajoute souvent un second remote pour suivre le dépôt
original :
git clone [Link]
cd projet-forke
git remote add upstream [Link]
git fetch upstream
git merge upstream/main # pour récupérer les mises à jour du projet original
4. Pull Request : le cycle complet
Créer une Committer les Pousser Ouvrir une Review +
branche changements (push) Pull Request Merge
Figure 3 — Cycle complet d'une contribution via Pull Request, de la création de branche à la fusion après review.
Bonne pratique Pourquoi
Titre clair et description du "pourquoi" Permet à un relecteur de comprendre l'intention sans lire
tout le code
PR de taille raisonnable (quelques centaines Une PR trop grosse est relue superficiellement, ou pas du
de lignes max) tout
Lier la PR à une Issue ("Closes #12") Ferme automatiquement l'Issue à la fusion, garde la
traçabilité
Répondre à chaque commentaire de review Montre que chaque remarque a été prise en compte, même
si rejetée avec justification
5. Issues et code review
Les Issues suivent bugs, tâches et idées, avec labels et assignations. La code review vise le code, jamais la
personne : formuler les remarques de façon factuelle et constructive ("cette fonction pourrait..." plutôt que "tu as
mal fait...").
Checklist minimale pour une revue de code
[ ] La logique correspond-elle à la description de la PR ?
[ ] Les cas limites et cas d'erreur sont-ils gérés ?
[ ] Le code est-il lisible sans commentaire explicatif superflu ?
[ ] Des tests couvrent-ils le nouveau comportement ?
[ ] Aucun secret (clé, mot de passe) n'est présent dans le diff ?
6. Protection de branche
Une règle de protection de branche (Settings -> Branches, sur GitHub) empêche de pousser directement sur
main sans passer par une Pull Request, et peut exiger une revue approuvée ou que les tests automatiques
passent avant fusion. Recommandé même en petite équipe étudiante : cela évite les erreurs de manipulation
autant que les mauvaises pratiques délibérées.
Document 3/4 des supports de cours de la formation « Git & GitHub sur toutes les plateformes ».