Introduction à Git et GitHub – Partie 3

Dans cette dernière partie du tutoriel d’introduction à Git et GitHub, vous apprendrez à maîtriser les fonctionnalités collaboratives avancées de GitHub, telles que les issues, les branches et les pull requests, afin de gérer efficacement vos contributions et celles des autres dans un projet GitHub.

Prérequis#

• Avoir complété l’initiation à Git et GitHub – Partie 2.

• Avoir quelques notions sur l’utilisation d’un terminal.

Objectif final : La mine aux trésors#

Tout au long de cette introduction, nous avons illustré nos propos et nos manipulations via la repository-mine. De manière générale, une mine est créée pour en extraire des minerais, un filon, un trésor… Ne serait-ce pas une bonne idée d’ajouter un trésor à la repository-mine pour lui apporter de la valeur ? Dans cette optique, j’ai créé au sein du repository un fichier nommé Notre_Tresor.md :

# Notre trésor

* "Les limites de l'imagination sont celles qu'on lui impose."

Pour le moment il n’est pas très rempli, je peux vous l’accorder… Mais il s’agit d’une phrase qui me tient à cœur, un principe important sur lequel je fonde ma manière de penser. Comme cette phrase a de la valeur pour moi, je peux la considérer comme un trésor. C’est la première pierre d’un trésor bien plus grand : les suivantes, c’est à vous de les poser !

Le but final est de remplir ce trésor commun avec votre touche personnelle : cela peut être une citation que vous appréciez particulièrement, une phrase qui vous inspire, des pensées ou des mots de qui vous donnent de la motivation au quotidien et que vous souhaitez partager avec autrui. Ce fichier constituera ainsi le cœur du trésor de la repository-mine, enrichi par les contributions de chacun.

Les issues#

Une issue est un espace de discussion associé à un repository. Concrètement, elles permettent de signaler un bug, proposer une amélioration, décrire un problème ou poser une question. Cela aide les contributeurs à avoir une vue globale sur les problèmes et les objectifs liés au repository et à suivre leur résolution au fil du projet.

Sur GitHub, il me suffit de cliquer sur l’onglet “Issues” de mon repository, puis sur “New Issue” :

Voir l'issue sur GitHub.

Dans l’image ci-dessus on peut voir les différentes caractéristiques d’une issue :

• Un titre : “Enrichir notre trésor”. Le titre permet de résumer en une phrase de quoi l’issue traite.
• Une description : Elle permet d’apporter plus de détail au contexte de l’issue, en expliquant ce qui est attendu et en précisant éventuellement les contraintes ou les pistes à suivre.
• Des labels : Ils permettent de catégoriser l’issue. Ici, on a mis le label enhancement, car le but de l’issue est d’apporter une amélioration au repository de base. Le label good first issue indique qu’il s’agit d’une issue idéale pour ceux qui veulent apporter une première contribution au projet.

La prochaine étape est donc de modifier les fichiers concernés afin d’enrichir le trésor commun. Or, le repository ayant été créé par moi-même, vous ne pouvez pas modifier directement le contenu. Plutôt que de donner un à un les droits d’écriture à chacun, GitHub propose un mécanisme alternatif : la fork.

Les forks#

Pour illustrer comment créer une fork, un nouveau contributeur est introduit : Chromatistí.

Chromatistí !

“Forker” un repository consiste à créer une copie complète d’un repository sur votre propre compte GitHub. Cette copie, la fork, vous appartient : vous pouvez y effectuer toutes les modifications que vous souhaitez. C’est le mode de fonctionnement le plus courant pour contribuer à un projet sans en être propriétaire original.

Fork un repository, c'est comme avoir une mine identique à l'originale dans laquelle vous pouvez tout faire !

• Pour créer une fork, Chromatistí va se rendre sur mon repository et appuyer sur le bouton “Fork” :

• Chromatistí vérifie ensuite les informations de sa fork. Les informations par défaut sont celles du repository de référence, mais elles peuvent aussi être modifiées à souhait :

• Chromatistí appuie sur “Create fork” et obtient finalement une repository-mine identique à l’originale (c’est bien son icône qui est à côté du nom du repository) :

Les branches#

Une branche est une ligne de développement parallèle qui permet de travailler sur des modifications sans affecter la version principale du projet. Les branches s’avèrent très utiles lorsque vous souhaitez tester de nouvelles idées, corriger des bugs ou développer de nouvelles fonctionnalités sans impacter le projet original. Ici, la branche sera utilisée pour apporter des modifications au fichier Notre_Tresor.md avant de les intégrer, une fois validées, à la branche principale.

