Apprendre Git – Partie 3 – Travailler avec un dépôt distant

Dans la première partie de cette mini-série Apprendre Git, on a fait connaissance avec Git. On a appris à initialiser un dépôt, on a fait nos premiers commits et on a découvert comment Git fonctionne.

Dans la deuxième partie la série, on a parlé des branches. Les branches sont un concept central dans Git. On a appris à créer des branches, fusionner des branches et résoudre les conflits quand il y en a.

Maintenant, vous avez une bonne connaissance globale du fonctionnement de Git. Vous êtes prêts à collaborer en ligne, ce qui est tout l’intérêt de Git.

Dans cet article, on va voir comment gérer et travailler à partir de dépôts distants hébergés sur https://github.com : comment les créer, les cloner, comment pousser nos modifications, etc…

Qu’est-ce que Github ?

Github est une plateforme d’hébergement et de gestion de dépôts de code. Elle permet aux organisations et aux individus de stocker leurs projets en ligne et permet aux autres utilisateurs de collaborer sur ces projets.

Chaque projet peut-être publique (visible par tous) ou privé (visible uniquement par le propriétaire et ses collaborateurs autorisés). L’avantage des projets publiques, c’est que tout le monde peut lire votre code et contribuer à votre projet.

Par exemple, si une personne utilise votre projet et y découvre un bug, elle peut potentiellement cloner le dépôt distant, corriger le bug et vous soumettre la correction, que vous pouvez accepter ou refuser.

Git et Github permettent simplement à plusieurs individus de contribuer au même projet simultanément.

Pour cette série, on va parler de Github, mais il existe d’autres plateformes de gestion de dépôt similaires : Gitlab, Bitbucket, etc… Tout les concepts que vous allez apprendre ici sont applicables aux autres plateformes.

Comment travailler avec un dépôt distant

La version stable du code de votre projet sera stockée dans votre dépôt en ligne sur https://github.com (ou autre). Le code en ligne constitue ainsi la source de vérité. En général, c’est dans la branche principale (main, master, ou encore trunk).

Votre copie de travail locale n’est qu’un brouillon utilisé tant que vous êtes en train de développer votre fonctionnalité, mais le code stable à jour est en ligne.

Avec un dépôt distant, le workflow est le suivant :

• vous allez commencer par vous assurer que votre copie de travail locale est à jour, synchronisée avec le dépôt distant, en téléchargeant (pull) le code du dépôt. Pour notre exemple, on n’a pas encore de dépôt distant. On va le créer dans un instant à partir de notre dépôt local. Ils seront donc parfaitement identiques.
• Vous développez vos fonctionnalités sur votre copie de travail locale et tenez à jour votre dépôt local, en créant vos branches, etc… Comme on l’a fait jusqu’à maintenant.
• Quand vous aurez terminé, vous poussez (push) vos modifications sur le dépôt distant sur https://github.com (ou autre)
• Selon vos droits sur le dépôt distant, vous allez pouvoir approuver ou non les changements entrants, ou alors allez devoir attendre qu’un administrateur du dépôt approuve ou non vos changements.
• Plus tard, quand vous devez à nouveau travailler sur le projet, vous allez mettre à jour votre dépôt local en téléchargeant le code du dépôt distant (pull), pour récupérer les changements effectués par vos collègues ou autres contributeurs et travailler sur une version à jour du projet dans votre copie locale.
• Vous pouvez continuer votre travail, pousser vos changements (push), etc…

Pour résumer, on pull (on rapatrie/télécharge) le code distant pour être à jour, on travaille, on push (on pousse) sur le dépôt distant. C’est très simple en fait. On va voir toutes ces étapes ensemble, pas à pas.

Créer un dépôt

Avant de créer un dépôt, il vous faut un compte sur https://github.com.

Ensuite, pour gérer vos dépôts depuis votre machine, il vous faudra vous authentifier. Pour cela, Github propose plusieurs méthodes d’authentification : https://docs.github.com/fr/authentication/keeping-your-account-and-data-secure/about-authentication

Votre organisation a peut-être déjà un compte sur Github et peut donc vous aider à vous authentifier.

