Découvrez comment Git gère les versions et comment installer les logiciels nécessaires pour accéder aux serveurs Git sur lesquels votre projet logiciel sera stocké
Cet article vous présente Git, et comment installer les logiciels nécessaires pour accéder aux serveurs Git sur lesquels votre projet logiciel sera stocké.
- Concepts de gestion de version
- Installer Git
- Concepts et fonctionnalités de Git
1. Concepts de gestion de version
Pour comprendre Git et le concept de gestion de version, il est nécessaire d’examiner la gestion de version d’un point de vue historique. Il existe trois générations de logiciels de gestion de version.
La première génération
La première génération était très simple. Les développeurs ont travaillé sur le même système physique et « extrait » un fichier à la fois.
Cette génération de logiciels de gestion de version utilisait une technique appelée verrouillage de fichier. Lorsqu’un développeur extrayait un fichier, celui-ci était verrouillé afin qu’aucun autre développeur ne puisse le modifier.
Des exemples de logiciels de gestion de version de première génération comprennent le système de gestion de révision (RCS) et le système de gestion de code source (SCCS).
La deuxième génération
Les problèmes avec la première génération sont les suivants :
- Un seul développeur peut travailler sur un fichier à la fois. Cela a entraîné un goulot d’étranglement dans le processus de développement.
- Les développeurs devaient se connecter directement au système contenant le logiciel de gestion de version.
Ces problèmes ont été résolus dans la deuxième génération de logiciel de gestion de version. Dans cette génération, les fichiers sont stockés sur un serveur centralisé dans un référentiel.
Les développeurs peuvent extraire des copies séparées d’un fichier. Lorsque le développeur termine le travail sur un fichier, le fichier est archivé dans le référentiel.
Si deux développeurs extraient la même version d’un fichier, il y a un problème. Celui-ci est géré par un processus appelé fusion.
Qu’est-ce qu’une fusion ?
Supposons que deux développeurs, Bob et Sue, extraient la version 5 d’un fichier nommé abc.txt. Une fois que Bob a terminé son travail, il réintègre le fichier. En règle générale, cela entraîne une nouvelle version du fichier, la version 6.
Quelque temps plus tard, Sue enregistre son dossier. Ce nouveau fichier doit intégrer ses propres modifications ainsi que les modifications de Bob. Ceci est accompli grâce au processus de fusion.
Selon le logiciel de gestion de version que vous utilisez, il peut y avoir différentes manières de gérer cette fusion. Dans certains cas, comme lorsque Bob et Sue ont travaillé sur des parties complètement différentes du fichier, le processus de fusion est très simple.
Cependant, dans les cas où Sue et Bob ont travaillé sur les mêmes lignes de code dans le fichier, le processus de fusion peut être plus complexe. Dans ces cas, Sue devra prendre des décisions, par exemple si le code de Bob ou son code sera dans la nouvelle version du fichier.
Une fois le processus de fusion terminé, le processus de validation du fichier dans le référentiel a lieu. Valider un fichier signifie essentiellement créer une nouvelle version dans le référentiel ; dans ce cas, la version 7 du fichier.
Des exemples de logiciels de gestion de version de deuxième génération incluent Concurrent Versions System (CVS) et Subversion.
La troisième génération
La troisième génération est appelée systèmes de gestion de version distribués (DVCS). Comme pour la deuxième génération, un serveur de référentiel central contient tous les fichiers du projet.
Cependant, les développeurs ne récupèrent pas les fichiers individuels du référentiel. Au lieu de cela, l’ensemble du projet est extrait, ce qui permet au développeur de travailler sur l’ensemble complet de fichiers plutôt que sur des fichiers individuels.
Une autre (très grande) différence entre la deuxième et la troisième génération de logiciels de gestion de version concerne le fonctionnement du processus de fusion et de validation. Comme mentionné précédemment, les étapes de la deuxième génération consistent à effectuer une fusion, puis à valider la nouvelle version dans le référentiel.
Avec le logiciel de gestion de version de troisième génération, les fichiers sont archivés puis fusionnés.
Exemple de gestion de version
Supposons que deux développeurs extraient un fichier basé sur la troisième version. Si un développeur archive ce fichier, résultant en une version 4 du fichier, le second développeur doit d’abord fusionner les modifications de sa copie extraite avec les modifications de la version 4 (et, potentiellement, d’autres versions). Une fois la fusion terminée, la nouvelle version peut être validée dans le référentiel en tant que version 5.
Si vous vous concentrez sur ce qui se trouve dans le référentiel (la partie centrale de chaque phase), vous voyez qu’il y a une ligne de développement très droite (ver1, ver2, ver3, ver4, ver5, etc.). Cette approche simple du développement logiciel pose certains problèmes potentiels :
- Le fait d’obliger un développeur à fusionner avant de s’engager entraîne souvent le refus des développeurs de valider leurs modifications de manière régulière. Le processus de fusion peut être pénible. Ainsi, les développeurs peuvent décider d’attendre plus tard et de procéder à une seule fusion plutôt qu’à un ensemble de fusions régulières. Cela a un impact négatif sur le développement logiciel, car d’énormes morceaux de code sont soudainement ajoutés à un fichier. De plus, vous devez encourager les développeurs à valider les modifications dans le référentiel, tout comme vous devez encourager quelqu’un qui écrit un document à enregistrer régulièrement.
- Très important : la version 5 de cet exemple n’est pas nécessairement le travail que le développeur a effectué à l’origine. Pendant le processus de fusion, le développeur peut abandonner une partie de son travail pour terminer le processus de fusion. Ce n’est pas idéal car cela entraîne la perte de code potentiellement bon.
Graphe orienté acyclique ou DAG
Une meilleure technique, bien que sans doute plus complexe, peut être utilisée. Il est appelé graphe orienté acyclique (DAG).
Imaginez le même scénario que ci-dessus, où deux développeurs extraient la version 3 d’un fichier. Là, si un développeur enregistre ce fichier, il en résulte toujours une version 4 du fichier.
Cependant, le deuxième processus d’archivage aboutit à un fichier de version 5 qui n’est pas basé sur la version 4, mais plutôt indépendant de la version 4. Dans l’étape suivante du processus, les versions 4 et 5 du fichier sont fusionnées pour créer une version 6.
Bien que ce processus soit plus complexe (et, potentiellement, beaucoup plus complexe si vous avez un grand nombre de développeurs), il offre certains avantages par rapport à une seule ligne de développement :
- Les développeurs peuvent valider leurs modifications régulièrement et ne pas avoir à se soucier de la fusion jusqu’à une date ultérieure.
- Le processus de fusion pourrait être délégué à un développeur spécifique qui a une meilleure idée de l’ensemble du projet ou du code que les autres développeurs.
- À tout moment, le chef de projet peut revenir en arrière et voir exactement le travail que chaque développeur a créé.
Il existe sans doute un argument pour les deux méthodes. Cependant, gardez à l’esprit que cet article se concentre sur Git, qui utilise la méthode du graphe orienté acyclique des systèmes de gestion de version de troisième génération.
2. Installer Git
Vous avez peut-être déjà Git sur votre système car il est parfois installé par défaut (ou un autre administrateur peut l’avoir installé). Si vous avez accès au système en tant qu’utilisateur régulier, vous pouvez exécuter la commande suivante pour déterminer si Git est installé :
ocs@ubuntu:~$ quel git
/usr/bin/git
Si Git est installé, le chemin d’accès à la commande git est fourni, comme indiqué dans la commande précédente. S’il n’est pas installé, vous n’obtenez aucune sortie ou une erreur comme celle-ci :
[ocs@centos ~]# quel git ?
/usr/bin/which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/
bin:/usr/sbin:/bin:/sbin:/root/bin)
En tant qu’administrateur sur un système basé sur Debian, vous pouvez utiliser la commande dpkg pour déterminer si le paquet Git a été installé :
root@ubuntu:~# dpkg -l git
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/
➥Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========-=============-=============-========================================
ii git 1:1.9.1-1ubun amd64 fast, scalable, distributed
➥revision con
En tant qu’administrateur sur un système basé sur Red Hat, vous pouvez utiliser la commande rpm pour déterminer si le paquet git a été installé :
[root@centos ~]# rpm -q git
git-1.8.3.1-6.el7_2.1.x86_64
Si Git n’est pas installé sur votre système, vous devez vous connecter en tant qu’utilisateur root ou utiliser sudo ou su pour installer le logiciel. Si vous êtes connecté en tant qu’utilisateur root sur un système basé sur Debian, vous pouvez utiliser la commande suivante pour installer Git :
apt-get install git
Si vous êtes connecté en tant qu’utilisateur root sur un système basé sur Red Hat, vous pouvez utiliser la commande suivante pour installer Git :
yum install git
Obtenez plus que Git
Pensez à installer le progiciel git-all. Ce package comprend des packages de dépendances supplémentaires qui ajoutent plus de puissance à Git. Bien que vous n’utilisiez peut-être pas ces fonctionnalités au début, il vaut mieux les avoir disponibles lorsque vous serez prêt à exécuter des fonctions Git plus avancées.
3. Concepts et fonctionnalités de Git
L’un des challenges d’utiliser Git est juste de comprendre les concepts sous-jacents. Si vous ne comprenez pas les concepts, alors toutes les commandes ressemblent à une sorte de magie noire. Cette section se concentre sur les concepts critiques de Git et vous présente certaines des commandes de base.
Étapes Git
Il est très important de vous rappeler que vous vérifiez un projet entier et que la plupart du travail que vous effectuez sera local pour le système sur lequel vous travaillez. Les fichiers que vous extrayez seront placés dans un répertoire sous votre répertoire personnel.
Pour obtenir une copie d’un projet à partir d’un référentiel Git, vous utilisez un processus appelé clonage. Ce dernier ne crée pas simplement une copie de tous les fichiers du référentiel ; il remplit en fait trois fonctions principales :
- Crée un référentiel local du projet sous le répertoire
nom_projet/.gitdans votre répertoire personnel. Les fichiers du projet à cet emplacement sont considérés comme extraits du référentiel central. - Crée un répertoire dans lequel vous pouvez voir directement les fichiers. C’est ce qu’on appelle la zone de travail. Les modifications apportées dans la zone de travail ne sont pas immédiatement contrôlées par version.
- Crée une zone intermédiaire. Cette dernière est conçue pour stocker les modifications apportées aux fichiers avant de les valider dans le référentiel local.
Cela signifie que si vous clonez un projet appelé Jacumba, le projet entier serait stocké dans le répertoire Jacumba/.git sous votre répertoire personnel. Vous ne devez pas essayer de les modifier directement. Au lieu de cela, regardez directement dans le répertoire ~/Jacumba pour voir les fichiers du projet. Ce sont les fichiers que vous devez modifier.
Modifier un fichier
Supposons que vous ayez apporté une modification à un fichier, mais que vous deviez travailler sur d’autres fichiers avant d’être prêt à valider les modifications dans le référentiel local. Dans ce cas, vous devriez mettre en scène le fichier sur lequel vous avez fini de travailler. Cela le préparerait à être engagé dans le référentiel local.
Après avoir effectué toutes les modifications et organisé tous les fichiers, vous les validez dans le référentiel local.
Sachez que la validation des fichiers intermédiaires ne les envoie qu’au référentiel local. Cela signifie que vous seul avez accès aux modifications qui ont été apportées. Le processus d’archivage des nouvelles versions dans le référentiel central est appelé un push.
Choisir votre hébergeur de référentiel Git
Tout d’abord, la bonne nouvelle est que de nombreuses organisations fournissent l’hébergement Git. Au moment de la rédaction de cet article, il y a plus de deux douzaines de choix. Cela signifie que vous avez le choix entre de nombreuses options. C’est la bonne nouvelle… et la mauvaise nouvelle.
Ce ne sont que de mauvaises nouvelles car cela signifie que vous devez vraiment passer du temps à rechercher les avantages et les inconvénients des sociétés d’hébergement.
Par exemple, la plupart ne facturent pas l’hébergement de base, mais facturent les projets à grande échelle. Certains ne fournissent que des référentiels publics (tout le monde peut voir votre référentiel) tandis que d’autres vous permettent de créer des référentiels privés. Il existe de nombreuses autres fonctionnalités à prendre en compte.
Une fonctionnalité qui pourrait figurer en tête de votre liste est une interface Web. Bien que vous puissiez effectuer à peu près toutes les opérations de référentiel localement sur votre système, pouvoir effectuer certaines opérations via une interface Web peut être très utile. Explorez l’interface fournie avant de faire votre choix.
À tout le moins, je recommande de considérer ce qui suit :
- https://bitbucket.org
- https://www.cloudforge.com
- https://www.codebasehq.com
- https://github.com
- https://gitlab.com
Configurer Git
Maintenant que vous avez parcouru toute la théorie, il est temps de faire quelque chose avec Git. La section suivante suppose ce qui suit :
- Vous avez installé le progiciel git ou git-all sur votre système.
- Vous avez créé un compte sur un service d’hébergement Git.
La première chose à faire est d’effectuer une configuration de base. Chaque fois que vous effectuez une opération de validation, votre nom et votre adresse e-mail seront inclus dans les métadonnées. Pour définir ces informations, exécutez les commandes suivantes :
ocs@ubuntu:~$ git config --global user.name "Martin Dubois"
ocs@ubuntu:~$ git config --global user.email "martin@hebergeurcloud.com"
Évidemment, vous allez remplacer « Martin Dubois » par votre nom et « martin@hebergeurcloud.com » par votre adresse e-mail. L’étape suivante consiste à cloner votre projet à partir du service d’hébergement Git. Notez qu’avant le clonage, un seul fichier se trouve dans le répertoire personnel de l’utilisateur :
ocs@ubuntu:~$ git config --global user.name "Martin Dubois"
ocs@ubuntu:~$ git config --global user.email "martin@hebergeurcloud.com"
ocs@ubuntu:~$ ls
first.sh
Les éléments suivants ont cloné un projet nommé ocs :
ocs@ubuntu:~$ git clone https://gitlab.com/martin/ocs.gi
Cloning into 'ocs'...
Username for 'https://gitlab.com': martin
Password for 'https://martin@gitlab.com':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Checking connectivity... done.
Une fois l’exécution réussie, notez un nouveau répertoire dans le répertoire de base de l’utilisateur :
ocs@ubuntu:~$ ls
first.sh ocs
Si vous basculez vers le nouveau répertoire, vous pouvez voir ce qui a été cloné à partir du référentiel (un seul fichier existe jusqu’à présent dans le référentiel) :
ocs@ubuntu:~$ cd ocs
ocs@ubuntu:~/ocs$ ls
README.md
Ensuite, créez un nouveau fichier dans le répertoire du référentiel. Vous pouvez soit en créer un à partir de zéro, soit copier un fichier depuis un autre emplacement :
ocs@ubuntu:~/ocs$ cp ../first.sh
N’oubliez pas que tout ce qui est placé dans ce répertoire n’est pas géré par version car il s’agit du répertoire de travail. Pour le mettre dans le référentiel local, vous devez d’abord l’ajouter à la zone de préparation, puis vous devez le valider dans le référentiel :
ocs@ubuntu:~/ocs$ git add first.sh
ocs@ubuntu:~/ocs$ git commit -m "added first.sh"
[master 3b36054] added first.sh
1 file changed, 5 insertions(+)
create mode 100644 first.sh
La commande git add place le fichier dans la zone de préparation. La commande git commit prend tous les nouveaux fichiers dans la zone préparation et les valide dans le référentiel local. Vous utilisez l’option -m pour ajouter un message ; dans ce cas, la raison de la validation a été donnée.
Il est important de souligner qu’aucune modification n’a été apportée au référentiel sur le serveur. La commande git commit met uniquement à jour le référentiel local.
Vous devrez probablement apporter des modifications supplémentaires à votre projet local, puis archiver (push) les modifications dans le référentiel du serveur :
ocs@ubuntu:~/ocs$ git push -u origin master
Username for 'https://gitlab.com': martin
Password for 'https://martin@gitlab.com':
Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 370 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://gitlab.com/martin/ocs.git
12424f5..3b36054 master -> master
Branch master set up to track remote branch master from origin
À ce stade, toutes les modifications des fichiers de la zone de préparation ont été mises à jour vers le référentiel local et le référentiel du serveur central.
