Gestion du cycle de vie d'un projet de modélisation

Utilisation de Git pour gérer le code source

Objective

After completing this lesson, you will be able to gérez les fichiers source à l'aide de Git.

Vue d'ensemble de Git

Pourquoi utiliser un système de contrôle de version ?

Il est très probable que plusieurs développeurs travaillent sur le même projet de modélisation. Les développeurs doivent travailler ensemble, ce qui signifie qu'ils ne doivent pas écraser le travail des autres, s'assurer qu'ils utilisent la dernière version de n'importe quel fichier et qu'ils peuvent également revenir à une version précédente d'un fichier si des erreurs sont détectées. Pour gérer ces besoins, un système de contrôle de version de code source est nécessaire.

Le système de contrôle de version de code source doit pouvoir gérer des développements parallèles. Examinons un scénario commun :

Alors, comment gérez-vous cette demande ? Pour le moment, votre développement actuel n'est pas terminé, ni testé, mais vous devez corriger votre version 2.1.0. Bien sûr, vous souhaitez commencer à partir de la dernière version (vous ne voulez pas inclure une partie des fonctionnalités futures dans le correctif), mais votre correctif peut affecter certains fichiers que vous avez déjà modifiés dans le cadre du développement de nouvelles fonctionnalités.

C'est là qu'un système de contrôle de version entre en jeu. Il vous permet de conserver un historique complet des modifications en utilisant des types de jalons lors du développement de votre code, à un niveau très précis si nécessaire. Vous pouvez également brancher votre code, ce qui signifie que vous pouvez développer et tester différentes fonctionnalités dans différents threads de développement parallèles (branches). Si une branche de fonctionnalités est prête à l'emploi, vous pouvez fusionner cette branche avec la branche principale. Si ce n'est pas le cas, vous pouvez poursuivre votre développement, voire vous débarrasser de cette branche si vous réalisez qu'une option de développement pour une fonctionnalité n'était pas pertinente et que vous devez y réfléchir à nouveau.

Avantages clés d'un système de contrôle de version

  • Sauvegarde du code source

  • Un historique des modifications complet

  • Fonctionnalités de ramification et de fusion

  • Traçabilité (par exemple, connexion d'une modification au logiciel de gestion de projets)

Git en bref

Git est un système de contrôle de version distribué (D-VCS) utilisé pour gérer le code source dans le développement logiciel.

Il permet à un ou plusieurs développeurs de travailler localement avec leur propre copie du référentiel Git.

Remarque

Git peut également être utilisé même en dehors d'un contexte de collaboration, pour vous aider à contrôler le développement d'un projet sur lequel vous travaillez seul, grâce à un certain nombre de capacités.

L'architecture de Git est distribuée. C'est quelque part entre purement local et purement central. Une architecture locale rendrait difficile la collaboration de plusieurs développeurs. Une solution centralisée permet la collaboration, mais dans certains cas, un développeur doit bloquer un morceau de code sur le référentiel central tout en travaillant dessus.

Au lieu de cela, Git est conçu pour que chaque développeur puisse garder localement sur son ordinateur toute l'histoire d'un projet (ou seulement une partie de celui-ci, selon ses besoins).

Git est un logiciel libre distribué sous GNU GPL (General Public License).

Remarque

L'objectif initial de Git n'est PAS la révision du code ou le déploiement automatisé d'applications. Pour ce faire, d'autres outils existent, souvent avec une connectivité avancée à Git, tels que Gerrit pour la révision du code ou Jenkins pour l'intégration et le déploiement automatisés.

Architecture Git

Remarque

Dans Git, il est même possible pour un développeur de définir le référentiel local d'un autre développeur comme référentiel distant et de synchroniser leur développement. Cela nécessite un accès au réseau et les autorisations pertinentes.

Les référentiels Git partagés peuvent être hébergés en interne sur l'infrastructure informatique d'une entreprise ou sur des services d'hébergement Git publics tels que GitHub.

Cycle de vie des fichiers dans Git

Lorsque vous travaillez avec des fichiers localement dans Git, cela implique trois zones logiques principales.

  • Répertoire de travail.

  • La zone de mise à disposition, également appelée INDEX.

  • Référentiel Git (local).

Ce ne sont pas toutes des zones réelles, dans le sens où un fichier donné n'est pas nécessairement matérialisé dans chacune d'elles. Expliquons cela à l'aide d'un diagramme.

La façon de gérer les fichiers dans un référentiel Git local est très simple, en s'appuyant sur un petit nombre d'actions.

La zone intermédiaire est l'emplacement virtuel où vous placez toutes les modifications que vous voulez inclure dans votre prochain commit.

Remarque

Lorsque votre répertoire de travail contient des modifications que vous ne souhaitez PAS inclure dans votre prochaine validation, il vous suffit de vous assurer de NE PAS mettre en scène les fichiers correspondants avant de le valider.

L'historique Git

Git est très doué pour représenter l'histoire d'un projet de manière simple, comme la succession de commits.

Au fil du temps, toutes les validations que vous exécutez dans votre projet sont ajoutées à l'historique et chaque validation (à l'exception de la validation initiale) référence sa validation parent.