Sinon, la manière la plus simple de s’authentifier est d’utiliser un Personal Access Token. Comme son nom l’indique, c’est un jeton d’accès personnel que vous pouvez utiliser comme un mot de passe pour gérer vos dépôts distants depuis votre machine. Vous pouvez en créer un facilement depuis votre compte.

Une fois que vous avez créé votre jeton, vous allez pouvoir initialiser un dépôt.

Sur votre compte Github, dans l’onglet Répositories (dépôts), vous allez pouvoir créer un dépôt en cliquant le bouton New sur la droite. Vous allez ensuite remplir un simple formulaire vous invitant à renseigner le nom de votre dépôt, une description optionnelle et quelques options de configuration. Pour le moment, initialisez le dépôt sans aucune de ces options : pas de readme.md, pas de .gitignore, et pas de licence.

Une fois votre dépôt crée, Github vous aide en vous indiquant ce que vous pouvez faire :

Ils vous donnent toutes les commandes nécessaires pour cloner le dépôt, créer un nouveau dépôt local et le synchroniser avec ce nouveau dépôt distant, ou synchroniser un dépôt local existant.

Nous avons déjà un dépôt local, donc c’est cette troisième option qui nous intéresse.

Déclarer un dépôt distant avec git remote

Les commandes git remote permettent de gérer des dépôts distants. Vous allez pouvoir ajouter des références à des dépôts distants avec git remote add, en supprimer avec git remote remove, les renommer avec git remote rename, entre autres. git remote seul va lister les dépôts distants comme git branch seul ne fait que lister les branches.

Comme mentionné précédemment, le code du dépôt distant est souvent considéré comme la référence, et par convention ce dépôt est appelé origin.

Maintenant que notre dépôt en ligne est crée et qu’on dispose de son url, on va l’ajouter à la liste des dépôts distants sur notre dépôt local.

git remote add origin https://github.com/vincedubroeucq/apprendre-git.git

git remote add <name> <url> permet simplement d’ajouter un dépôt distant appelé <name> et de spécifier où le trouver à l’aide de l’url.

Maintenant, notre dépôt local sait qu’il existe un dépôt distant nommé origin à l’adresse https://github.com/vincedubroeucq/apprendre-git.git

En utilisant git remote seul, on peut voir qu’on a maintenant un dépôt distant listé : origin. Pour le reste de l’article, j’utiliserai le mot remote pour parler du dépôt distant (pour remote repository).

Pousser notre code avec git push

Avec git remote on a juste créé une référence vers le remote. Mais notre code n’est pas synchronisé.

Pour pousser notre code sur le remote, on va utiliser la commande git push <remote> <branch> en remplaçant <remote> par le nom de notre dépôt et <branch> par la branche dans laquelle nous voulons pousser la branche courante.

git push origin master

Git a réussi à compresser nos changements, et à les envoyer. La dernière ligne nous indique qu’il a aussi réussi à créer une nouvelle branche à partir de notre master locale qu’il a aussi appelée master.

Potentiellement, on peut pousser n’importe quelle branche locale dans n’importe quelle branche distante et on peut donner n’importe quelle nom à nos branches. Mais pour ne pas s’emmêler les pinceaux, on garde en général les mêmes noms pour les branches distantes et locales.

Notre dépôt distant contient bien notre code. Tout va bien.

Par contre, vous remarquerez qu’il ne contient pas notre branche inline-navigation. En utilisant git push origin master, on a spécifié que nous voulions uniquement pousser la branche master.

Rapatrier des changements avec git pull

Maintenant, si vous regardez la capture précédente, Github nous recommande d’ajouter un fichier readme.md. Ce fichier est affiché automatiquement sur la page d’accueil de notre dépôt et constitue en général sa documentation.

On va donc suivre le conseil et créer un fichier readme.md, directement sur Github, en cliquant sur le bouton central.

Dans ce fichier markdown, on va mettre ce contenu :

## Apprendre Git

This repo contains an example for the *Apprendre Git* article series on https://vincentdubroeucq.com

Github nous permet d’ajouter des fichiers et de créer les commits directement. Pour un simple fichier texte comme celui-ci cela ne pose pas trop de problèmes, mais il vaut mieux éviter de modifier du code directement sur Github.

