Git et GitHub au Maroc : prouver ses compétences sur son CV et en entretien

Décrire son niveau avec précision

Évitez les mentions isolées comme « maîtrise de Git » ou « expert GitHub » si elles ne sont pas accompagnées d’exemples. Un recruteur peut demander ce que vous entendez par là : avez-vous seulement cloné un dépôt et enregistré des modifications, ou avez-vous aussi travaillé avec des branches, des revues et des résolutions de conflits ? Votre formulation doit correspondre à ce que vous pouvez refaire et expliquer.

Distinguez les deux outils dans votre description. Git concerne le versionnage et l’historique du code ; GitHub est une plateforme de collaboration où l’on peut notamment organiser des dépôts et proposer des changements au moyen de pull requests. Présenter les deux comme une compétence uniforme peut masquer des lacunes : on peut être à l’aise avec les commandes Git tout en ayant peu pratiqué la revue de code sur GitHub, ou l’inverse.

Choisissez des verbes d’action adaptés à votre expérience : « créer », « consulter », « comparer », « fusionner », « documenter », « relire », « résoudre ». Mentionnez le contexte — projet personnel, exercice encadré, stage ou équipe — et ne présentez pas un exercice comme une expérience professionnelle.

Exemples de formulations CV selon différents niveaux :

• Débutant : « Utilisation de Git pour initialiser ou cloner un dépôt, enregistrer des modifications avec des commits et publier un projet personnel sur GitHub. »

