Depuis le premier guide de ce parcours, vous savez que Git et GitHub sont deux choses différentes. Jusqu'ici, mon-premier-site n'a existé que sur votre ordinateur : quatre commits, deux branches fusionnées, un conflit résolu, tout ça est resté strictement local. Ce guide ouvre la seconde partie du parcours : relier ce travail à un dépôt hébergé sur GitHub.

Un compte GitHub

Si vous n'avez pas encore de compte, créez-en un gratuitement sur github.com. Un compte gratuit suffit largement pour tout ce parcours : héberger des dépôts publics ou privés, créer des Pull Requests, gérer des issues.

Créer le dépôt sur GitHub

Une fois connecté, utilisez le bouton de création de nouveau dépôt, généralement accessible depuis un bouton « + » ou « New » en haut de l'interface GitHub. Donnez-lui un nom, par exemple mon-premier-site, pour qu'il corresponde à votre projet local.

Le point le plus important de cet écran de création concerne l'initialisation automatique : GitHub propose d'ajouter un README, une licence ou un .gitignore directement depuis son interface. Ne cochez aucune de ces options ici. Vous avez déjà un projet local complet, avec son propre historique et son propre .gitignore. Si vous laissiez GitHub créer ses propres fichiers, le dépôt distant démarrerait avec un historique différent du vôtre, ce qui compliquerait inutilement la suite. Créez donc un dépôt vide, sans aucun fichier initial.

Attention

Si vous cochez « Add a README file » ou une option similaire lors de la création, GitHub crée un premier commit directement sur son serveur. Votre dépôt local et ce nouveau dépôt distant auraient alors chacun un historique différent dès le départ, et les relier deviendrait plus compliqué que nécessaire pour un début de parcours. Un dépôt vide, sans aucune case cochée, est la bonne option ici.

Récupérer l'adresse du dépôt

Une fois le dépôt créé, GitHub affiche une page avec plusieurs adresses possibles pour s'y connecter, et propose deux formats : HTTPS et SSH. Pour ce parcours, l'adresse HTTPS suffit et évite une configuration supplémentaire de clés. Elle ressemble à ceci, en remplaçant les valeurs d'exemple par les vôtres :

Relier votre dépôt local à ce dépôt distant

Retournez dans votre terminal, ouvert dans mon-premier-site. Un « remote » est simplement un nom que Git associe à une adresse de dépôt distant : ce nom vous évite de retaper l'URL complète à chaque commande. Par convention, le remote principal s'appelle presque toujours origin, mais ce n'est qu'une habitude largement partagée, pas une obligation technique de Git.

Cette commande ne modifie aucun fichier de votre projet et n'envoie encore rien sur GitHub : elle enregistre uniquement, dans la configuration locale du dépôt, l'adresse à laquelle origin correspond désormais.

Vérifier que le remote est bien configuré

Deux lignes apparaissent pour le même remote : l'une pour fetch, qui sert à récupérer des données depuis GitHub, l'autre pour push, qui sert à en envoyer. Dans la grande majorité des cas, les deux adresses sont identiques, comme ici.

Rechargez maintenant la page de votre dépôt sur github.com : elle doit toujours afficher un dépôt vide, sans aucun fichier ni commit visible. C'est normal et attendu : git remote add a seulement préparé la connexion. Rien n'a encore été transféré. L'envoi effectif de vos commits, avec la commande git push, est l'objet du prochain guide.

Vérifiez que vous avez compris

Vous venez de taper git remote add origin ... avec succès, puis vous rafraîchissez la page GitHub du dépôt. Vos quatre commits locaux apparaissent-ils déjà dans l'historique visible sur GitHub ?

Non. git remote add enregistre uniquement une adresse de destination possible, il ne transfère aucun commit. Tant qu'aucun git push n'a été effectué, le dépôt GitHub reste exactement dans l'état où vous l'avez créé, c'est-à-dire vide.

Chapitre terminé