Maintenant, la branche master de notre remote est en avance d’un commit sur notre dépôt local.

On va se placer dans la branche master sur notre dépôt local si on n’y est pas déjà, et on va rapatrier les changements de master distant vers master local à l’aide de git pull, en spécifiant le remote et la branche a rapatrier.

git pull origin master

Vous pouvez voir la mention Fast-forward. On a déjà rencontré cette mention dans la partie 2 de cette série, quand on a fusionné deux branches.

Car c’est bien ce qu’il se passe ici : quand vous utilisez git pull ou git push, c’est bien une fusion entre votre branche locale et votre branche distante qui a lieu.

Et cette fusion comporte les mêmes risques de conflits qu’en local. Heureusement, les conflits se règlent souvent assez facilement, comme nous l’avons vu la dernière fois.

Si vous examinez la copie locale de votre code, vous verrez qu’on a bien rapatrié notre fichier readme.md. Notre branche locale master est bien à jour.

Expliciter les branches amonts pour simplifier les pull et push

Cela peut devenir assez pénible de toujours spécifier le remote et la branche que l’on veut pousser ou tirer dans la commande. Pour tester, on va simplement mettre à jour notre readme.md, créer un commit et essayer de pousser nos modifications avec git push seul.

git add .
git commit -m "Updated readme"
git push

Quand on essaie git push, Git ne peut pas savoir dans quelle branche distante pousser la branche courante locale. Il nous faut expliciter la liaison entre notre branche courante et la branche distante correspondante à l’aide de la commande que Git nous fournit :

git push --set-upstream origin master

Avec le flag --set-upstream, on explicite à Git que la branche courante (master locale) est à synchroniser avec master depuis origin.

Git comprend ça très bien et nous le restitue clairement dans son dernier message : La branche ‘master’ est paramétrée pour suivre la branche distante ‘master’ depuis ‘origin’.

Nos branches master locales et distantes sont maintenant liées et à chaque fois que nous devons rapatrier ou pousser des changements sur ces branches, nous n’aurons plus besoin de spécifier la branche dans la commande : git push ou git pull suffiront.

Pousser une nouvelle branche locale

Maintenant, imaginons que nous devons avancer et ajouter un pied de page à notre site.

Pour travailler en toute sécurité, on va mettre à jour notre branche master locale à l’aide de git pull, puis on va créer une nouvelle branche locale.

git switch master
git pull
git switch -c footer

git switch -c footer permet de créer la branche avant de s’y déplacer, grâce au flag -c. On aurait aussi pu simplement faire git branch footer pour créer la branche, suivi d’un git switch footer pour s’y déplacer.

Dans index.html, on va modifier la structure qui n’allait pas du tout et ajouter notre pied de page :

...
<body>
  <header>
    <a href="/">Apprendre Git</a>
    <nav class="main-navigation">
      <ul>
        <li><a href="/about">About</a></li>
        <li><a href="/products">Products</a></li>
        <li><a href="/services">Services</a></li>
        <li><a href="/contact">Contact</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <div class="wrapper">
      <h1>Apprendre Git</h1>
      <p>...content</p>
    </div>
  </main>

  <footer>&copy;2024 Vincent Dubroeucq</footer>
</body>
</html>

On va créer un commit local dans la branche footer et on va essayer de pousser nos changements avec git push.

git status
git commit -am "Added footer"
git push

Exactement comme précédemment, notre git push seul a échoué car on n’a pas spécifié la branche distante dans laquelle pousser.

Aussi la branche distante footer n’existe pas. Mais on peut résoudre ce problème exactement de la même manière que précédemment : en associant explicitement la branche locale et une branche amont (que l’on va nommer de la même manière).

git push --set-upstream origin footer

Git a réussi à créer une branche distante appelée footer, et a paramétré la branche locale pour suivre la distante du même nom.

Aussi, vous remarquerez que Git nous suggère de créer une pull request sur Github. On va voir tout de suite de quoi il s’agit.

Créer une pull request

En allant sur Github.com, vous remarquerez que nous disposons bien de notre nouvelle branche footer, et qu’une notice nous invitant à examiner les changements effectués dans cette branche est apparue.

