Git Lab est un système de contrôle de version (VCS) basé sur Git. Git se concentre sur le stockage des versions de fichiers et est le système de versionnement le plus répandu sous la forme d'un logiciel open source. GitLab, quant à lui, est utilisé par les développeurs et les programmeurs pour travailler de manière agile et efficace sur des projets logiciels et web. Il est hébergé sur le propre serveur de l'entreprise. Le travail quotidien est facilité par le fait que plusieurs programmeurs peuvent développer simultanément et travailler sur différentes fonctionnalités. En effet, le système de versionnement permanent assure l'enregistrement de toutes les modifications. Ainsi, aucun travail n'est perdu ou écrasé par inadvertance. Les modifications apportées au code sont surveillées et peuvent être annulées si nécessaire. Les projets créés sont organisés dans des archives numériques appelées référentiels. Un référentiel contient tous les éléments d'un projet, y compris les fichiers PHP, JavaScript, HTML et CSS correspondants. En extrayant un projet, les participants téléchargent une copie de travail (Working Copy) d'un repository sur leur ordinateur et, après le traitement, la version modifiée est à nouveau archivée. GitLab est basé sur un modèle d'entreprise ouvert qui existe en deux modèles de licence : GitLab Community Edition (CE) et GitLab Enterprise Edition (EE).

GitHub est un service de gestion de versions en réseau pour les projets de développement de logiciels. Cette gestion de versions collaborative fonctionne sur le système de gestion de versions Git. Mais qu'est-ce que Git vs GitHub ? Git assure l'enregistrement de différents fichiers en tant que versions au cours des différentes phases d'un projet. GitHub, quant à lui, est un espace de stockage en nuage qui montre les modifications et les changements en temps réel. Contrairement à d'autres prestataires de services de logiciels open source, GitHub ne se concentre pas sur le projet en tant que collection de code source, mais sur l'utilisateur et ses bases de données de code source - également appelées référentiels. Il est également important de créer (GitHub branch) et de fusionner (GitHub merge) des scissions (GitHub forks). Cela facilite particulièrement le codéveloppement de projets étrangers, car les bases de données de code source permettent de scinder et d'effectuer des modifications. Ces modifications ne seront finalement reprises que plus tard. Comme toutes les étapes sont également possibles via l'interface web et qu'il existe un réseau social avec accès aux dépôts d'autres personnes ainsi qu'une application pour smartphone, GitHub est une plateforme de développement qui convient également aux débutants. La plateforme appartient à Microsoft depuis 2018. GitHub est plus grand que GitLab par exemple et bénéficie de la confiance pour sa longévité. De plus, davantage de développeurs travaillent à l'extension de la plateforme, ce qui permet d'obtenir un système très stable et plus performant.

Le serveur GitLab CI - également appelé coordinateur - n'exécute pas lui-même les builds. Il délègue cette tâche à des "runners". Un runner est un processus qui interroge le coordinateur afin de récupérer et de traiter les tâches en attente. Dans le principe du CD GitLab, on parle d'un pipeline GitLab. Ce pipeline GitLab définit sous quelle condition telle ou telle validation doit être vérifiée pour pouvoir publier les parties de logiciel correspondantes. Le versionnement du code et les techniques qui y sont liées, comme le "branching", jouent un rôle important dans CD.
GitLab peut être utilisé comme application basée sur le web ou peut être installé sur votre propre serveur (GitLab self-hosted). GitLab Pages permet d'héberger des sites web statiques et de créer des documentations de projet.

Un tutoriel GitLab comprend les contenus suivants :

• Créer des utilisateurs dans GitLab via "New User
• Créer un nouveau projet avec "New Project
• Travailler en équipe avec GitLab grâce aux autorisations et aux droits d'accès

Il est également possible d'acquérir des connaissances sur GitLab en suivant un cours Git.

TortoiseGit ou "Git Tortoise" est une interface utilisateur graphique libre pour le logiciel de gestion de versions Git sous Windows. Il est placé sous General Public License (GNU). "Git Tortoise" est implémenté comme une extension de shell et s'intègre dans l'explorateur Windows. Elle peut être utilisée indépendamment d'un environnement de développement intégré. Des icônes représentent l'état respectif comme versionné, inchangé, modifié ou ignoré. L'interaction principale se fait via le menu contextuel. Diverses actions y sont exécutées avec Commit, Push ou Pull, ainsi que l'ouverture de dialogues TortoiseGit. Le logiciel a pour tâches principales le contrôle des versions, des révisions et des sources. Techniquement, "Git Tortoise" est basé sur TortoiseSVN - étendu avec des aspects spécifiques à Git.

