Explorer le contrôle de version à l’aide de Git

Effectué

Il existe différents types de systèmes de contrôle de version (VCS), mais ils peuvent généralement être classés comme centralisés et distribués. Au cours des dernières années (partiellement en raison de la popularité croissante de DevOps), la dernière catégorie a gagné une popularité significative, avec Git devenant la norme de facto dans le développement de logiciels modernes. Ce VCS particulier serait le choix le plus approprié pour l’organisation dans notre exemple de scénario, en particulier compte tenu de son intention d’utiliser GitHub comme plateforme cible pour sa transition DevOps. Dans cette unité, explorez l’utilisation de Git comme contrôle de version.

Contrôle de version centralisé et distribué

Les systèmes de contrôle de version centralisés (CVCS) et les systèmes de contrôle de version distribués (DVCS) offrent la possibilité de gérer et de suivre les modifications apportées aux projets de développement de logiciels. Les principales différences entre elles sont liées à la façon dont elles implémentent des référentiels et de la collaboration. En particulier:

• Emplacement du référentiel : dans les systèmes centralisés, il existe une instance unique et centralisée du référentiel contenant l’historique complet du projet. Dans les systèmes distribués, chaque membre de l’équipe aurait généralement une copie locale entièrement fonctionnelle de l’ensemble du référentiel, y compris son historique de version complet.
• Connectivité réseau : dans les systèmes centralisés, l’accès à l’instance centralisée du référentiel est nécessaire pour effectuer de nombreuses actions, notamment les mises à jour et la récupération de l’historique. Dans les systèmes distribués, toutes les activités peuvent être effectuées sur la copie locale du référentiel.
• Modèle collaboratif : dans les systèmes centralisés, les développeurs examinent les fichiers de l’instance centralisée du référentiel tout en les connectant sur un réseau avant d’apporter des modifications et de valider les modifications. Cela empêche les modifications d’être extraites des fichiers par d’autres utilisateurs. Dans les systèmes distribués, les développeurs effectuent et valident les modifications apportées à leur copie locale du référentiel, qui, à un moment donné, sont synchronisées avec d’autres copies.
• Modèle de branchement et de fusion : dans les systèmes centralisés, la branchement et la fusion nécessitent généralement une coordination avec d’autres personnes. Dans les systèmes distribués, les branches peuvent être créées indépendamment dans des copies locales et fusionnées par la suite.

Il est important de noter que, bien que le modèle distribué ne repose pas sur l’utilisation d’un référentiel central (au sens traditionnel), il est courant d’implémenter une copie du référentiel, qui est hébergée par des services tels que GitHub, GitLab ou Bitbucket. Cette instance sert de point focal de collaboration et de synchronisation.

Terminologie Git

Afin de devenir compétent dans l’utilisation de Git, il est important de se familiariser avec sa terminologie. Certains des concepts sont propres à Git, ce qui le distingue d’autres DVCS. Les termes Git les plus fondamentaux sont les suivants :

• Arborescence de travail : structure de répertoire qui contient tous les fichiers du projet.
• Référentiel (communément appelé référentiel) : répertoire situé au niveau supérieur d’une arborescence de travail, hébergeant tous les fichiers du projet, ainsi que l’historique des versions de ces fichiers.
• Clone : action de création d’une copie d’un référentiel distant sur un ordinateur local pour travailler sur un projet auquel vous avez accès.
• Fork : action de création d’une copie hébergée par GitHub d’un référentiel distant pour travailler sur un projet auquel vous n’avez pas accès. Un fork est généralement utilisé si vous souhaitez contribuer au projet d'une autre personne ou bien créer votre propre version de ce projet. Bien que vous n'ayez pas accès en écriture au dépôt d'origine, vous pouvez entièrement gérer votre fork.
• Commit : capture instantanée des modifications apportées aux fichiers d’un référentiel à un moment spécifique. Les validations sont utilisées pour enregistrer et enregistrer les modifications.
• Zone intermédiaire un emplacement intermédiaire (qui ne fait pas partie du référentiel) où les modifications apportées aux fichiers de l’arborescence de travail sont préparées avant qu’elles ne soient validées. Il permet aux développeurs de sélectionner les modifications qu’ils ont l’intention de valider.
• Branche: série nommée de validations liées. En termes simples, une branche représente une version distincte d’un projet. Cela permet de travailler sur différentes parties d’un projet en même temps sans affecter sa version principale. La validation la plus récente au sein d’une branche est appelée head. La branche par défaut générée automatiquement lorsque vous initialisez un référentiel est appelé principal ou maître.
• Fusionner: processus de combinaison de modifications d’une branche (ou validation) dans une autre. Cela intègre les modifications d’une branche à une autre.
• Objet : un des quatre types d’entités disponibles dans un référentiel. Ces entités incluent des blobs représentant des fichiers individuels, un arbre représentant une arborescence de travail, un commit représentant une version spécifique de l'arborescence de travail et un tag, qui est une étiquette assignée à un commit individuel.
• Hachage : identificateur de longueur fixe et unique généré automatiquement qui représente le contenu d’un objet. Chaque fois que cet objet change, son hachage change également. Cela permet à Git de déterminer le contenu d’un dépôt mis à jour.
• Distant : référence à un autre référentiel (autre que celui local), pointant généralement vers l’instance hébergée par le service du référentiel. Cela sert de valeur par défaut pour les opérations de poussée et d’extraction.
• Extraction : action qui extrait les modifications d’un référentiel distant et les fusionne dans la branche actuelle.
• Evoyer (Push) : action qui envoie des validations locales à un référentiel distant, la mettant à jour avec les modifications apportées localement.
• Récupérer : l’action qui récupère les modifications d’un référentiel distant sans les fusionner automatiquement. Cela permet leur révision avant d’appliquer une fusion.
• Pull request : une fonctionnalité des plateformes d’hébergement basées sur Git (comme GitHub) qui permet aux développeurs de proposer des modifications et de demander leur fusion dans une branche cible.

Git dispose également d’un vaste ensemble de commandes, qui permettent d’implémenter et de gérer entièrement le contrôle de version via l’interpréteur de commandes tel que Linux Bash ou l’invite de commandes Windows. Vous pouvez également gérer Git via des applications de bureau telles que GitHub Desktop. Les plateformes d’hébergement basées sur Git fournissent une interface web qui facilite l’interaction avec les référentiels côté service.

Git et GitHub

Comme décrit précédemment, Git est un DVCS multiplateforme open source qui facilite la collaboration à l’aide de référentiels locaux, qui peuvent être synchronisés avec des référentiels distants. GitHub est un service cloud qui fournit une plateforme d’hébergement pour les dépôts Git. Il étend la gamme de fonctionnalités Git en incluant la prise en charge des éléments suivants :

• Référentiels distants : faciliter l’interaction entre les équipes distribuées.
• Outils de collaboration: fournir des fonctionnalités telles que des problèmes, des discussions, des demandes de tirage, des notifications, des étiquettes, des actions, des forks, des wikis et des projets.
• Interface web : minimisation de la nécessité d’utiliser des commandes Git
• Branche de protection: application de conditions qui doivent être satisfaites avant qu’une fusion puisse avoir lieu (par exemple, des révisions de demande de tirage terminées).