Initialisation d’un dépôt

git init
git config user.name "Aminata Diop"
git config user.email "aminata@exemple.sn"
git remote add origin git@github.com:org/projet.git

# .gitignore minimal
cat > .gitignore << 'EOF'
node_modules/
.env
dist/
*.log
.DS_Store
EOF

Workflow de base (add / commit / push)

git status
git add src/ tests/
git diff --staged
git commit -m "feat(billing): calcul TVA 18% SYSCOHADA"
git push -u origin main

Branches et pull requests

git switch -c feat/export-pdf
# ... modifs ...
git add -A && git commit -m "feat: export facture PDF"
git push -u origin feat/export-pdf

# Via gh (GitHub CLI)
gh pr create --title "Export PDF factures" --body "Closes #142"
gh pr view --web

Récupérer les changements de l’équipe

git fetch origin
git status           # indique: votre branche est en retard de N commits
git pull --rebase    # rebase préféré à merge pour l'historique linéaire
# Conflit ? Git indique les fichiers en UU
git add fichier-resolu.js
git rebase --continue

Annuler une modification

# Dé-stager un fichier
git restore --staged fichier.js

# Annuler les modifs non commitées (destructif)
git restore fichier.js

# Revenir au commit précédent en gardant les modifs
git reset --soft HEAD~1

# Annuler un commit poussé (crée un commit inverse, sûr)
git revert <sha>

Historique et recherche

git log --oneline --graph --decorate --all | head -20
git log -p -- src/billing.js
git blame src/billing.js
git show HEAD~3

# Chercher dans tous les commits
git log -S "calculTVA" --oneline
git grep "TODO" $(git rev-list --all)

Stash : mettre de côté

git stash push -m "WIP: refactor users"
git switch main   # intervention urgente
# ...
git switch feat/xxx
git stash pop

Tags et releases

git tag -a v1.2.0 -m "Release 1.2.0 - export PDF, i18n wolof"
git push --tags

# Via gh
gh release create v1.2.0 --notes-from-tag
gh release upload v1.2.0 dist/app.zip

Collaboration GitHub : forks et PR

gh repo fork org/projet --clone
cd projet
git switch -c fix/typo-readme
# ... modifs ...
git commit -am "docs: fix typo"
gh pr create

GitHub Actions minimale

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage

Conventions de commits

feat:     nouvelle fonctionnalité
fix:      correction de bug
docs:     documentation
refactor: refactor sans changement fonctionnel
test:     ajout/modif tests
chore:    maintenance, deps

feat(billing): ajoute acompte 30%
fix(auth): rejette les tokens expirés
BREAKING CHANGE: renomme /v1/ en /v2/

Étape 1 : installer Git et configurer son identité

Git ne sert à rien sans une identité d’auteur. Chaque commit est signé avec un nom et un email, et c’est ce qui permet à un lead dev à Dakar de retracer qui a touché à quelle ligne dans une équipe distribuée. Avant de cloner quoi que ce soit, on installe et on configure.

Sous Ubuntu ou WSL, l’installation tient en une commande ; sous Windows on utilise Git for Windows depuis git-scm.com. Une fois installé, ouvrez un terminal et tapez les commandes suivantes en remplaçant les valeurs par les vôtres.

git --version
git config --global user.name "Mamadou Diallo"
git config --global user.email "mamadou@exemple.sn"
git config --global init.defaultBranch main

La première ligne doit renvoyer quelque chose comme git version 2.43.0. Si la commande échoue, l’installation n’a pas pris. La dernière configuration force Git à créer la branche principale sous le nom main à chaque git init, alignement avec la convention GitHub depuis 2020.

Étape 2 : initialiser un dépôt local et faire son premier commit

Un dépôt Git est un dossier qui contient un sous-dossier caché .git/. C’est là que vit l’historique. On peut transformer n’importe quel dossier existant en dépôt avec git init, puis enregistrer un instantané initial.

Plaçons-nous dans un projet vide et déroulons les commandes ci-dessous.

mkdir mon-projet && cd mon-projet
git init
echo "# Mon projet" > README.md
git add README.md
git commit -m "chore: premier commit"

