Git et GitHub pour débuter : versionner un projet et travailler à plusieurs

Un fichier supprimé par erreur, une modification qui casse le site ou plusieurs personnes qui travaillent sur le même projet : Git devient utile dès que les fichiers commencent à évoluer. Git conserve l’historique d’un projet sur votre ordinateur, tandis que GitHub peut héberger ce dépôt et faciliter le partage ou la collaboration.

Le plus simple pour débuter consiste à maîtriser un cycle court : modifier, vérifier, enregistrer une version, puis synchroniser. Vous n’avez pas besoin de connaître toutes les fonctions de Git pour travailler proprement, mais quelques habitudes évitent déjà la plupart des erreurs courantes.

Git et GitHub ne désignent pas le même outil

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

GitHub est une plateforme en ligne qui peut héberger un dépôt Git. Elle ajoute des fonctions de partage, de discussion, de revue de code et de gestion du travail en équipe. Git peut fonctionner sans GitHub, notamment pour un projet conservé uniquement en local. À l’inverse, GitHub s’appuie généralement sur Git pour suivre l’historique des fichiers.

Cette distinction aide à comprendre les commandes. Les actions comme git add et git commit concernent d’abord votre copie locale. Les commandes git push et git pull servent à échanger des modifications avec un dépôt distant, par exemple sur GitHub.

Préparer un premier dépôt sans exposer de fichiers inutiles

Installez Git depuis la source adaptée à votre système, puis vérifiez que la commande répond dans un terminal avec git –version. Configurez ensuite le nom et l’adresse utilisés pour identifier vos commits. Ces informations ne remplacent pas votre authentification à GitHub : elles servent à attribuer clairement les modifications dans l’historique.

Dans le dossier du projet, exécutez git init. Git crée alors un dossier interne qui contient les informations nécessaires au suivi des versions. Il est préférable de lancer cette commande à la racine du projet, là où se trouvent les fichiers principaux, et non dans un sous-dossier comme images ou src.

Avant le premier enregistrement, créez un fichier .gitignore. 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 produits par l’éditeur, les journaux de débogage et les fichiers contenant des secrets locaux.

Le fichier .gitignore n’est pas une protection absolue : un secret déjà enregistré dans l’historique ne disparaît pas simplement parce que vous l’ajoutez ensuite à ce fichier. Les clés d’API, mots de passe et jetons ne doivent donc jamais être écrits dans le dépôt, même privé.

Le cycle quotidien : vérifier, sélectionner, enregistrer

La commande git status est votre point de contrôle. Elle indique les fichiers modifiés, les fichiers préparés pour le prochain commit et ceux que Git ignore. Prenez l’habitude de l’utiliser avant et après chaque opération importante : elle évite de committer un fichier inattendu ou de croire qu’une modification a bien été prise en compte.

Git ne place pas automatiquement toutes les modifications dans le prochain commit. La commande git add nom-du-fichier sélectionne un fichier précis. La forme git add . ajoute les changements visibles dans le dossier courant ; elle est pratique, mais demande une vérification attentive avec git status, surtout lorsqu’un projet contient des fichiers temporaires.

Lorsque la sélection est correcte, créez une version avec git commit -m « Décrire la modification ». Le message doit expliquer l’intention du changement : « ajoute la validation du formulaire » est plus utile que « modifications ». Un commit devrait idéalement correspondre à une unité compréhensible, comme une correction, une fonctionnalité ou une mise à jour de documentation.

Pour consulter les versions enregistrées, utilisez git log. L’historique permet de retrouver l’auteur, la date et le message de chaque commit. Il devient réellement utile lorsque les commits sont réguliers et décrits avec précision ; un seul commit géant en fin de projet rend les recherches et les retours en arrière beaucoup plus difficiles.

Relier le projet local à un dépôt GitHub

Créez sur GitHub un dépôt vide correspondant au projet. Si un dépôt local existe déjà, évitez de demander à GitHub de générer automatiquement un fichier d’accueil ou d’autres fichiers initiaux : deux historiques indépendants peuvent nécessiter une fusion avant la première synchronisation.