Avec chaque validation, Git conserve un enregistrement de la date de validation, de l'identité du développeur qui l'a exécutée et des informations utiles sur les fichiers affectés (ajoutés, modifiés ou supprimés).

Concept de branche dans Git

Branching est l'un des concepts fondamentaux de Git, qui offre une grande flexibilité à un coût très faible. Qu'est-ce qu'une branche ?

D'un point de vue conceptuel, une branche est une série de commits. Techniquement, une branche est juste un pointeur qui référence un commit particulier de l'historique du projet.

Chaque référentiel Git possède toujours au moins une branche. La branche par défaut est généralement appelée maître.

À de nombreuses fins différentes, vous pouvez créer une nouvelle branche et valider vos modifications dans une branche existante.

Découvrons la figure, Le concept de branche. Après le commit C3, une nouvelle branche Feature32 a été créée pour prendre en charge le développement d'une nouvelle fonctionnalité. Deux commits, C5 et C6, ont été faits à cette branche. Entre-temps, des modifications supplémentaires ont été effectuées dans la branche principale (commit C4).

Utilisation de Git

Maintenant que vous connaissez bien les fondamentaux de GIT, voyons les options disponibles pour GIT avec SAP Business Application Studio.

SAP Business Application Studio dispose d'un référentiel local pour GIT, il est recommandé de toujours sauvegarder le travail dans les référentiels distants. Le référentiel distant peut être public ou privé (GIT d'entreprise).

Pour ce cours, nous allons nous concentrer sur l'utilisation du GIT public en particulier github https://github.com/. Comme mentionné précédemment, vous pouvez utiliser n'importe quel autre si vous possédez déjà un compte ou si vous êtes familiarisé avec l'outil.

SAP Business Application Studio est fourni avec un ensemble prédéfini d'environnements de développement, d'outils automatiques, de plug-ins pour prendre en charge Github, de sorte qu'aucun outil ou installation supplémentaire n'est requis, mais seulement quelques conditions préalables à remplir.

Conditions préalables

  1. Compte sur https://github.com :

    Connectez-vous à https:// github.com et suivez le processus de création de compte étape par étape.

  2. Référentiel sur https://github.com :

    Une fois le compte créé, accédez aux référentiels dans le menu et créez un référentiel.

