14 Principes de base du contrôle de version

Le Contrôle de version consiste à gérer les modifications apportées à la base de code au fil du temps et potentiellement entre plusieurs développeurs travaillant sur le même projet. Cette pratique est également appelée contrôle de source. Le contrôle de version offre un instantané du développement et permet de suivre l’historique des commits du code. Il permet également de fusionner les contributions de code provenant de plusieurs sources et de gérer les conflits de fusion.

Un système de contrôle de version (ou système de gestion de contrôle de source) offre une suite de fonctionnalités permettant aux développeurs de suivre les modifications de code et de revenir à des versions précédentes de la base de code. De plus, il fournit une plate-forme collaborative pour le travail d’équipe tout en vous permettant de travailler de manière indépendante jusqu’à ce que vous soyez prêt à enregistrer votre travail. Un système de contrôle de version vise à vous aider à rationaliser votre travail tout en fournissant un emplacement centralisé pour votre code. Le contrôle de version est essentiel pour garantir que les progiciels de code testés et approuvés sont déployés dans l’environnement de production.

Git

Git est un puissant système de contrôle de version source ouverte^{. Contrairement à d’autres systèmes de contrôle de version qui considèrent le contrôle de version comme une liste de modifications basées sur des fichiers, Git considère ses données davantage comme une série d’instantanés d’un système de fichiers miniature. Un instantané représente l’état de tous les fichiers à un moment donné. Git stocke les références à ces instantanés dans le cadre de sa gestion des versions.}

Les équipes de développeurs utilisent Git de différentes manières en raison de son modèle distribué et accessible. Il n’y a pas de politique imposée quant à la manière dont une équipe doit utiliser Git. Cependant, les projets développent généralement leurs propres processus et politiques. Le seul impératif est que l’équipe comprenne et adhère au processus du flux de travail qui permet de valider fréquemment le code et de minimiser les conflits de fusion.

Un projet versionné avec Git se compose de trois zones : l’arbre de travail, l’environnement de simulation et le répertoire Git.

Au fur et à mesure que vous progressez dans votre travail, vous placez généralement vos validations dans l’environnement de simulation, puis vous les validez dans le répertoire (ou référentiel) Git. À tout moment, vous pouvez vérifier vos modifications à partir du répertoire Git.

Installation de Git

Pour vérifier si Git est déjà fourni avec votre système d’exploitation, exécutez la commande suivante à l’invite de commande :

git --version

Pour installer Git, rendez-vous sur le site de téléchargement⁸ et sélectionnez la version appropriée pour votre système d’exploitation, puis suivez les instructions.

Configuration d’un référentiel Git

Pour initialiser un référentiel Git dans un dossier de projet sur le système de fichiers, exécutez la commande suivante depuis le répertoire racine de votre dossier :

git init

Sinon, pour cloner un référentiel Git distant dans votre système de fichiers, exécutez la commande suivante :

git clone <remote_repository_url>

Les référentiels Git fournissent des URL SSH au format git@host:user_name/repository_name. git

Git fournit plusieurs commandes pour cette synchronisation avec un référentiel distant :

Git remote : Cette commande permet de gérer les connexions à des référentiels distants, y compris la création, la visualisation, la mise à jour et la suppression de ces connexions aux référentiels distants. Elle fournit également des alias pour référencer ces connexions plutôt que d’utiliser leur URL complète

La commande ci-dessous permet de répertorier toutes les connexions à des référentiels distants avec leur URL.

git remote -v

La commande ci-dessous permet de créer une nouvelle connexion à un référentiel distant.

git remote add <repo_name> <repo_url>

La commande ci-dessous permet de supprimer une connexion à un référentiel distant.

git remote rm <repo_name>

La commande ci-dessous permet de renommer une connexion distante de repo_name_1 à repo_name_2

git remote rename <repo_name_1> <repo_name_2>

Lors du clonage d’un référentiel distant, la connexion au référentiel distant est appelée origine.

Pour extraire (pull) les modifications d’un référentiel distant, utilisez soit Git fetch ou Git pull

La commande ci-dessous permet de récupérer une branche spécifique du référentiel distant.

git fetch <repo_url> <branch_name>

où repo_url est le nom du référentiel distant et branch_name est le nom de la branche.

Alternativement, pour récupérer toutes les branches, utilisez la commande ci-dessous :

git fetch —all

La commande ci-dessous permet d’extraire (pull) les modifications du référentiel distant.

git pull <repo_url>

La commande ci-dessus permet de récupérer la copie du référentiel distant de votre branche actuelle et fusionnera les modifications dans votre branche actuelle.

Si vous souhaitez voir ce processus en détail, utilisez le drapeau verbeux, comme indiqué ci-dessous :