Lorsque l'on travaille avec Git, "enregistrer" est plus nuancé que dans un traitement de texte et comprend une collection de fichiers et de répertoires. Enregistrer est un synonyme du terme Git "Comitten" - dans le cas de l'enregistrement, il s'agit de "Commit". La commande Git "Git Commit" permet de capturer un instantané des modifications actuellement déployées dans le projet. De tels snapshots de committe sont considérés comme des versions sûres, car Git n'y effectue des modifications que sur instruction explicite. Avant la commande "Git Commit", il faut encore la commande "Git Add" pour enregistrer les modifications dans un commit, les transporter dans le projet dans l'environnement de staging ou les "stager". Les commandes "Git Commit" combinées à la commande "Git Add" font ainsi partie des commandes les plus fréquemment utilisées et constituent le flux de travail Git de base. Vient ensuite la commande "Git Status", qui permet d'obtenir l'état du répertoire de travail et de l'environnement de staging. La commande "Git Stash", quant à elle, a pour effet de mettre temporairement en attente (ou de staser) les modifications apportées à la copie de travail. Le programmeur peut ainsi se consacrer à d'autres tâches et appliquer les modifications plus tard. C'est pratique lorsqu'il est au milieu d'une modification de code, qu'il n'est pas encore prêt à committer et qu'il doit rapidement continuer à travailler sur quelque chose de complètement différent.

Un petit tutoriel Git explique le fonctionnement de Git :

• créer un projet "Repository" avec un outil d'hébergement Git, comme Bitbucket par exemple
• copier ou cloner le référentiel sur ton système local
• ajouter un fichier au référentiel local et effectuer un "commit" pour les modifications à "enregistrer".
• Déplacer les modifications par "push" dans ta branche principale
• apporter une modification au fichier à l'aide d'un outil d'hébergement Git et effectuer un commit pour cette modification
• effectuer un "pull" pour appliquer les modifications à ton système local
• créer une "branche Git" (une version Git), apporter une modification et effectuer un commit pour celle-ci
• ouvrir une "pull request" (proposition de modification de la branche maîtresse)
• effectuer un "merge" des modifications dans la branche master

L'introduction à Git, les commandes Git et l'installation de Git sont enseignées lors d'un cours Git.

SVN utilise un référentiel centralisé unique comme interface de communication pour les développeurs, la collaboration se faisant par le biais de changesets. Les changesets sont échangés entre les copies de travail des développeurs et le référentiel central. C'est la principale différence avec le modèle de collaboration distribuée de Git, où chaque développeur reçoit sa propre copie du référentiel avec son propre historique local ainsi que sa structure de branche. Ainsi, des branches entières (au lieu d'une série de commits successifs ou de changesets individuels) peuvent être partagées entre les référentiels. La commande "Git Remote" fait partie d'un vaste système de synchronisation des modifications. Git Remote" permet de se connecter à d'autres référentiels, d'y accéder ou de les supprimer. Les entrées via "Git Remote" sont utilisées conjointement avec les commandes "Git Fetch", "Git Push" et "Git Pull". La commande "Git Fetch" permet de télécharger des commits, des fichiers et des références d'un référentiel distant vers le référentiel local, afin de voir ce sur quoi tout le monde travaille. En voyant l'avancement dans l'historique central sans impact sur le travail de développement local. Les contenus récupérés doivent être explicitement extraits à l'aide de la commande "Git Checkout", afin de réviser en toute sécurité les commits avant leur intégration dans le référentiel local. La commande "Git Push" est utilisée pour télécharger des contenus d'un référentiel local vers un référentiel distant. Avec la commande "Git Push", tu transfères des commits de ton référentiel local vers un référentiel distant. Le pendant de cette commande est la commande "Git Fetch", qui importe des commits dans des branches locales. En effet, "Git Push" permet d'exporter des commits dans des branches distantes. Les branches distantes sont configurées avec la commande "Git Remote". Comme il existe un risque d'écraser les modifications lors de la poussée avec "Git Push", il convient d'être prudent. Pour télécharger des contenus d'un référentiel distant, il faut utiliser la commande "Git Pull". Cela permet d'actualiser immédiatement le référentiel local afin que les contenus correspondent. La fusion des modifications en amont avec ton référentiel local est souvent nécessaire dans les workflows de collaboration basés sur Git. La commande "Git Pull" est en fait une combinaison de commandes "Git Fetch" suivie de "Git Merge". "Git Pull" exécute d'abord une "Git Fetch" qui englobe la branche locale et renvoie à la HEAD. Dès que le contenu a été téléchargé, "Git Pull" lance un workflow de fusion. Un nouveau commit de fusion est créé et HEAD est ainsi mis à jour pour faire référence au nouveau commit. Ces commandes Git et d'autres ainsi que les outils Git peuvent être appris dans un cours Git.