Tacite WAKILONGO

Posted on Feb 25 • Edited on Feb 28

🚀 Contribuer en Open Source avec Git & GitHub : Le Guide Ultime du Workflow Pro

#git #opensource #kadea #devops

🚀 Contribuer en Open Source : Le Guide Ultime du Workflow Pro

Contribuer à un projet open source, ce n’est pas seulement "envoyer du code". C’est intégrer une organisation collaborative mondiale. Pour réussir, il ne faut pas seulement savoir coder, il faut savoir communiquer et respecter des standards.

L’open source ne récompense pas seulement les meilleurs codeurs.
Il récompense les développeurs organisés.
Ceux qui savent collaborer proprement.

Prenons une analogie pour tout comprendre...

🏗️ L'analogie du "Chantier Communautaire"

Imagine un immense projet de construction d'un hôpital public.

Le dépôt (Repository) principal = Le bâtiment officiel en construction.
L’architecte (Mainteneur) = Celui qui valide les plans et la qualité.
Les artisans (Contributeurs) = Toi et des centaines d'autres.
Le cahier des charges (Issues) = La liste des pièces à construire ou des fuites à réparer.
Le permis de construire (Pull Request) = Ta proposition de modification soumise à l'architecte.

1️⃣ Étape 0 : L'étiquette (Ne travaillez pas pour rien !)

Avant de coder, vérifiez le cahier des charges.

Consultez les Issues : Cherchez les labels good first issue (idéal pour débuter).
Communiquez : Laissez un commentaire sur l'issue : "Je souhaite travailler sur ce sujet, pouvez-vous me l'assigner ?".
Proposez : Si vous avez une idée neuve, créez une issue avant de coder pour voir si l'architecte est d'accord.

👉 C’est comme demander si on a besoin d'un électricien avant de commencer à poser des câbles.

2️⃣ Étape 1 : Le Fork (Ta copie privée)

Sur GitHub, cliquez sur le bouton Fork.
Cela crée une copie exacte du projet sur ton propre compte GitHub. Tu es désormais le roi de cette copie, tu peux tout casser sans risquer d'abîmer le projet officiel.

3️⃣ Étape 2 : Le Clone & l'Upstream (Préparer son bureau intelligemment)

Ramène le projet sur ton ordinateur :

git clone <url-de-ton-fork>

⚠️ Ce que beaucoup ne comprennent pas :
Quand tu clones ton fork, Git configure automatiquement un remote appelé : origin.
👉 origin = Ton dépôt GitHub personnel (ton fork). C’est là que tes push iront par défaut.

🔎 L’étape cruciale (souvent oubliée) :
Ajoute une connexion vers le dépôt original (celui de l'owner) pour pouvoir récupérer les mises à jour des autres :

git remote add upstream <url-du-repo-original>

📡 Ce que tu viens de créer :
Si tu tapes git remote -v, tu verras :

origin (https://github.com/ton-compte/nom_du_repo.git) -> Lecture + Écriture.
upstream (https://github.com/owner/nom_du_repo.git) -> Lecture principalement.

🧠 Comprendre avec un schéma :

                 (Repo Officiel)
                    upstream
                        ↑
                        |
   (Ton repo local) ----+----> origin (Ton Fork sur GitHub)

🏗️ Analogie chantier :

origin = Ton entrepôt personnel.
upstream = Le chantier principal.
git remote add upstream = Installer un talkie-walkie pour écouter les annonces du chantier officiel.

🎯 Pourquoi on ajoute upstream ?
Pour rester à jour pendant que tu travailles :

git fetch upstream
git rebase upstream/main

💡 Les équipes avancées préfèrent **rebase* pour garder un historique propre et linéaire.*

4️⃣ Étape 3 : Installation & README

Ne fonce pas dans le code !

Lis le README.md : Il contient l'architecture et les règles de l'architecte.
Installe les outils : npm install.
Vérifie que le projet se lance : Tu dois partir d'une base saine.

5️⃣ Étape 4 : La Branche (La zone d'isolation)

Règle d'or : On ne travaille jamais sur la branche main. Jamais.
Crée une branche avec un nom clair :

git checkout -b feat/ajout-formulaire-client

👉 C’est comme construire une maquette de la pièce dans ton atelier avant de la poser sur le vrai bâtiment.

6️⃣ Étape 5 : Coder & Respecter les standards

Pendant que tu codes, respecte le style du projet (Linting, Prettier).
Les "Conventional Commits" : Pour que l'historique soit propre, utilise des messages clairs :

feat: ... (nouvelle fonctionnalité)
fix: ... (correction de bug)

7️⃣ Étape 6 : La Qualité (Husky & Tests)

Avant de partager ton travail, assure-toi qu'il est parfait.

Lance les tests : npm test.
Nettoie ton code : Supprime les console.log. Si le projet utilise Husky (comme MariaSaaS), ton commit sera bloqué automatiquement si ton code est "sale" (ex: présence de any).

8️⃣ Étape 7 : Synchronisation (Éviter les conflits)

Avant l'envoi, assure-toi d'avoir intégré les derniers changements de l'architecte (voir Étape 2 avec fetch et rebase).

9️⃣ Étape 8 : Le Push & la Pull Request (La proposition officielle)

Ton travail est prêt, synchronisé et tes tests passent. Maintenant, tu envoies ton travail vers ton fork, pas vers le repo officiel :

git push origin feat/ajout-formulaire-client

🧠 Schéma clair du flux réel :

      Tu codes ici
      (Local branch)
             |
             v
     git push origin
             |
             v
     Ton Fork (GitHub)
             |
             v
     Pull Request  ----->  Repo Officiel (Upstream)

🏗️ Analogie chantier :
Le push = tu envoies ta maquette à ton entrepôt (origin).
La Pull Request = tu demandes à l’architecte : “Est-ce que ma pièce peut être intégrée au bâtiment officiel ?”

🎯 La Pull Request (moment stratégique) :
Sur GitHub, clique sur "Compare & Pull Request". Pour être accepté :

✅ Explique clairement le problème et ta solution.
✅ Ajoute des captures d'écran si tu as touché à l'interface.
✅ Mentionne l’issue liée (ex: Closes #12).

🔟 Étape 9 : La Revue de Code (Le dialogue)

L'architecte va lire ton code. Il peut :

Valider : 🎉 Ton code est fusionné !
Demander des modifs : Ne le prends pas personnellement ! Modifie ton code localement, refais un commit et un push, la PR se mettra à jour toute seule.