git pull —verbose

Comme git pull utilise la fusion comme stratégie par défaut, si vous souhaitez utiliser rebase à la place, exécutez la commande ci-dessous :

git pull —rebase <repo_url>

Pour pousser les modifications vers un référentiel distant, utilisez git push, comme décrit ci-dessous :

git push <repo_name> <branch_name>

Où repo_name est le nom du référentiel distant et branch_name est le nom de la branche locale.

Git SSH

Une clé SSH est un moyen d’authentification pour le protocole Secure Shell (SSH) utilisé dans les réseaux. Cette technologie utilise une paire de clés – une clé publique et une clé privée – pour initier une connexion sécurisée entre des parties distantes.

Les clés SSH sont générées à l’aide d’un algorithme de cryptographie à clé publique.

Si vous souhaitez générer une clé SSH sur un Mac, vous pouvez utiliser la commande suivante :

ssh-keygen -t rsa -b 4096 -C "your_email@domain"

Après avoir été invité à spécifier le chemin de stockage de la clé, choisissez un fichier dans lequel vous voulez l’enregistrer.

Créez une phrase de passe sécurisée.

Ajoutez la clé SSH nouvellement générée au ssh-agent

ssh-add -K <file_path_from_step_2>

Git archive

Pour exporter un projet Git vers une archive, exécutez la commande suivante :

git archive --output=<output_archive_name> --format=tar HEAD

La commande ci-dessus génère une archive à partir du HEAD actuel du référentiel. Le HEAD fait référence au commit actuel.

Enregistrer les modifications

Lorsque vous modifiez votre code en local, que ce soit pour développer de nouvelles fonctionnalités ou corriger des bogues, vous aurez besoin de les simuler avant la mise en production. Pour ce faire, veuillez exécuter la commande suivante pour chaque fichier que vous souhaitez ajouter à l’environnement de simulation :

git add <file_name>

git commit -m <commit_message>“

La première commande permet de placer vos modifications dans l’environnement de simulation, tandis que la deuxième commande crée un instantané de ces modifications qui peut être envoyé au référentiel distant.

Si vous souhaitez ajouter tous les fichiers en une seule fois, vous pouvez utiliser la variante de Git add avec l’option —all.

Une fois que vous avez ajouté le(s) fichier(s) à la zone de préparation, ils sont suivis.

Synchronisation

Après avoir validé les modifications sur votre référentiel local, il est temps de synchroniser votre référentiel distant Git avec les validations effectuées localement. Veuillez consulter les commandes de synchronisation mentionnées au début de cette section pour effectuer une synchronisation.

Faire une demande pull

Une demande pull (extraction) est utilisée pour informer l’équipe de développement (ou les réviseurs assignés) des modifications apportées, telles qu’une nouvelle fonctionnalité ou une correction de bogue, afin qu’ils puissent examiner les modifications de code (ou commits) et les approuver, les refuser entièrement ou demander des modifications supplémentaires.

Dans le cadre de ce processus :

Un membre de l’équipe crée une nouvelle branche locale (ou crée sa branche locale à partir d’une branche distante existante) et y apporte des modifications.

Une fois les modifications finalisées, le membre de l’équipe les transmet à leur branche distante dans le référentiel distant.

Le membre de l’équipe crée une demande pull (extraction) en utilisant le système de contrôle de version. Au cours de cette procédure, il sélectionne les branches sources et de destination et affecte des réviseurs.

Le ou les réviseurs affecté(s) discutent des modifications de code en équipe à travers la plate-forme de collaboration intégrée au système de contrôle de version, et prennent finalement une décision d’accepter ou de refuser les modifications en totalité ou en partie.

L’étape 4 ci-dessus peut passer par plusieurs autres cycles ou de révisions.

Une fois que toutes les modifications ont été acceptées (ou approuvées) à la fin du processus de révision, le membre de l’équipe fusionne la branche distante dans le référentiel de code, ce qui ferme la demande pull (extraction).

Figure 8 : Exemples de demandes pull.

Commandes Git courantes

Le tableau ci-dessous répertorie certaines commandes Git couramment utilisées qui sont utiles de retenir. La figure 9 illustre le sens d’exécution relatif de certaines de ces commandes.

git config --global user.name “<user_name>”

git init

git clone <repo_url>

git remote add origin <remote_server>

git add <file_name>

git status

git commit -m "<message>"

git push origin master

git checkout -b <branch_name>

git checkout <branch_name>

git branch

git branch -d <branch_name>

git pull

git merge <branch_name>

git diff

git checkout -- <file_name>

git reset --hard origin/master

Figure 9 : Commandes Git courantes et directions d’exécution relatives.