GitHub pour débuter : organiser ses versions et collaborer sur un projet web

Un dossier de projet copié sur plusieurs ordinateurs, des fichiers renommés « version finale », puis « version finale 2 » : cette méthode atteint vite ses limites. GitHub permet de conserver l’historique d’un projet, de revenir à une version stable et de coordonner plusieurs contributeurs, à condition de comprendre la différence entre Git et GitHub et d’adopter un flux de travail simple.

Ce guide s’adresse aux débutants qui développent un site, un script ou une petite application. L’objectif n’est pas de couvrir toutes les fonctions de la plateforme, mais de mettre en place une organisation fiable dès le premier projet.

Git et GitHub ne désignent pas la même chose

Git est un système de gestion de versions installé sur votre ordinateur. Il observe les modifications apportées aux fichiers et permet d’enregistrer des états successifs du projet. Ces enregistrements sont appelés des commits.

GitHub est une plateforme en ligne qui héberge des dépôts Git. Elle ajoute des fonctions de collaboration : partage du code, gestion des droits, demandes de fusion, suivi des problèmes et consultation de l’historique depuis un navigateur.

Vous pouvez donc utiliser Git sans GitHub, par exemple pour suivre localement l’évolution d’un projet. En revanche, GitHub s’appuie sur Git pour stocker et synchroniser les versions. Cette distinction explique pourquoi une modification enregistrée localement n’apparaît pas automatiquement sur le dépôt en ligne.

Préparer un dépôt propre avant le premier commit

Un dépôt est l’espace qui contient l’historique et les fichiers d’un projet. Avant de le créer, rassemblez les éléments utiles dans un dossier clairement nommé. Un petit site peut par exemple contenir index.html, un dossier css, un dossier js et un fichier README.md.

Le fichier .gitignore mérite une attention particulière. Il indique à Git quels fichiers ne doivent pas être suivis. On y place généralement les dépendances installées automatiquement, les fichiers temporaires, les journaux et les secrets locaux. Une clé d’API, un mot de passe ou un fichier de configuration contenant des données privées ne doit jamais être envoyé dans un dépôt partagé.

Depuis le dossier du projet, l’initialisation locale peut se faire avec les commandes suivantes :

git init
git add .
git commit -m "Initialiser le projet"

git init crée le dépôt local. git add prépare les fichiers à enregistrer et git commit crée un point de sauvegarde accompagné d’un message. Le commit ne constitue pas encore une publication sur GitHub : il reste sur votre ordinateur tant qu’il n’est pas envoyé vers un dépôt distant.

Créer des commits utiles plutôt qu’un historique illisible

Un commit devrait correspondre à une modification compréhensible : ajouter une page, corriger l’affichage mobile ou modifier la validation d’un formulaire. Évitez de regrouper plusieurs fonctionnalités sans rapport dans le même enregistrement. Un historique découpé avec logique est beaucoup plus facile à relire ou à annuler.

Les messages doivent décrire l’action réalisée, et non l’état émotionnel du projet. « Corriger le menu sur mobile » est plus utile que « changements » ou « ça devrait marcher ». Il n’est pas nécessaire d’écrire une longue description pour chaque modification, mais le message doit permettre de comprendre rapidement l’intention.

Avant de valider, vérifiez ce que Git s’apprête à enregistrer :

git status
git diff

git status indique les fichiers modifiés, ajoutés ou non suivis. git diff affiche le détail des changements. Cette vérification évite d’inclure par erreur un fichier temporaire ou une modification inachevée.

Relier le projet local à GitHub

Après avoir créé un compte GitHub, vous pouvez créer un dépôt vide depuis l’interface de la plateforme. Pour un projet déjà présent sur votre ordinateur, il est préférable de ne pas générer automatiquement un second README ou d’autres fichiers qui pourraient provoquer un conflit lors du premier envoi.

GitHub fournit ensuite une adresse de dépôt. Elle peut être utilisée avec HTTPS ou avec une clé SSH. Pour un débutant, HTTPS est souvent plus simple à comprendre, tandis que SSH évite de ressaisir certaines informations une fois configuré. Dans les deux cas, l’authentification doit respecter les mécanismes actuellement proposés par GitHub ; un simple mot de passe de compte n’est pas la méthode normale pour pousser du code.