Une fois ces conditions préalables remplies, vous pouvez commencer à lier le référentiel local au processus de référentiel Github dans SAP Business Application Studio dans votre espace de développement.

  1. Configurez votre nom d'utilisateur Git, e-mail :

    git config --global user.email "git_email@company.com"

    git config --global user.name "nom_utilisateur"

    Remarque

    Ce processus est réalisé sur le dossier racine Terminal → Nouveau Terminal → projets cd

    git config –list est utilisé pour récupérer les identifiants utilisateur enregistrés lors de la configuration.

  2. Initialiser le répertoire local en tant que référentiel Git :

    git --init

    Ici, nous initialisons le répertoire local en tant que référentiel Git. Ce point est local et n'est pas écrit dans lié au référentiel.
  3. Ajoutez les fichiers dans votre nouveau référentiel local :

    git ajouter .

    Une fois que nous avons initialisé le dépôt, nous pouvons ajouter les fichiers à ce référentiel prêt pour le premier commit.

  4. Validez les fichiers que vous avez planifiés dans votre référentiel local :

    git commit -m "Première validation(texte libre)"

    Cette étape valide les fichiers d'étapes dans le référentiel local.

  5. Créez une nouvelle :succursaleprincipale.

    Branche git - M principal

    Cela créera une nouvelle branche nommée Principal. Il peut s'agir de n'importe quel nom.

  6. Indiquez le lien du référentiel distant :

    git distant add origin https://<URL hôte Git>/<chemin complet vers référentiel>

  7. Pousser vers le référentiel distant :

    Git - Origine push - Principal

  8. ID utilisateur et mot de passe :

    Il vous est demandé de saisir le nom d'utilisateur et le mot de passe pour Git ici et de poursuivre, afin d'éviter cette étape pour chaque push que nous avons les options ci-dessous.

    • Utilisation du jeton :

      SAP Business Application Studio prend en charge les jetons d'accès du personnel au lieu des mots de passe.

      Les jetons d'accès personnels sont une alternative à l'utilisation de mots de passe pour l'authentification à GitHub lors de l'utilisation de l'API GitHub ou de la ligne de commande, c'est-à-dire la fonction de jetons d'accès personnels comme les jetons d'accès OAuth ordinaires. Ils peuvent être utilisés à la place d'un mot de passe pour Git via HTTPS.

      Les jetons d'accès personnels ne peuvent être utilisés que pour les opérations Git HTTPS. Si votre référentiel utilise une URL distante SSH, vous devrez passer de SSH à HTTPS.

      Vous devez créer un jeton d'accès personnel à utiliser à la place d'un mot de passe avec l'interface utilisateur Github ou avec la ligne de commande.

      Pour créer un jeton, suivez les instructions décrites dans la documentation GitHub.

      Création d'un jeton d'accès personnel

      Cette diapositive montre comment créer un jeton d'accès personnel.
      1. Dans le coin supérieur droit de la page Github, cliquez sur Paramètres.
      2. Cliquez sur Paramètres développeur.
      3. Cliquez sur Jetons d'accès personnels.
      4. Cliquez sur Générer un nouveau jeton.
      5. Indiquez un nom pour le jeton.
      6. Sélectionnez Périmètres, autorisations, pour utiliser votre jeton pour accéder aux référentiels à partir de la ligne de commande, sélectionnez Référentiel.

      Utilisation d'un jeton sur la ligne de commande

      clonage git https://github.com/username/repo.git

      Nom d'utilisateur : votre_nom d'utilisateur

      Mot de passe : votre_token

    • Mise en cache du mot de passe/jeton : .

      Cela évite les efforts pour saisir les identifiants à chaque poussée.

      Assistant d'identifiants Git :

      Saisissez les commandes ci-dessous une fois que vous vous êtes connecté avec succès lorsque vous poussez pour la première fois depuis le terminal.

      cache git config credential.helper –timeout=3600000 (durée en millisecondes)

      Git config credential.helper store

      Pour effacer les identifiants, utilisez la commande ci-dessous, c'est-à-dire pour désactiver ce nom d'utilisateur/mot de passe mis en cache pour votre utilisateur de dossier Git local actuel.

      git config credential.helper ""

Remarque

Une autre option existe mais n'est pas couverte ici. Exemple d'utilisation de .netrc

Git à l'aide de l'option IU :

En plus de l'option Ligne de commande, SAP Business Application Studio fournit une interface utilisateur graphique pour l'exécution des commandes Git et la gestion de votre contrôle et versionnement de source.

Capture d'écran de l'interface utilisateur pour Git et les étapes du workflow. Tout d'abord, initiez git. Deuxième étape tout. Troisièmement, validez. Quatrièmement, poussez vers le référentiel.

Utilisation de fichiers dans un projet Git

