Le cycle modifier / commit / push au quotidien
Git, GitHub Desktop et VSCode
Comprendre ce que fait Git, et enregistrer/envoyer vos modifications avec GitHub Desktop ou directement depuis VSCode.
Pré-requis :
Logiciels :
Machines/Outils :
Git garde un historique complet de chaque modification de vos fichiers, et GitHub héberge une copie de cet historique en ligne pour que toute l’équipe travaille sur la même base. Le cycle de base, celui que vous répéterez des dizaines de fois par semaine :
graph LR
A[Modifier des fichiers] --> B[Stage / sélectionner<br/>les changements]
B --> C[Commit : enregistrer<br/>avec un message]
C --> D[Push : envoyer<br/>sur GitHub]
Un dossier partagé écrase les fichiers sans prévenir en cas de modification simultanée. Git garde chaque version dans l’historique et prévient explicitement en cas de conflit — voir Résoudre un conflit Git.
Ouvrez GitHub Desktop, sélectionnez votre repo dans la liste en haut à gauche. L’onglet Changes liste tous les fichiers modifiés depuis le dernier commit, avec un aperçu des lignes ajoutées/supprimées.
Cochez les fichiers à inclure dans ce commit (tous par défaut). En bas à gauche, écrivez un résumé court (impératif, ex. « Ajoute le calcul de vitesse moteur ») et, si besoin, une description plus longue. Cliquez sur Commit to main.
Cliquez sur Push origin en haut. Vos commits sont maintenant visibles par toute l’équipe sur GitHub.com. Avant de commencer à travailler, pensez aussi à cliquer sur Fetch origin pour récupérer les changements des autres.
Onglet History en haut : chaque commit envoyé apparaît dans la liste, avec son message et l’auteur. C’est là que vous retrouvez l’historique complet du projet, et que vous pouvez comparer ce qui a changé à chaque commit.
VSCode intègre les mêmes fonctions sans changer d’application — pratique si vous éditez déjà votre code ou votre documentation dedans. Le cycle est le même que dans GitHub Desktop, juste réparti sur quatre petites actions dans le même panneau.
Cliquez sur l’icône de branches dans la barre latérale gauche (ou Ctrl+Shift+G). Les fichiers modifiés apparaissent sous Modifications, avec une icône M (modifié).
Survolez un fichier et cliquez sur le + pour le stager (ou le + en haut de la liste Modifications pour tout stager d’un coup). Les fichiers passent alors dans une section Changements indexés séparée.
Tapez votre message de commit dans le champ de texte en haut du panneau, puis cliquez sur Validation (le bouton bleu ✓).
Une fois le commit fait, le bouton devient Synchroniser les modifications (avec le nombre de commits en attente) : cliquez dessus pour push (et pull en même temps). Le panneau Graphique (GitLens) en bas confirme le commit envoyé, relié à main.
Des commits petits et fréquents, avec un message précis, valent mieux qu’un commit géant en fin de journée avec le message « avancement ». Un commit doit correspondre à un changement cohérent qu’on pourrait résumer en une phrase.
| Symptôme | Cause probable | Solution |
|---|---|---|
| “Push” échoue avec une erreur de rejet | Quelqu’un d’autre a push avant vous, votre historique local est en retard | Faites Fetch origin puis Pull, réglez les conflits éventuels (voir le guide dédié), puis repush |
| Un fichier que vous ne voulez pas suivre apparaît dans Changes | Fichier généré ou temporaire non exclu | Ajoutez-le à .gitignore |
| Le bouton Commit reste grisé | Aucun message de commit écrit, ou aucun fichier staged | Vérifiez les deux |
Si vous voulez une explication plus posée, en vidéo, des concepts vus ici (dépôt, branche, fork, pull request…) : Git and GitHub for Poets, une série de 11 courtes vidéos par The Coding Train, en anglais mais très accessible même sans vocabulaire technique de départ.
Modifiez n’importe quel fichier de votre repo (par exemple, ajoutez une
ligne dans docs/objectifs.md), puis faites le cycle complet : stage,
commit avec un message précis, push. Vérifiez sur GitHub.com que votre
commit apparaît bien dans l’historique du repo.