Le principe de synchronisation repose sur deux commandes :

git remote add origin ADRESSE_DU_DEPOT
git push -u origin main

La première associe le dépôt local au dépôt distant nommé origin. La seconde envoie la branche locale main sur GitHub. Le nom de la branche peut varier selon la configuration, mais main est aujourd’hui un choix courant.

Adopter un flux de travail simple avec les branches

La branche principale doit rester dans un état suffisamment stable pour être consultée ou déployée. Pour une nouvelle fonctionnalité, créez une branche séparée :

git switch -c formulaire-contact

Vous pouvez alors modifier les fichiers, tester le résultat et créer plusieurs commits sans perturber la branche principale. Une fois le travail terminé, envoyez la branche vers GitHub :

git push -u origin formulaire-contact

Dans GitHub, ouvrez ensuite une pull request. Cette demande permet de comparer les changements, de laisser des commentaires et de décider si la branche peut être fusionnée dans main. Même lorsque vous travaillez seul, cette étape crée un point de contrôle intéressant : elle vous oblige à relire les modifications avant de les intégrer.

Pour une petite équipe, une règle simple suffit souvent :

• main contient la version stable ;
• chaque tâche importante possède sa propre branche ;
• une pull request est relue avant la fusion ;
• la branche est supprimée après la fusion si elle ne sert plus.

Récupérer les changements sans écraser son travail

Avant de commencer une session, récupérez la version récente du projet :

git switch main
git pull

Si vous travaillez sur une branche personnelle, vous pouvez ensuite intégrer les derniers changements de main dans celle-ci. L’objectif est de détecter les incompatibilités tôt, plutôt que d’attendre la fin du projet.

Un conflit apparaît lorsque deux modifications concernent une même partie d’un fichier et que Git ne peut pas choisir automatiquement laquelle conserver. Le fichier comporte alors des marqueurs indiquant les deux versions. Il faut examiner le code, supprimer les marqueurs, conserver la solution correcte, puis valider la résolution :

git add fichier-concerne
 git commit -m "Résoudre le conflit de fusion"

Ne résolvez jamais un conflit en sélectionnant mécaniquement votre version ou celle du dépôt distant. Relisez le comportement attendu et relancez les tests ou la prévisualisation du site après la fusion.

Les erreurs qui fragilisent un dépôt GitHub

GitHub facilite le partage, mais il ne remplace ni une sauvegarde ni une politique de sécurité. Plusieurs erreurs reviennent souvent chez les débutants.

• Publier un secret : supprimer le fichier après coup ne suffit pas toujours, car il peut rester dans l’historique. Une clé exposée doit être révoquée et remplacée.
• Commiter des fichiers lourds : les vidéos, archives et exports volumineux compliquent le dépôt. Utilisez une solution adaptée aux gros fichiers lorsque c’est nécessaire.
• Modifier directement main : cette pratique réduit la possibilité de relire ou tester une contribution avant son intégration.
• Utiliser des messages vagues : un historique rempli de « fix », « test » ou « modif » perd une grande partie de sa valeur.
• Confondre dépôt public et sauvegarde privée : un dépôt public rend son contenu accessible. Vérifiez la visibilité avant d’y placer des fichiers de travail.

Une organisation adaptée à un projet individuel

Pour un site personnel ou un petit exercice, inutile de mettre en place un processus lourd. Créez un dépôt, ajoutez un README expliquant le projet, utilisez une branche par fonctionnalité et conservez une branche principale fonctionnelle. Faites un commit après chaque étape cohérente : structure HTML, style principal, formulaire, correction mobile.

Pour un projet à plusieurs, ajoutez quelques règles écrites dans le README : méthode de lancement local, convention de nommage des branches, commandes de test et procédure de demande de fusion. Ces informations évitent que chaque nouveau contributeur devine le fonctionnement du projet.

GitHub devient réellement utile lorsque l’équipe sait quoi enregistrer, quand le publier et comment relire une modification. La plateforme ne demande pas de mémoriser toutes ses fonctions dès le départ : un cycle régulier — modifier, vérifier, commiter, pousser, relire — suffit pour construire de bonnes habitudes.