Modifier le contenu de votre projet (avec ou sans Git) signifie créer, modifier et supprimer des fichiers. Avec Git, toutes ces modifications sont suivies dans votre répertoire de travail dès qu'elles sont effectuées, par exemple, lorsque vous sauvegardez un fichier que vous venez de modifier et répertorié dans la zone Statut du fichier.

Ensuite, pour chaque fichier, vous disposez des possibilités suivantes :

  • Planifiez la modification pour qu'elle soit incluse dans la prochaine validation.

  • Laisser la modification non mise à disposition (elle ne sera pas incluse dans la prochaine validation)

  • Rejeter la modification

La mise à disposition ou le rejet peut également être effectué pour l'ensemble complet des modifications.

L'étape suivante consiste à valider vos modifications, ce qui ajoutera un prochain commit à l'historique de la branche.

Remarque

Le concept de branches dans Git, déjà introduit, sera abordé plus en détail plus loin. Pour l’instant, considérons que vous travaillez sur une seule branche locale, par exemple, master.
Schéma des étapes du workflow. Tout d'abord, extrayez les fichiers du référentiel Git local. Ensuite, créez ou modifiez des fichiers et sauvegardez-les. Ensuite, mettez en scène tous les fichiers. Ensuite, validez et effectuez un push vers le référentiel.

Pour matérialiser ce workflow, un statut Git est affecté à chaque fichier. Ce statut est représenté par une icône dans l'espace de travail SAP Business Application Studio et/ou dans la zone Statut du fichier du volet Git. La liste des statuts de fichier possibles est la suivante :

Signification du statut Git des fichiers. A est nouveau et mis à disposition, U n'est pas mis à disposition. M est modifié et n'est pas mis à disposition. Les modifications non mises à disposition peuvent être annulées. D est supprimé (mis à disposition ou non mis à disposition). Un fichier rouge avec C est un conflit lors d'une opération de fusion ou de rebasage. Un fichier bleu avec C est une copie.

Remarque

Le statut Conflit (C) sera discuté ultérieurement.

Validation des modifications

Lorsque vous validez les modifications, vous ajoutez ces modifications à l'historique Git et indiquez une description du commit. À partir de ce moment, le volet Historique Git inclura cette validation et fournira l'identité de l'auteur de la validation, la date, la description de la validation et les détails sur lesquels les fichiers ont été affectés par la validation. Notez que la validation des modifications ne modifie pas votre répertoire de travail. Les fichiers validés sont toujours disponibles pour d'autres modifications et les fichiers nouveaux ou modifiés que vous n'avez pas encore validés sont toujours disponibles pour une validation à venir. Vous pouvez également rejeter les modifications apportées à ces fichiers non validés.

La description du commit fournit des informations importantes pour permettre la lisibilité de vos modifications, en particulier lorsque vous collaborez avec d'autres développeurs. Vous pouvez trouver un certain nombre de blogs et de tutoriels sur la façon d'écrire un bon message de validation. Voici des recommandations pour écrire un message de validation :

  • Commencez par un sujet relativement court (50 caractères max), en utilisant l'humeur impérative

  • Séparez l'objet et le corps par une ligne vide.

  • Fournir des informations sur ce que fait la modification et pourquoi (par exemple, quel problème elle résout)

  • Le cas échéant, indiquez l'URL d'un problème ou d'une spécification lié(e) dans un autre système (par exemple, JIRA).

Il est possible de modifier un commit précédent. Cela vous permet de remplacer la toute dernière validation par une nouvelle, après avoir planifié des fichiers supplémentaires. La description du commit d'origine s'affiche afin que vous puissiez la modifier avant de la valider à nouveau.

Attention

Vous ne devez pas modifier les commits qui ont été partagés avec d'autres développeurs, car cela modifierait un historique (partagé) sur lequel d'autres pourraient déjà avoir basé leur travail.

Vous trouverez de plus amples informations sur les fonctionnalités de Git pour SAP Business Application Studio à l'adresse https://help.sap.com/viewer/9d1db9835307451daa8c930fbd9ab264/Cloud/en-US/265962e20eee43f499516de9011ac2e3.html.

Configurer Git dans SAP Business Application Studio

DemoStart Demo
Learning

SAP FacebookSAP YoutubeSAP LinkedIn