Après git commit, Git affiche un identifiant court de 7 caractères et le message du commit. C’est le signal que l’instantané est bien archivé. git log --oneline permet de relire cet historique : vous devez voir une seule ligne avec votre commit initial.

Étape 3 : créer un dépôt distant sur GitHub et le lier

Le dépôt local n’a pas de sauvegarde tant qu’il vit seul sur votre machine. Un disque SSD qui lâche au bureau d’Almadies, et le projet disparaît. GitHub fournit un dépôt distant gratuit pour héberger l’historique et collaborer.

Connectez-vous sur github.com, cliquez sur New repository, donnez le nom mon-projet, laissez la case « Initialize with README » décochée pour éviter un conflit, puis créez. GitHub affiche une URL au format https://github.com/votrelogin/mon-projet.git. Liez-la au dépôt local et poussez le commit.

git remote add origin https://github.com/votrelogin/mon-projet.git
git branch -M main
git push -u origin main

À la première poussée HTTPS, GitHub demande un Personal Access Token, pas votre mot de passe — politique en vigueur depuis le 13 août 2021. Générez-le dans Settings puis Developer settings puis Tokens (classic) avec le scope repo. Collez-le quand le terminal demande le password. La sortie se termine par branch 'main' set up to track 'origin/main' : la liaison est faite.

Étape 4 : travailler en branches pour ne pas casser main

Le tronc main doit rester stable et déployable. Toute nouvelle fonctionnalité ou correction se développe dans une branche dédiée, qu’on fusionne ensuite via une pull request une fois validée. C’est la règle d’or des équipes qui livrent en production sans rouler sur leurs propres pieds.

Pour créer une branche et y basculer en une seule commande, utilisez git switch -c, recommandé depuis Git 2.23.

git switch -c feat/page-contact
touch contact.html
git add contact.html
git commit -m "feat: ajoute page contact"
git push -u origin feat/page-contact

Après le push, GitHub affiche un encart en haut du dépôt avec un bouton « Compare & pull request ». Cliquez dessus, rédigez un titre et une description claire en français — l’équipe à Cotonou et celle à Lomé doivent comprendre l’intention sans deviner — puis créez la pull request.

Étape 5 : relire le code, fusionner et nettoyer

Une pull request n’est pas une formalité, c’est une revue de code. Le mainteneur lit la diff, commente les lignes problématiques, demande des ajustements. Vous corrigez localement, refaites un commit sur la même branche et repoussez : la PR se met à jour automatiquement.

Quand la revue est verte, on fusionne avec le bouton Merge pull request sur GitHub, ou en ligne de commande comme ci-dessous.

git switch main
git pull
git branch -d feat/page-contact
git push origin --delete feat/page-contact

La branche locale et la branche distante sont supprimées une fois fusionnées. git log --oneline --graph sur main montre désormais le commit de la PR intégré au tronc. Cette hygiène évite l’accumulation de branches mortes qu’on retrouve sur les vieux dépôts mal entretenus.

Étape 6 : gérer les conflits sans paniquer

Un conflit arrive quand deux branches modifient les mêmes lignes. Git ne devine pas quelle version garder et marque le fichier avec des balises <<<<<<<, =======, >>>>>>>. La première fois, c’est déstabilisant ; après deux ou trois résolutions, ça devient une routine.

Quand vous lancez git pull et que Git annonce un conflit, ouvrez le fichier dans VS Code. L’éditeur affiche les options « Accept Current », « Accept Incoming », « Accept Both ». Choisissez la version correcte ou éditez à la main, supprimez les balises, sauvegardez, puis terminez la fusion.

git add fichier-en-conflit.js
git commit
git push

Le commit de fusion est enregistré et la branche est de nouveau alignée avec le distant. Évitez à tout prix le git push --force sur main : c’est la méthode la plus rapide pour effacer le travail de l’équipe.

Étape 7 : aller plus loin avec les alias et GitHub CLI

Quand on tape Git toute la journée, raccourcir les commandes fait gagner du temps. Les alias se configurent une fois et durent toute la vie de la machine. GitHub CLI (gh) ajoute par-dessus la possibilité de créer des PR sans passer par le navigateur.

Voici une configuration de démarrage qui couvre 80 % des usages quotidiens d’un dev à Niamey ou Conakry.

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.lg "log --oneline --graph --decorate"
gh auth login
gh pr create --fill

