Git et GitHub : prendre de bonnes habitudes dès le départ

Combien de fois avez-vous vu un dossier de projet ressembler à projet_final, projet_final_v2, projet_final_vrai_final ? Cette gymnastique de sauvegarde manuelle est épuisante et source d’erreurs. Git est l’outil qui met fin à ce désordre. Dans cet article, l’objectif est concret : mettre en place un workflow propre que vous garderez pour toute votre carrière, depuis la création d’un dépôt jusqu’à la pull request, en passant par les commits soignés et le fichier .gitignore.

Pas besoin d’un projet compliqué pour commencer. Une simple page web, un script Python ou un exercice de cours suffisent. L’important est de prendre le bon réflexe maintenant, pendant que les enjeux sont faibles, pour ne pas paniquer le jour où vous travaillerez en équipe sur un vrai produit.

Git et GitHub : deux choses différentes

On confond souvent les deux, alors clarifions. Git est un logiciel installé sur votre machine : il enregistre l’historique de vos fichiers, localement, même sans connexion internet. GitHub est un service en ligne qui héberge vos dépôts Git et permet de collaborer. Vous pouvez très bien utiliser Git sans GitHub. Mais GitHub sans Git n’a aucun sens.

Avant tout, configurez votre identité une seule fois. Chaque commit portera votre nom, c’est essentiel quand on travaille à plusieurs.

git config --global user.name "Awa Ndiaye"
git config --global user.email "awa.ndiaye@example.com"
git config --global init.defaultBranch main

Démarrer un dépôt et faire son premier commit

Placez-vous dans le dossier de votre projet, puis initialisez Git. Le cycle de base tient en trois actions : on modifie des fichiers, on les ajoute à la zone de préparation (staging), puis on enregistre un instantané avec commit.

# Dans le dossier de votre projet
git init

# Voir l'état des fichiers
git status

# Préparer les fichiers à enregistrer
git add index.html style.css

# Enregistrer l'instantané
git commit -m "Ajoute la page d'accueil et sa feuille de style"

La commande git status est votre meilleure amie. Prenez l’habitude de la lancer avant et après chaque action : elle vous dit toujours où vous en êtes.

Écrire des messages de commit qui ont du sens

Un bon message de commit explique pourquoi un changement a été fait, pas seulement quoi. Comparez "modif" ou "fix" avec "Corrige le calcul de la TVA dans la facture". Le second vous sauvera la mise dans six mois, quand vous chercherez quand un bug est apparu. Voici quelques règles simples :

• Commencez par un verbe à l’impératif : « Ajoute », « Corrige », « Supprime ».
• Restez sous 50 caractères pour la première ligne.
• Faites des commits petits et cohérents : un commit = une idée. N’attendez pas la fin de la journée pour tout enregistrer d’un bloc.
• Ne mélangez jamais une correction de bug avec un changement de style ou de mise en forme.

Un commit doit raconter une histoire claire. Si vous avez besoin du mot « et » dans votre message, c’est probablement que vous deviez faire deux commits séparés.

Le piège classique : versionner des fichiers indésirables

Voici l’erreur que presque tous les débutants commettent : envoyer sur GitHub des fichiers qui n’ont rien à y faire. Mots de passe dans un fichier .env, dossier node_modules de plusieurs centaines de mégaoctets, environnements virtuels Python, fichiers temporaires de l’éditeur… Une fois publiés, ils sont visibles par tous et difficiles à effacer de l’historique.

La solution est le fichier .gitignore, à créer avant votre premier commit. Il liste tout ce que Git doit ignorer.

# Dépendances
node_modules/
venv/
__pycache__/

# Secrets et configuration locale
.env
*.key

# Fichiers système et éditeur
.DS_Store
.vscode/
*.log

Conseil pour l’Afrique de l’Ouest, où la connexion est parfois lente et facturée au volume : un .gitignore bien rempli vous évite de pousser des centaines de mégaoctets inutiles. Vous économisez du temps, de la bande passante et du crédit.

Travailler avec des branches

Une branche est une ligne de travail isolée. Plutôt que de bricoler directement sur main (votre version stable), vous créez une branche par fonctionnalité. Si quelque chose casse, votre version principale reste intacte.

# Créer une branche et basculer dessus
git checkout -b ajout-formulaire-contact

# ... vous travaillez, vous committez ...
git add .
git commit -m "Ajoute le formulaire de contact"

# Revenir sur la branche principale
git checkout main

Nommez vos branches clairement : correction-bug-connexion est bien plus parlant que test2. Cette discipline rend le travail d’équipe nettement plus fluide.

Pousser sur GitHub et ouvrir une pull request

Après avoir créé un dépôt vide sur GitHub, reliez-le à votre projet local et envoyez votre travail.

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

# Pour pousser votre branche de fonctionnalité
git push -u origin ajout-formulaire-contact

Une fois la branche poussée, GitHub vous propose d’ouvrir une pull request (PR). C’est une demande de fusion de votre branche dans main. La PR permet à un coéquipier de relire votre code, de commenter, et de valider avant intégration. Même en solo, ouvrir une PR vous force à relire votre propre travail à tête reposée. Décrivez toujours dans la PR ce que vous avez fait et pourquoi : votre futur vous, et vos collègues, vous remercieront.

Récapitulatif

Vous tenez maintenant un workflow solide et professionnel. Les réflexes à ancrer dès aujourd’hui :

• Configurez votre identité Git une fois pour toutes.
• Créez un .gitignore avant le premier commit pour ne jamais publier de secrets ni de fichiers lourds.
• Faites des commits petits, fréquents et au message explicite.
• Travaillez sur des branches, jamais directement sur main.
• Passez par des pull requests pour relire et fusionner.

Ces habitudes ne demandent que quelques minutes de plus par jour, mais elles font toute la différence entre un développeur amateur et un professionnel sur qui on peut compter. Ouvrez un projet, même minuscule, et appliquez ce workflow dès maintenant. C’est en pratiquant que ces gestes deviendront une seconde nature.

Pour aller plus loin

• Déployer sa première application avec Docker — conteneuriser et mettre votre projet en production.
• Automatiser vos tâches répétitives avec Python — scripts utiles, scraping, emails et cron.