Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Git
  3. Partager un dépôt
Extrait - Git Maîtrisez la gestion de vos versions (concepts, utilisation et cas pratiques) (4e édition)
Extraits du livre
Git Maîtrisez la gestion de vos versions (concepts, utilisation et cas pratiques) (4e édition) Revenir à la page d'achat du livre

Partager un dépôt

Qu’est-ce qu’un dépôt distant ?

Un dépôt distant est un dépôt qui va servir à centraliser un dépôt. C’est un type de dépôt qui devient réellement important (voire indispensable) lorsqu’on travaille à plusieurs sur le même projet puisqu’il permet de centraliser le travail de chaque développeur.

En anglais, ce type de dépôt s’appelle un bare repository ou encore un remote, ce qui donnerait une traduction proche de dépôt nu ou encore dépôt simple. Il est également possible de trouver les terminologies dépôt d’autorité ou dépôt serveur pour désigner ce type de dépôt. Dans le milieu francophone, les termes de dépôt distant et dépôt serveur sont beaucoup utilisés pour désigner ce type de dépôt. Pour éviter les confusions et utiliser des termes reconnus, celui utilisé dans ce livre sera le terme dépôt distant. Ce type de dépôt est en opposition avec le dépôt local (qui pourrait également s’appeler dépôt client).

Le schéma ci-dessous présente une architecture simple composée d’un dépôt distant et de deux dépôts locaux :

IMAGES/07E01.png

Ce schéma présente également un exemple de cycle de vie de la relation entre ces deux types de dépôts avec des lignes pointillées représentant les échanges entre le dépôt distant et les dépôts locaux. Cet exemple permettra de mieux concevoir le lien qui unit les deux types de dépôts :

1 : Le développeur crée son dépôt local et travaille dessus pendant plusieurs semaines. 

2 : Un stagiaire...

Créer un dépôt distant

1. Pour un nouveau projet

Un nouveau projet est perçu ici du point de vue de Git uniquement, c’est-à-dire qu’un nouveau projet peut contenir du code et exister depuis plusieurs années. La seule caractéristique qui le différencie d’un projet existant est de n’être géré par aucun dépôt.

La création d’un dépôt distant Git vierge est très simple : il faut utiliser git init en lui ajoutant le paramètre --bare. Par exemple, pour créer un nouveau dépôt nommé new_browser, il faut utiliser la commande suivante :

git init --bare new_browser 

Git indique que la commande s’est correctement déroulée en affichant la sortie suivante :

Initialized empty Git repository in 
/Volumes/JedemaKey/Livre/Git/Repo/07/01BareVierge/new_browser/ 

2. Pour un projet existant

Un projet existant est, du point de vue de Git, un projet qui est déjà stocké dans un dépôt Git. Pour cela, il faut utiliser la commande git clone qui va copier un dépôt distant dans un nouveau dépôt local. Cette commande sera expliquée plus précisément dans la suite de ce chapitre. Pour tester cette partie, il faut un dépôt local contenant plusieurs commits. Nous allons donc créer un dossier contenant un dépôt local, commiter des modifications dans ce dépôt, et créer un dossier où nous clonerons le dépôt local :

mkdir local  
cd local  
git init  
vi fichier.txt  
git add fichier.txt  
git commit  
cd.  
mkdir serveur  
cd serveur  
git clone --bare ../local/.git clone_distant  
cd clone_distant  
git log 

La sortie...

Cloner un dépôt distant

Cloner un dépôt correspond à copier le contenu d’un dépôt vers un nouveau dépôt. Le nouveau dépôt contiendra un répertoire de travail qui permettra de récupérer et d’enregistrer des modifications.

Le fait de cloner un dépôt revient à copier tout le contenu d’un dépôt dans un nouveau dépôt. Les branches, les commits, et tous les autres objets stockés par Git seront dupliqués dans un nouveau dépôt.

IMAGES/07E02.png

Les protocoles d’échange

Pour échanger avec un dépôt distant, il faut utiliser un moyen de communication entre ce dépôt et le dépôt local. Les dépôts ont besoin d’échanger des données lorsque par exemple un développeur souhaite cloner un dépôt ou encore lorsqu’il souhaite envoyer ses modifications vers le dépôt distant.

Il existe quatre protocoles permettant d’échanger des informations entre deux dépôts :

  • Local : à l’aide du système de fichiers.

  • SSH : à l’aide d’un accès SSH sur la machine contenant le dépôt distant.

  • HTTP : à l’aide du protocole HTTP via un serveur HTTP.

  • Git : à l’aide du protocole Git conçu pour être performant.

Chacun de ces protocoles présente des avantages et inconvénients et convient à des utilisations différentes. Le tableau ci-dessous présente une liste non exhaustive des avantages et des inconvénients des différents protocoles :

Protocoles

Avantages

Inconvénients

Local

  • Simplicité de mise en place.

  • Mêmes restrictions d’accès que celles du système de fichiers.

  • Mise en place d’un accès via Internet compliquée.

