GitHub : travailler seul ou à plusieurs depuis un seul dépôt distant

Maintenant que nous avons appris à préparer Git localement, à versionner nos fichiers, à créer des branches, puis à tester, fusionner ou revenir en arrière, nous allons franchir une étape importante : connecter notre projet à un dépôt distant. (voir — Préparer Git côté local : démarrer dans de bonnes conditions, Premiers pas avec Git : suivre l’évolution d’un site simple et Explorer, tester, corriger : aller plus loin avec Git en solo). Nous utiliserons ici GitHub, la plateforme la plus connue, mais les mêmes principes s’appliquent à GitLab, Bitbucket ou d’autres services similaires.

Si vous découvrez GitHub ou si vous hésitez encore sur ce que signifie un pull request, un gist ou un codespace, nous vous conseillons de commencer par lire l’article GitHub : explorer l’interface avant de connecter un projet. Vous y verrez comment fonctionne la plateforme, à quoi correspond chaque section, et comment s’y repérer dès l’ouverture d’un compte.

Dans cet article-ci, nous allons connecter un projet concret à un dépôt distant, le publier, le synchroniser, puis voir comment collaborer à plusieurs tout en gardant un historique clair.

Choisir un nom de branche compatible avec GitHub

Par défaut, Git créait autrefois une branche principale nommée master. C’est d’ailleurs le nom que nous avons utilisé dans les articles précédents. Mais GitHub, comme d’autres plateformes modernes, préfère aujourd’hui le nom main. Ce changement vise à harmoniser les pratiques et à éviter certaines ambiguïtés dans les environnements collaboratifs.

Si votre projet local utilise encore master, deux solutions s’offrent à vous. Vous pouvez conserver ce nom, à condition que le dépôt GitHub soit vide et que vous gardiez une cohérence parfaite entre les deux. Mais dans la plupart des cas, mieux vaut adopter le nom main, notamment si vous utilisez Visual Studio Code ou si vous laissez GitHub créer le dépôt automatiquement lors de la publication.

En ligne de commande, vous pouvez renommer votre branche actuelle en une seule instruction :

git branch -M main

Cette commande remplace le nom master (ou tout autre nom courant) par main, sans perte d’historique ni de commit. Vous pouvez vérifier le résultat avec :

Dans Visual Studio Code, ce changement peut également se faire dans l’interface. Il suffit d’ouvrir le panneau Git (source control), de cliquer sur le nom de la branche actuelle, puis de choisir “Rename branch”. Vous pouvez alors saisir main, valider, et continuer normalement.

Adopter ce nom facilite la synchronisation avec GitHub et évite de nombreuses erreurs lors des pushes ou des publications initiales.

Deux méthodes pour publier un projet existant

Pour connecter un projet Git local à GitHub, deux chemins sont possibles. Vous pouvez le faire en ligne de commande ou directement depuis Visual Studio Code. Les deux méthodes aboutissent au même résultat, mais ne suivent pas la même logique.

Si vous choisissez la ligne de commande, vous devez au préalable créer un dépôt vide sur GitHub. Cela vous permettra ensuite d’établir le lien entre ce dépôt distant et votre projet local. Il est impératif de ne rien ajouter à ce dépôt lors de sa création : ni README, ni fichier .gitignore, ni licence. Le dépôt doit être totalement vide pour accepter un premier push depuis votre machine.

Si vous passez par Visual Studio Code, la démarche est plus directe. Il ne faut rien créer du tout sur GitHub. Le dépôt distant sera généré automatiquement par l’éditeur lors de la publication. Visual Studio Code établira la connexion, poussera les fichiers, et configurera le dépôt sans que vous ayez besoin d’intervenir sur GitHub. Il suffit d’ouvrir le dossier local et de lancer la commande Publish to GitHub depuis l’interface.

Dans les deux cas, votre projet local doit être prêt, avec un historique de commits, une branche active, et un nom de branche compatible avec GitHub (voir chapitre précédent).

Attention aux noms : GitHub ignore les majuscules

Lorsque vous publiez un projet local vers GitHub, Visual Studio Code se base automatiquement sur le nom du dossier local pour nommer le dépôt distant. Par exemple, si votre dossier s’appelle git-website, le dépôt proposé sera git-website.

Mais GitHub ne fait pas la différence entre majuscules et minuscules dans les noms de dépôts. Un dépôt GIT-Website et un dépôt git-website sont considérés comme identiques. Cela peut poser problème si vous avez déjà créé manuellement le dépôt distant avec un nom différent par la casse (par exemple GIT-Website) : GitHub refusera la publication automatique en affichant une erreur “Repository already exists”.

