Editions ENI Livres | Vidéos | e-Formations
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 afin de le partager avec d’autres dépôts dits « locaux ». C’est un type de dépôt qui devient réelleent 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, qu’on pourrait traduire par « dépôt nu » ou « dépôt simple ». On rencontre aussi le terme « dépôt d’autorité », mais l’usage a consacré « dépôt distant » et « dépôt serveur ». Dans ce livre, nous utiliserons le terme « dépôt distant ». Ce type de dépôt s’utilise différemment d’un 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 :
Ce schéma présente également un exemple...
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 les besoins des prochains tests, il faut un dépôt local contenant plusieurs commits. Nous allons donc créer...
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 ce nouveau dépôt.
Les protocoles d’échange
Pour qu’un dépôt distant et un dépôt local puissent échanger des données, il leur faut un moyen de communication. 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 à deux dépôts d’échanger des informations :
-
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 des 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 |
|
|
|
SSH |
|
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 dédiée aux 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 troisième ligne permet de spécifier l’endroit où sont stockées les branches locales et les branches distantes suivies.
Pour changer le nom du dépôt distant nommé...
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 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.
Si plusieurs développeurs travaillent sur le même serveur distant, qu’un développeur envoie des modifications (via un ou plusieurs commits) sur le serveur et que personne ne les récupère, alors personne ne pourra envoyer ses modifications avant d’avoir récupéré celles présentes sur le serveur. Pour tester ce cas, il suffit de réaliser les étapes suivantes :
-
Créer un nouveau dépôt distant :
mkdir test_echange cd test_echange ...
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 les branches distantes. Ces commits seront alors intégrés dans ces branches afin d’être fusionnés par la suite dans les branches locales.
La commande git merge FETCH_HEAD va ensuite merger les modifications contenues sur la branche distante suivie pour les intégrer...
Les branches divergentes
Une branche est dite « divergente » lorsque, pour une même branche globale, la branche locale et la branche distante possèdent des commits différents à partir d’un ancêtre commun. Ce sont ces commits différents dans la branche locale et dans la branche distante qui caractérisent cette divergence.
Cette situation peut avoir diverses origines :
-
Des commits ont été poussés vers le dépôt distant pendant que des commits ont été enregistrés sur le dépôt local.
-
Un développeur a réécrit l’historique (en rebasant des commits ou encore en utilisant git commit --amend, puis en envoyant les modifications avec git push --force).
Si le deuxième cas se produit, c’est très certainement dû à une organisation défaillante dans l’équipe. En effet, réécrire l’historique lorsqu’on est seul sur une branche n’est pas dérangeant, mais très peu de situations légitiment cette réécriture d’historique lorsque plusieurs personnes travaillent sur une branche. Si la réécriture de l’historique est massive et concerne de nombreux commits, la situation peut devenir très complexe à gérer. Néanmoins, de nombreux cas demeurent assez simples à traiter à condition de bien comprendre de quoi il retourne.
En définitive, il n’y a pas de réel problème vu qu’il est facile de revenir à une situation normale de branche. Néanmoins, cela peut s’avérer chronophage si l’ancêtre commun des deux sous-branches se trouve loin dans l’historique et que de nombreux commits touchant au même code ont été créés.
Pour les tests suivants, nous allons installer un environnement reproduisant ce genre de cas.
Il faut tout d’abord créer le projet en utilisant les commandes suivantes :
mkdir...