GitHub fournit l’adresse du dépôt distant. Dans le terminal, la commande git remote add origin adresse-du-depot associe le nom origin à cette adresse. Le nom est une convention courante, pas une obligation. Vérifiez l’association avec git remote -v avant d’envoyer quoi que ce soit.

La branche principale peut porter un nom différent selon la configuration du projet. Pour connaître la branche active, utilisez git branch –show-current. Une première synchronisation ressemble souvent à git push -u origin main lorsque la branche locale s’appelle main. Remplacez ce nom si votre projet utilise une autre branche.

Lors de cette étape, GitHub peut demander une authentification. L’ancien fonctionnement consistant à utiliser directement un mot de passe pour les opérations Git n’est plus la méthode habituelle. Selon votre configuration, vous pourrez utiliser une clé SSH ou un jeton d’accès. Ces moyens d’authentification doivent rester privés et ne doivent jamais être copiés dans un fichier du projet.

Récupérer et envoyer les changements sans créer de conflit

Avant de commencer une session de travail, récupérez les changements disponibles sur le dépôt distant avec git pull. Cette habitude est particulièrement importante lorsque plusieurs personnes modifient le même projet. Elle réduit le risque de travailler à partir d’une version dépassée.

Un conflit apparaît lorsque Git ne peut pas choisir automatiquement entre deux modifications qui concernent une même zone de fichier. Le fichier contient alors des marqueurs indiquant les différentes versions. Il faut examiner le contenu, conserver la version correcte ou combiner les deux, supprimer les marqueurs, puis vérifier le résultat avant de préparer le fichier avec git add.

Ne résolvez pas un conflit en supprimant rapidement une partie du fichier sans la comprendre. Relisez le contexte, testez le projet et consultez la personne concernée si le changement touche une fonctionnalité importante. Un conflit est un problème de contenu à trancher, pas seulement un message technique à faire disparaître.

Pourquoi utiliser des branches plutôt que modifier directement la version principale

Une branche permet de travailler sur une fonctionnalité ou une correction sans perturber immédiatement la branche principale. Créez-en une avec git switch -c nom-de-la-branche, puis réalisez vos modifications et vos commits sur cette branche.

Des noms explicites facilitent le suivi : ajout-formulaire-contact, correction-menu-mobile ou mise-a-jour-documentation indiquent l’objectif sans devoir ouvrir les fichiers. Une branche ne remplace pas les commits : elle offre un espace de travail séparé dans lequel les étapes restent traçables.

Une fois la fonctionnalité testée, envoyez la branche sur GitHub avec git push -u origin nom-de-la-branche. Vous pouvez ensuite ouvrir une demande de fusion, souvent appelée pull request, afin de faire relire le changement avant son intégration. Pour un projet personnel, cette étape peut sembler facultative, mais elle permet aussi de conserver une description claire de ce qui a été modifié.

Les habitudes qui rendent un dépôt fiable

• Commitez souvent, mais pas chaque caractère modifié : regroupez les changements qui servent une même intention.
• Écrivez des messages précis : le futur vous doit pouvoir comprendre le commit sans rouvrir tout le projet.
• Vérifiez avant de pousser : consultez le statut, relisez les changements et lancez les tests disponibles.
• Gardez les branches courtes : une branche qui reste isolée trop longtemps devient plus difficile à fusionner.
• Ne confondez pas Git et une sauvegarde complète : un dépôt ne remplace pas une stratégie de sauvegarde indépendante, surtout si les fichiers sont importants.
• Protégez les informations sensibles : ajoutez les fichiers locaux au fichier .gitignore, mais traitez immédiatement tout secret déjà exposé.

Pour un petit projet web, un rythme simple suffit : récupérer les changements au début, travailler sur une branche dédiée, vérifier les fichiers modifiés, committer une étape cohérente, tester, puis pousser la branche. Cette routine réduit les manipulations improvisées et rend l’historique compréhensible.

Commencez avec un dépôt d’essai contenant quelques fichiers sans données sensibles. Faites volontairement une modification, consultez git diff, créez un commit, puis revenez lire l’historique. Après cette première boucle locale, la synchronisation avec GitHub et le travail par branches deviennent beaucoup moins intimidants.