Pour éviter cela, veillez à ce que le nom du dossier local et celui du dépôt GitHub soient strictement identiques, y compris dans l’usage des majuscules. Si ce n’est pas le cas, vous devrez connecter manuellement votre projet local au dépôt distant (nous reviendrons sur cette méthode plus bas).

Créer un dépôt distant GitHub pour une connexion manuelle

Si vous avez choisi de publier votre projet en ligne de commande, vous devez d’abord créer un espace distant sur GitHub. Connectez-vous à votre compte, puis cliquez sur New repository depuis le menu + ou votre tableau de bord.

Lors de la création, laissez toutes les options décochées : ne cochez pas Initialize with a README, ni les cases .gitignore ou licence. Cela garantit que le dépôt restera vide. En effet, GitHub refuse un git push initial si un fichier a déjà été ajouté côté distant.

Donnez simplement un nom clair au dépôt et, si vous le souhaitez, une courte description. Le code, les commits et les branches sont déjà prêts dans votre projet local. Il ne reste plus qu’à établir le lien entre les deux.

Ce fonctionnement a déjà été détaillé dans l’article GitHub : explorer l’interface avant de connecter un projet, notamment pour le rôle du README, les choix de visibilité ou l’ajout d’une licence. Nous nous concentrons ici uniquement sur la synchronisation.

Relier notre projet local au dépôt distant

Une fois le dépôt GitHub créé, retournez dans votre terminal et placez-vous dans le dossier du projet. Vous pouvez alors relier votre dépôt local au dépôt distant, puis publier vos fichiers :

git remote add origin https://github.com/votre-utilisateur/nom-du-depot.git
## Crée un lien nommé "origin" vers le dépôt distant

git branch -M main
## Renomme la branche locale actuelle en "main" si ce n’est pas déjà le cas

git push -u origin main
## Envoie le contenu local vers le dépôt distant, et définit "origin/main" comme branche de suivi

Une fois ces étapes terminées, votre projet apparaît dans l’interface GitHub. Tous les fichiers, messages de commit et branches sont désormais visibles en ligne.

Si vous avez choisi de conserver le nom master, veillez à utiliser git push -u origin master au lieu de main. L’important est que le nom de branche soit strictement identique entre le dépôt local et le dépôt distant.

Publier vers GitHub depuis Visual Studio Code

Si vous utilisez Visual Studio Code, vous pouvez publier le projet directement depuis l’interface sans passer par la ligne de commande. Une fois votre dossier local ouvert, un bouton “Publish to GitHub” s’affiche en bas à gauche de la fenêtre. Vous pouvez aussi y accéder via la palette de commandes (Ctrl+Shift+P), en tapant Git: Publish to GitHub.

Lors de cette première connexion, GitHub vous demandera d’autoriser Visual Studio Code à accéder à votre compte. Cela passe par une série d’écrans dans le navigateur : confirmation de l’identité (Signed in as...), demande d’autorisation d’accès, puis éventuelle connexion avec votre identifiant GitHub et votre mot de passe.

Une fois validée, l’extension GitHub pour Visual Studio Code crée automatiquement le lien distant (origin), pousse le contenu actuel de votre branche (git push) et synchronise le projet en ligne. Le dépôt distant est visible immédiatement dans l’interface GitHub, avec vos commits, fichiers, et branches.

Mais attention : Visual Studio Code ne publie que la branche active au moment de la commande Publish to GitHub. Toutes les autres branches locales — même si elles existent dans l’historique — restent uniquement sur votre machine. Il ne s’agit donc pas d’un envoi complet du projet Git, mais uniquement d’une publication ciblée de ce que vous êtes en train de développer.

Si vous souhaitez publier d’autres branches, vous pouvez le faire manuellement depuis Visual Studio Code :

• ouvrez la palette de commandes (Ctrl+Shift+P) et tapez Git: Publish Branch,
• ou passez par le panneau Source Control, cliquez sur le nom de branche, basculez sur la branche souhaitée, puis répétez l’opération de publication.

Si vous rencontrez une erreur de type “Repository already exists”, vérifiez que le nom de votre dossier local ne crée pas de conflit avec un dépôt GitHub déjà existant (même nom, même casse). Dans ce cas, vous pouvez supprimer l’origin automatiquement généré (git remote remove origin) puis reconnecter manuellement le dépôt comme décrit précédemment.

Cela permet d’envoyer uniquement les branches utiles, sans encombrer le dépôt distant avec des pistes de travail incomplètes ou obsolètes.

Pour publier toutes les branches locales en une seule fois, il est aussi possible d’utiliser la ligne de commande :

git push --all origin

Cela envoie toutes les branches vers GitHub, sans distinction. À utiliser avec prudence si votre dépôt local contient des branches expérimentales que vous ne souhaitez pas rendre publiques.