Création de branche#

La commande git checkout -b <nom_de_branche> permet de créer une nouvelle branche. Ainsi, si Chromatistí ouvre un terminal dans son repository local et entre la commande :

git checkout -b mon-tresor

une nouvelle branche nommée mon-tresor et créée et l’y positionne directement. Il est ainsi possible de modifier le fichier Notre_Tresor.md avec une citation, sans altérer la branche principale :

# Notre trésor

* "Les limites de l'imagination sont celles qu'on lui impose."

* "Une image vaut mille mots." – Confucius (Printer’s Ink, 1921).

Pour que les modifications soient effectives dans Git, il faut utiliser les mêmes commandes que dans la partie précédente. La seule subtilité à prendre en compte est l’ajout du flag --set-upstream origin <nom_de_branche> à la commande git push :

git add Notre_Tresor.md
git commit -m "Ajout de mon trésor au bien commun"
git push --set-upstream origin mon-tresor

La branche ainsi que ses modifications associées sont alors visibles sur Github.

Le changement de branche est directement disponible dans l'interface principale.

Ici, on voit que la branche active est "mon-tresor" et que le commit a bien été pris en compte.

La commande git checkout <nom_de_branche>, vous permet de changer de branche active. Par exemple, pour retourner sur la branche principale, il faut écrire :

git checkout main

Vous verrez alors que le fichier Notre_Tresor.md est revenu à son état d’origine.

Vous êtes ici !

Essayez de vous déplacer de branche en branche pour voir les différents changements !

Fusion de branches#

La fusion de branches permet de combiner les modifications de deux branches afin de créer une version unifiée du projet. La commande git merge <nom_de_branche> permet de réaliser cette opération.

Avec Chromatistí, cela donnerait :

git checkout main  # déplacement sur la branche main
git merge mon-tresor

Les modifications effectuées dans la branche mon-tresor apparaissent désormais sur la branche main :

# Notre trésor

* "Les limites de l'imagination sont celles qu'on lui impose."

* "Une image vaut mille mots." – Confucius (Printer’s Ink, 1921).

De manière imagée : on fusionne les deux branches du train pour n'avoir qu'une seule mine.

Lorsqu’une branche est fusionnée, elle peut être supprimée avec la commande git branch -d <nom_de_branche>. Par exemple, pour Chromatistí :

git branch -d mon-tresor

Les manipulations ayant été faites en local, il faut ensuite pousser les modifications sur le repository distant pour qu’elles soient effectives :

git push

Vous avez finalement votre trésor au sein de la mine ! Mais rappelez-vous, les modifications ont été réalisées au sein de votre fork. Il reste encore une dernière étape qui consiste à inclure ces changements au sein du repository principal. C’est le rôle de la pull request.

Les pull requests#

La pull request est un mécanisme fondamental de GitHub qui permet de proposer la fusion de changements d’une branche vers une autre, tout en offrant un espace de discussion et de validation avant leur intégration.

C'est comme demander à relier les deux mines pour n'en avoir qu'une seule.

Tout le processus se passe sur GitHub :

• Dans sa fork, Chromatistí appuie sur le bouton “Contribute”, puis sur “Open pull request”, ce qui lui ouvre une interface dans laquelle il peut écrire un titre et une description à sa proposition :

Pour cet exercice, il peut se contenter d’écrire “Pull request pour l’issue …”. Pour quelle issue ? Il y a deux manières de le préciser :

• En appuyant sur le bouton “Reference” comme indiqué dans l’image ci-dessus.
• En tapant “#” dans le champ de description.

Dans les deux cas, la liste des issues et des anciennes pull requests s’affiche, il suffit alors de sélectionner l’issue qui concerne les modifications (ici, l’issue #2).

Ajouter une description et des références permet d’ajouter du contexte aux modifications apportées, ce qui facilite la compréhension pour le propriétaire originel du repository.

Une fois la pull request créée (“Create pull request”), il ne reste plus qu’à attendre qu’un contributeur (en l’occurrence, moi) vienne la valider :

Et voilà !

Pour aller plus loin#

Tableau récapitulatif des commandes#

Comme pour la partie précédente, ce tableau récapitule l’ensemble des fonctions vues au cours de ce tutoriel ainsi que leur utilité. N’hésitez pas à le garder sous la main au début pour vous familiariser avec les commandes !

Crédits#

• Rédacteur : Ousmane THIONGANE
• Dernière mise à jour : Janvier 2026
• Relecteur :