git st remplace git status, git lg affiche un graphe lisible. gh pr create --fill ouvre une pull request avec le titre et la description tirés automatiquement des derniers commits. Vous restez dans le terminal du début à la fin du flux : moins d’aller-retour navigateur, plus de focus sur le code. À lire ensuite sur le déploiement automatisé, voir notre tutoriel d’automatisation business et le tutoriel JavaScript ES2024.

Mettre en place des hooks pre-commit pour proteger la qualite

Un hook pre-commit est un script execute automatiquement par Git juste avant qu’un commit soit valide. Pour un developpeur a Abidjan ou a Lome qui livre du code Python ou JavaScript, c’est le filet de securite qui empeche d’envoyer en production une faute de frappe, une cle API en clair ou un fichier non formate. L’outil de reference s’appelle pre-commit (oui, le nom du concept et de l’outil sont identiques), il s’installe en une commande pip install pre-commit puis se configure via un fichier .pre-commit-config.yaml a la racine du depot.

Le fichier de configuration declare une liste d’hooks tires de depots publics maintenus par la communaute : black ou ruff pour Python, prettier pour JavaScript, detect-secrets pour reperer les credentials oublies, end-of-file-fixer pour normaliser les fins de fichiers. Une fois la configuration validee, lancez pre-commit install : Git executera desormais ces hooks a chaque tentative de commit et bloquera l’operation si un controle echoue, en proposant souvent une correction automatique a re-stager.

Le retour sur investissement est rapide : sur une equipe de trois developpeurs, le temps gagne en code review pour les sujets de forme depasse largement les quinze minutes d’installation initiale. Documentez le contenu du fichier de configuration dans le README du depot pour faciliter l’onboarding des nouveaux contributeurs.

Lancer une integration continue minimale avec GitHub Actions

L’integration continue (CI) consiste a executer automatiquement, a chaque push, une serie de controles : lint, tests unitaires, build. GitHub Actions propose 2 000 minutes gratuites par mois sur les depots prives et un quota illimite sur les depots publics, largement suffisant pour une PME ouest-africaine ou une equipe de trois developpeurs. La configuration tient dans un fichier YAML place dans .github/workflows.

Pour un projet Node.js typique, le workflow minimal lance les tests sur Node 22 LTS apres un npm ci puis un npm test. Pour Python, on remplace par pip install -r requirements.txt suivi de pytest. Ajoutez une matrice qui teste plusieurs versions du langage si vos clients tournent sur des environnements heterogenes, par exemple Node 20 et 22 en parallele pour anticiper la fin de support de Node 20 prevue pour avril 2026.

L’erreur classique est de surcharger la CI de tests longs des le premier jour. Commencez petit : un job lint et un job tests qui prennent moins de cinq minutes chacun. Ajoutez ensuite, par paliers, le calcul de la couverture de code, les tests d’integration, et le scan de securite avec des outils comme Trivy ou Snyk.

Strategie de tagging semver pour des releases lisibles

Le versionnage semantique (semver) suit le format MAJEUR.MINEUR.PATCH ou chaque chiffre porte un sens precis : MAJEUR change a chaque rupture de compatibilite, MINEUR a chaque ajout de fonctionnalite retrocompatible, PATCH a chaque correctif. Adopter cette convention transforme la conversation avec vos clients : au lieu d’expliquer ce qui a change, vous communiquez juste un numero et tout le monde comprend l’ampleur du changement.

Cote outillage, taggez chaque release dans Git avec git tag -a v1.2.3 -m « description courte » puis git push –tags. GitHub detectera automatiquement le tag et permettra de generer une page Releases avec le changelog et les binaires associes. Dans la continuité, automatisez la generation du changelog avec un outil comme release-please ou semantic-release qui parsent les messages de commit conventionnels (feat:, fix:, BREAKING CHANGE) pour produire la version et les notes de release.

Tenez un fichier CHANGELOG.md a la racine du depot avec une section par version, dates et bullet points lisibles par un humain non technique. C’est ce document que les chefs de projet et les equipes support consulteront en priorite. Pour un panorama plus complet du tooling, consultez notre tutoriel Git et GitHub qui pose les bases necessaires.