SSH

  • Protocole populaire.

  • Protocole sécurisé par une authentification, des restrictions et un chiffrement.

  • Requiert quelques compétences d’administration système pour la mise en place et la gestion des droits.

HTTP

  • L’accès est simple via ce protocole universel.

  • Mise en place simple via un serveur HTTP.

  • Protocole lent.

  • Pas d’authentification ni de restriction.

  • Trafic réseau non chiffré (excepté en HTTPS).

Git

  • Protocole très rapide

  • Pas d’authentification...

Fonctionnement interne et branches distantes

L’utilisation des branches locales et distantes est simple grâce aux commandes git pull et git push. Ces commandes masquent le système interne de Git qui permet de gérer ces branches sans difficulté.

1. Les dépôts distants liés

Un dépôt local peut être lié à plusieurs dépôts distants. Pour avoir la liste des dépôts distants liés au dépôt local, il faut utiliser la commande suivante :

git remote 

Lors de l’utilisation de la commande git clone, un dépôt distant nommé origin est automatiquement renseigné dans le fichier .git/config dont voici un extrait de la partie contenant les dépôts distants :

[remote "origin"]  
    url = /Volumes/JedemaKey/Livre/Git/Repo/07/test_echange/distant 
    fetch = +refs/heads/*:refs/remotes/origin/* 

Dans cet exemple, la première ligne définit le nom du dépôt distant tel qu’il sera utilisé par Git.

La ligne suivante définit l’URL permettant de communiquer avec le dépôt distant. 

La ligne suivante permet de spécifier l’endroit où sont stockées les branches locales et les branches distantes suivies.

Pour personnaliser le nom du dépôt distant et ne pas le nommer origin, il faut utiliser la commande git clone avec l’argument --origin et le nom souhaité :

git clone --origin gitlabteam https://gitlabteam.corporation.com 

2. Les branches distantes suivies

Le chapitre précédent explique le fonctionnement des branches. Les branches sont un système très efficace pour gérer les développements divergents au sein d’un même projet. Pour pouvoir proposer un système aussi souple...

Envoyer ses modifications

Lorsqu’un développeur travaille sur un dépôt local et commite son travail, il a besoin d’envoyer régulièrement ses modifications au dépôt distant. Envoyer ses modifications sur un dépôt distant permet de les partager avec ses autres collaborateurs. Voici la commande permettant d’envoyer au remote nommé origin les modifications ajoutées dans la branche master. Cette commande est utilisable sur un dépôt local :

git push origin master 

Un remote est un dépôt distant pour lequel une liaison existe dans le dépôt local. Ici, le remote origin est en réalité un raccourci vers un dépôt distant. Si le dépôt a été cloné à partir de l’URL http://git-conflict.com/depots/CMS.git, alors origin pointera toujours vers cette URL.

Il faut savoir que si plusieurs développeurs travaillent sur le même serveur distant, si un autre développeur a envoyé des modifications (via un ou plusieurs commits) sur le serveur et que personne ne les a récupérées, alors personne ne pourra envoyer ses modifications avant d’avoir récupéré celles présentes sur le serveur. Ce cas peut être testé facilement en suivant les étapes suivantes :

  • Créer un nouveau dépôt distant :

mkdir test_echange  
cd test_echange  
git init --bare distant 

Lorsque l’interface en ligne de commande se situe dans le dépôt distant, la commande git log affiche la sortie suivante :

fatal: bad default revision 'HEAD' 

Cette sortie indique que le dépôt est vide et que Git ne trouve pas de référence HEAD, ce qui est normal car HEAD n’a aucun commit auquel se référer.

  • Clonage à...

Recevoir les modifications

Savoir envoyer les modifications au dépôt distant est utile, mais tout l’intérêt d’un tel dépôt réside également dans le fait que les autres collaborateurs d’un projet peuvent récupérer les commits contenus dans ce dépôt.

La commande suivante permet de mettre à jour la branche courante avec les commits contenus dans le dépôt distant :

git pull 

Exécutée à partir du dépôt local2, cette commande affiche la sortie suivante :

remote: Counting objects: 3, done.  
remote: Total 3 (delta 0), reused 0 (delta 0)  
Unpacking objects: 100% (3/3), done.  
From /Volumes/JedemaKey/Livre/Git/Repo/07/test_echange/distant 
 * [new branch]      master     -> origin/master 

En réalité, la commande git pull est un raccourci de deux commandes Git exécutées successivement :

git fetch  
git merge FETCH_HEAD 

La commande git fetch va télécharger les commits contenus sur le dépôt distant pour la branche concernée. Ces commits seront intégrés dans la branche distante suivie.

La commande git merge FETCH_HEAD va ensuite merger les modifications contenues sur la branche distante suivie pour les intégrer dans la branche locale. 

Pour illustrer l’utilisation de ces deux commandes, il convient de modifier le fichier README du dépôt local1 puis de commiter :

cd local1  
vi README  
git add README  
git commit -m "README : Ajout lien site"  
git push 

La commande git log --pretty=oneline affiche la sortie suivante :

898f3fc README : Ajout lien site  
cc6bb2a README : initial 

À partir de ce moment, les deux commits sont présents...