• Niveau autonome sur un projet : « Création de branches par fonctionnalité, fusion des changements et résolution de conflits simples sur un projet web personnel. » N’utilisez cette formulation que si vous avez effectivement effectué ces opérations et savez les expliquer à l’oral. Git permet de travailler sur des branches séparées, puis de réunir les changements ; savoir raconter ce cheminement apporte davantage qu’un adjectif de niveau. ([git-scm.com](

• • Pratique collaborative : « Contribution à un dépôt d’équipe via des pull requests, avec description des changements et prise en compte des retours de revue. »
• • Si vous avez touché à l’intégration continue, précisez ce que vous avez configuré ou utilisé au lieu de revendiquer une maîtrise générale de la CI/CD.
• • Si vous connaissez une notion mais ne l’avez pas appliquée, dites « notions de… » et préparez-vous à distinguer théorie et pratique.

Choisir des preuves vérifiables

Un portfolio Git et GitHub n’a pas besoin d’être volumineux. Un projet terminé et compréhensible vaut souvent mieux qu’une collection de dépôts incomplets. L’objectif est de permettre à une personne qui ne vous connaît pas de comprendre le problème traité, votre contribution et les étapes du travail, sans qu’elle ait à deviner.

Dans un dépôt public, soignez d’abord les éléments d’entrée : un nom explicite, une courte description, un fichier README qui explique l’objectif, les prérequis, le lancement et les limites connues. Ajoutez des exemples d’utilisation ou des captures d’écran si elles aident à comprendre le résultat. Faites en sorte que le projet puisse être consulté sans dépendre de votre présence pour l’expliquer.

La preuve de votre pratique de Git ne se réduit pas au nombre de commits. Un historique cohérent, avec des messages informatifs et des changements regroupés par intention, peut servir de support à une discussion. Vous pouvez aussi présenter une branche de fonctionnalité, une pull request avec une description claire, un échange de revue, ou un conflit que vous avez résolu et dont vous comprenez l’origine. Les pull requests sont conçues pour proposer, discuter et intégrer des changements ; elles offrent donc une trace concrète de collaboration. ([docs.github.com](

Liste de preuves tangibles adaptées à Git et GitHub :

• • Un dépôt de projet personnel accessible, avec README, consignes de lancement et état du projet clairement indiqué.
• • Un historique de commits dont les messages expliquent les changements plutôt que de répéter « update » ou « fix » sans précision.
• • Une branche séparée pour une fonctionnalité ou une correction, avec une fusion que vous pouvez commenter.
• • Une pull request qui présente le besoin, les modifications effectuées, les tests lancés et les points à vérifier.
• • Un exemple de revue de code : commentaire formulé, réponse apportée et modification éventuelle, sans exposer de conversation privée.
• • Une démonstration d’un conflit résolu, accompagnée d’une explication de la comparaison des versions avant la fusion.
• • Si c’est pertinent pour votre poste, un dépôt où l’on peut observer les contrôles automatiques ou les règles de protection configurés. GitHub permet, selon les réglages et les fonctionnalités disponibles, d’exiger des revues ou des contrôles avant la fusion

Rédiger une expérience ou un projet sur son CV

Pour chaque ligne, essayez d’associer une action, un contexte et un résultat vérifiable. Le résultat n’a pas nécessairement besoin d’être un chiffre : une fonctionnalité intégrée, une documentation produite ou un processus de contribution clarifié sont des résultats descriptibles. N’inventez pas de mesure d’impact si vous ne pouvez pas l’expliquer.

Exemple de projet personnel : « Développé une petite application de suivi de dépenses ; structuré le travail en branches, documenté l’installation dans le README et regroupé les changements par fonctionnalité dans Git. » Cette phrase doit refléter votre dépôt réel. Si vous avez travaillé seul, ne suggérez pas une revue d’équipe ou une intégration par pull request que vous n’avez pas pratiquée.

Exemple de contribution en équipe : « Contribué au module de recherche d’un projet de groupe ; proposé les changements dans une pull request, intégré les retours de revue et résolu les conflits avec la branche principale. » Remplacez « module de recherche » par votre contribution précise et ne vous attribuez pas le travail des autres.

Sur le CV, indiquez un seul lien vers un portfolio ou un dépôt représentatif si vous pouvez le partager. Vérifiez avant l’envoi que le lien s’ouvre, que le README est à jour et que le projet ne contient pas de fichiers sensibles. Pour un travail confidentiel, décrivez les pratiques utilisées sans publier le dépôt ni copier des extraits de code appartenant à l’entreprise.

• À éviter : « Expert Git/GitHub » sans preuve ; « gestion de projet » si vous avez seulement contribué à une branche ; une longue liste de commandes sans contexte.
• À privilégier : « Utilisé Git pour versionner un projet de formation, créer des branches de travail et fusionner une fonctionnalité après vérification. »
• Pour un CV marocain en français, adaptez la formulation à l’annonce et au poste visé, sans reprendre des exigences que vous n’avez pas réellement pratiquées.

Préparer une démonstration courte

En entretien technique Git et GitHub, une démonstration n’est pas un tour complet de la plateforme. Choisissez un projet petit et stable, ouvrez le dépôt avant l’entretien et répétez le parcours. Si la connexion ou le partage d’écran échoue, préparez une explication orale de secours. Une démonstration courte doit faire ressortir votre raisonnement, pas votre vitesse de frappe.

• Trame de présentation orale d’un projet :
• 1. « Le besoin était… » Décrivez en une phrase le problème ou l’objectif du projet.
• 2. « Ma contribution était… » Distinguez votre travail de celui d’un binôme, d’une équipe ou d’un tutoriel suivi.
• 3. « J’ai organisé le travail ainsi… » Montrez une branche, quelques commits et, si elle existe, la pull request correspondante.
• 4. « J’ai choisi cette démarche parce que… » Expliquez comment vous avez limité la taille des changements ou facilité leur revue.
• 5. « Le point difficile était… » Racontez un conflit, une erreur ou un retour reçu, puis la façon dont vous l’avez traité.
• 6. « Voici ce que je ferais ensuite… » Présentez une amélioration réaliste, par exemple enrichir les tests ou clarifier la documentation.

Répondre aux questions techniques

Pour répondre à une question, utilisez une séquence simple : décrivez le contexte, expliquez les étapes, justifiez votre choix et précisez le résultat ou ce que vous vérifieriez ensuite. Si vous ne connaissez pas une commande ou une option, dites-le clairement et expliquez comment vous chercheriez la réponse sans risquer d’écraser le travail partagé.

Préparez-vous à expliquer la différence entre une branche et un commit, ce qui se passe quand deux changements touchent la même partie d’un fichier, et la manière dont vous vérifiez le résultat d’une fusion. Selon le poste, l’échange peut aussi porter sur les pull requests, la revue de code ou les protections d’une branche. GitHub documente des règles pouvant encadrer les revues, les contrôles requis et les possibilités de fusion ; ne prétendez pas avoir configuré ces règles si vous les avez seulement consultées. ([docs.github.com](

Une erreur bien racontée peut démontrer votre méthode. Par exemple : « J’ai constaté que deux branches avaient modifié la même zone ; j’ai comparé les changements, conservé les deux intentions nécessaires, relancé la vérification du projet et demandé une revue avant de continuer. » Adaptez cet exemple à une situation réellement vécue ; ne le présentez pas comme votre expérience si ce n’est qu’un scénario d’entraînement.

• Si l’on vous demande ce que vous feriez face à un conflit, commencez par expliquer comment vous identifiez les fichiers concernés et comparez les versions.
• Si vous n’avez jamais utilisé une fonctionnalité évoquée, dites-le, puis précisez ce que vous connaissez et comment vous apprendriez à l’utiliser.
• Ne récitez pas une procédure sans expliquer le risque qu’elle évite : l’entretien évalue aussi votre compréhension des effets sur le travail partagé.

Éviter les signaux qui fragilisent sa candidature

Un niveau gonflé se repère rapidement lorsqu’une question de suivi dépasse votre expérience. Préférez une description plus modeste, mais défendable. De même, un dépôt public sans instructions, avec des fichiers manquants ou un historique que vous ne savez pas commenter ne renforce pas nécessairement une candidature.

Avant de publier ou de partager un projet, vérifiez les droits de diffusion et les règles applicables à votre employeur, votre école ou votre client. Ne publiez pas de code propriétaire, de données personnelles, d’identifiants, de clés d’accès, de fichiers de configuration sensibles, de captures d’écran internes ou de noms de clients non autorisés. Retirer ensuite un fichier ne garantit pas que toutes ses traces aient disparu de l’historique.

Si un projet professionnel ne peut pas être montré, vous pouvez expliquer les pratiques sans divulguer le contenu : comment les branches étaient nommées, quel était votre rôle dans les revues, comment vous traitiez les conflits ou quelles vérifications précédaient une fusion. Vous pouvez aussi créer un projet d’exemple distinct, avec des données fictives et du code écrit par vous.

Enfin, ne faites pas du nombre de contributions visibles ou de la fréquence d’activité votre preuve principale. Choisissez plutôt quelques exemples que vous pouvez ouvrir, expliquer et relier aux besoins du poste.

• • Évitez les données confidentielles, secrets et fichiers internes dans un dépôt public ou une démonstration enregistrée.
• • Ne publiez que du code que vous avez le droit de partager ; vérifiez les licences et les consignes de l’organisation.
• • Préparez une version anonymisée ou un projet personnel de démonstration si le travail professionnel est confidentiel.
• • Vérifiez les liens, les instructions de lancement et l’absence d’informations sensibles avant chaque candidature.

Le parcours, étape par étape

1. 11. Faire l’inventaire de sa pratique — Notez les opérations Git et GitHub que vous avez réellement réalisées, puis classez-les en notions, pratique autonome et expérience collaborative. Gardez une formulation prudente pour ce que vous n’avez pas encore appliqué.
2. 22. Choisir un projet démontrable — Retenez un projet que vous pouvez expliquer du besoin jusqu’au résultat. Vérifiez vos droits de diffusion et supprimez les données ou fichiers sensibles avant toute publication.
3. 33. Rendre le dépôt compréhensible — Clarifiez le README, l’installation, les limites connues et le rôle que vous avez joué. Vérifiez que l’historique et les exemples soutiennent les affirmations de votre CV.
4. 44. Adapter le CV à l’offre — Associez une action à un contexte concret et à un résultat que vous pouvez défendre. Ajoutez le lien vers un dépôt pertinent seulement s’il est accessible et prêt à être consulté.
5. 55. Répéter la démonstration et les questions — Présentez le projet en quelques étapes, préparez un exemple de difficulté réellement rencontrée et exercez-vous à expliquer vos choix sans réciter une liste de commandes.
6. 66. Combler une lacune ciblée — Si votre expérience se limite au versionnage individuel, entraînez-vous sur un projet personnel à créer une branche, proposer une pull request, commenter un changement et résoudre un conflit. Décrivez ensuite honnêtement cette pratique comme un exercice.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Git - Branches in a Nutshell, Pro Git git-scm.com
2. Git - Basic Branching and Merging, Pro Git git-scm.com
3. GitHub Docs - Pull requests documentation docs.github.com
4. GitHub Docs - About protected branches docs.github.com
5. Fiche de poste publiée sur Emploi public emploi-public.ma
6. Formation Gestion du code Git / GitHub, B&D University api.gescof.com
7. Git et GitHub pour les équipes, FormaGroup formagroup.ma
8. Azure DevOps et pipelines CI CD, FormaGroup formagroup.ma