Une pull request est une demande (request) de fusion entre deux branches. Dans notre cas, on veut que footer soit fusionnée dans master. Autrement dit, on veut se placer dans la branche master distante et rapatrier et fusionner les changements (pull) contenus dans footer.

Quand vous travaillez dans votre dépôt local, vous avez tous les droits. Rien ne vous empêche de vous placer dans master et de faire git merge footer. Sur Github, vous allez simplement demander la permission, car tout le monde n’a pas forcément le droit de pousser du code directement dans master. On appelle ça une pull request.

En appuyant sur ce bouton, vous allez créer votre première pull request.

Sur la page de création de la pull request Github va comparer les branches destination et source pour voir s’il n’y a pas de conflit, et vous indiquer comment les résoudre s’il y en a.

Sur ce formulaire, vous pouvez ajouter une description, voir les commits concernés et comparer le code des branches avant la fusion.

Quand la pull request est créé, vous pouvez encore discuter avec vos collaborateurs s’il y a des soucis ou conflits avant de valider la fusion. La fusion peut être validée par un administrateur ou le propriétaire du dépôt.

Dans cette courte vidéo, il n’y a aucun conflit et je suis le propriétaire du dépôt, donc je peux valider sans problème.

Une fois votre branche fusionnée, vous pouvez la supprimer si vous le souhaitez. Vous pouvez aussi voir que la branche master contient bien tout notre nouveau code.

Cloner un dépôt avec git clone

Dans cet article, on est partis d’une copie locale de notre projet, qu’on a poussé sur un dépôt en ligne fraîchement crée. Maintenant, imaginez qu’un de vos clients vous demande d’ajouter des fonctionnalités sur un projet dont le dépôt est déjà existant sur Github. Rassurez-vous, la procédure est très simple.

Pour simuler cette situation, on va supprimer notre projet local et faire comme si on partait du dépôt existant en ligne. On va simplement cloner ce dépôt distant pour en avoir une copie sur notre machine.

Maintenant, rendez-vous sur la page d’accueil du dépôt sur Github et en cliquant sur le bouton Code vous allez pouvoir copier l’URL du dépôt.

De retour dans votre terminal, placez-vous dans le dossier où vous souhaitez placer votre projet, puis clonez le dépôt distant avec git clone <url>.

cd Projects
git clone https://github.com/vincedubroeucq/apprendre-git.git

Et voilà ! Maintenant, vous avez une copie locale de votre dépôt distant. Le nom du dossier correspond au nom du dépôt.

En naviguant dans votre projet et en utilisant git branch, vous remarquerez qu’en réalité, il a uniquement cloné la branche master et n’a pas rapatrié la branche distante footer.

Mais le dépôt local est déjà configuré pour suivre les branches distantes, donc rapatrier les branches distantes souhaitées est très simple :

git switch footer
git pull

La branche footer n’existe pas sur notre dépôt local donc git switch footer devrait échouer, puisqu’on essaie de basculer dans une branche inexistante. Mais puisqu’elle existe sur le dépôt distant, Git la rapatrie automatiquement. Le git pull permet de s’assurer qu’on est bien à jour.

Maintenant, vous pouvez travailler normalement sur votre projet, créer des branches, les pousser, etc…

Conclusion

Dans la première partie de cette série Apprendre Git, on a appris les rudiments de Git : comment créer un dépôt et faire nos premiers commits.

Dans la deuxième partie, on a parlé des branches et vu comment créer des branches et les fusionner.

Dans cette troisième partie, on a vu comment fonctionnaient les dépôts distants : on a appris à en créer un et le lier à notre dépôt local. On a vu comment pousser nos changements, rapatrier des changements et synchroniser nos branches. On a aussi vu comment fonctionnent les pull requests et appris à cloner un dépôt distant.

Avec tout ça, vous êtes prêts à collaborer ! Git a encore beaucoup d’autres fonctionnalités utiles, mais avec le contenu de ces articles, vous en savez largement suffisamment pour utiliser Git au quotidien.

Maintenant, lancez-vous !

J’espère que vous avez trouvez ça utile !

Si ça vous a plu, abonnez-vous à la newsletter pour ne rien rater !