Le dépôt utilisé dans cet article est accessible en ligne à l’adresse https://github.com/Birnou/GIT-Website. Il reflète exactement le projet local sur lequel nous avons travaillé, avec ses fichiers, ses commits, et ses branches publiées depuis Visual Studio Code. Vous pouvez le consulter, l’explorer, et même le cloner si vous souhaitez prolonger l’expérience de votre côté.

Ajouter un fichier README après publication

Le dépôt que nous avons publié ne contient pas encore de fichier README.md, car nous avons volontairement laissé GitHub vide lors de la création, pour éviter les conflits lors du premier push. Pourtant, ce fichier joue un rôle central : il s’affiche automatiquement en page d’accueil du dépôt et permet de présenter clairement le projet. Un bon README indique ce que fait le projet, à qui il s’adresse, comment l’utiliser, et éventuellement comment y contribuer.

Le fichier README.md s’écrit en Markdown, un format simple qui permet de structurer un texte avec des titres, du gras, des liens ou du code, sans complexité technique. Si vous ne l’avez jamais utilisé, l’article Markdown : Maîtriser la Clarté et la Simplicité dans Vos Écrits présente en détail ce format et ses usages concrets.

Il est possible d’ajouter ce fichier directement depuis l’interface GitHub, en cliquant sur Add a README. Une fois le fichier créé et validé, il apparaît immédiatement dans l’arborescence du projet.

Récupérer le README en local

Si vous passez par la ligne de commande, la commande git pull permet de synchroniser votre dépôt local avec le dépôt distant, et donc de récupérer le README.

Dans Visual Studio Code, un message s’affiche dans la barre inférieure dès qu’une mise à jour distante est détectée. Il suffit de cliquer sur Pull ou d’utiliser la palette de commandes pour intégrer le fichier ajouté. Vous pourrez ensuite modifier le contenu du README depuis votre éditeur, puis le versionner comme n’importe quel fichier du projet.

Pour voir un exemple illustratif, vous pouvez consulter le dépôt https://github.com/github/roadmap qui utilise un README clair, structuré et engageant dès la première ligne.

Travailler à plusieurs sur un projet GitHub

Une fois le projet publié et structuré, il est possible d’ouvrir la porte à d’autres contributeurs. GitHub permet de travailler à plusieurs en temps réel, de manière fluide et suivie. Cette collaboration peut prendre plusieurs formes, selon la manière dont vous organisez le dépôt.

Ajouter des collaborateurs ou proposer des modifications

Il est possible d’ajouter directement des collaborateurs depuis l’interface GitHub, via les paramètres du dépôt. Une fois invités, ces contributeurs auront les droits nécessaires pour cloner le dépôt, créer des branches, pousser leurs modifications et synchroniser leur travail avec le vôtre. Pour les projets publics, GitHub propose aussi un mécanisme de fork : n’importe quel utilisateur peut copier le dépôt, travailler sur sa propre version, puis soumettre une pull request pour proposer une amélioration ou une correction.

Travailler ensemble avec Git

Dans un usage en ligne de commande, chaque contributeur doit d’abord cloner le dépôt à l’aide de la commande git clone, puis créer une branche pour travailler isolément, avant de pousser ses modifications avec git push et de récupérer celles des autres avec git pull.

Dans Visual Studio Code, ces étapes sont accessibles sans quitter l’interface. Il est possible de publier une nouvelle branche via la commande Publish Branch, de basculer d’une branche à l’autre en un clic, ou de tirer les mises à jour en cliquant simplement sur Pull en bas à gauche. Les éventuels conflits sont détectés automatiquement et peuvent être résolus dans l’éditeur.

Collaborer demande un peu d’organisation, mais GitHub fournit les outils pour gérer ces échanges dans de bonnes conditions. Un message de commit clair, un historique bien suivi et un échange régulier entre les personnes impliquées permettent de garder une progression lisible.

Conclusion

La publication d’un projet Git local sur GitHub ouvre bien plus qu’un simple accès distant. Elle marque l’entrée dans un environnement partagé, versionné, évolutif. Le dépôt devient un lieu d’échange, de documentation et de coordination.

Avec un README.md bien rédigé, une organisation claire des branches, et des invitations ouvertes à la contribution, vous posez les bases d’un projet prêt à vivre dans la durée. Ce premier lien entre Git et GitHub est fondamental, mais ce n’est qu’une première étape. Dans les prochains articles, nous verrons comment structurer le travail collectif, ouvrir des discussions techniques, traiter les propositions d’évolution, et faire de GitHub un véritable espace de projet.

Souhaitez-vous ajouter un bloc final de navigation vers l’article sur les pull requests ou préférez-vous le réserver à la page récapitulative ?