Dans mon article précédent, « Comment annuler une validation dans Git » (un tutoriel PowerShell Git), j’ai montré comment vous pouviez utiliser un référentiel local PowerShell Git et exploiter les avantages du contrôle de code source local. Avec Git, vous pouvez créer des validations (« commits ») ou des instantanés de votre code et revenir aux versions précédentes. En général, lorsque vous travaillez avec Git et des référentiels de code, vous créez d’abord le référentiel distant, puis vous le téléchargez sur votre système local.
À l’inverse, si vous démarrez d’abord un projet sur votre système local et que vous devez ensuite vous connecter à un référentiel distant, il vous faudra fusionner les référentiels. Dans cet article, je vais vous montrer comment effectuer une fusion dans Git, c’est-à-dire prendre un référentiel local Git et le fusionner avec un référentiel distant de votre compte GitHub.
Pour suivre ce tutoriel PowerShell Git sur la fusion dans Git, vous aurez besoin des éléments suivants :
- Le client PowerShell Git installé sur votre système (Téléchargement et Guide d’installation)
- Un compte GitHub gratuit
- Vous connecter à GitHub avec SSH
- Des fichiers de projet
Accédez à une série de cours sur l’automatisation des tâches Active Directory à l'aide de PowerShell et obtenez 3 crédits CPE (cours en anglais)
1. Créer le référentiel local GitRepository
Tout d’abord, vous devez créer un référentiel local pour votre projet. Je vais utiliser PowerShell pour ce tutoriel, mais vous pouvez utiliser tout autre terminal à votre disposition. Sachez néanmoins que vous devrez utiliser des commandes équivalentes pour créer des dossiers et naviguer dans la structure des répertoires pour comprendre comment fusionner dans Git.
Commencez par créer un dossier pour stocker les fichiers de votre projet, puis sélectionnez ce répertoire dans la console. Initialisez ensuite le dossier en tant que référentiel Git à l’aide de la commande « git init ».
2. Créer la première validation Git
Une fois le référentiel local Git créé, vous devez ajouter des fichiers au projet. Je vais créer un script PowerShell qui affiche « Hello World! » sur la console, puis vérifier la sortie du script.
- New-Item -Name HelloWorld.ps1 -ItemType File
- Add-Content -Value ‘“Hello World!”’ -Path .\HelloWorld.ps1
- .\HelloWorld.ps1
Le référentiel possède un fichier non suivi à utiliser pour créer la première validation. Vous pouvez afficher les fichiers non suivis en exécutant la commande « git status ». Vous pouvez ajouter le fichier à la zone de transit en utilisant la commande « git add » et en spécifiant le nom du fichier. Ensuite, créez une validation avec « git commit » en utilisant l’option –m pour ajouter un message à la validation.
3. Créer le référentiel GitHub
Bien que l’utilisation d’un référentiel local Git soit utile, l’objectif principal du contrôle du code source est de collaborer sur des projets avec d’autres personnes. Vous devez maintenant prendre le référentiel local Git et le placer dans un référentiel distant et centralisé, afin que d’autres personnes puissent collaborer au projet. Le stockage du code du projet dans un référentiel distant et centralisé permet à d’autres collaborateurs de copier le code dans leur système et d’y apporter des modifications.
S’il existe de nombreuses façons de disposer d’un référentiel central Git, une option facile est de le stocker dans GitHub. GitHub est une implémentation populaire de Git, qui propose des comptes gratuits pour l’hébergement des référentiels.
Sur votre page de profil GitHub, sélectionnez Repositories en haut, puis cliquez sur New.
Sur l’écran Create a new repository, saisissez un nom de référentiel unique qui n’existe pas dans votre compte. Je vous conseille de lui donner le même nom que le projet dans votre système local ; ici, cela sera mon_projet. Ensuite, saisissez une description du projet, précisez si le projet est public ou privé, puis choisissez l’une des options pour initialiser des fichiers de projet additionnels. Puisque vous importez un référentiel existant, vous ne devriez pas avoir besoin de sélectionner des fichiers supplémentaires, car ils doivent normalement exister dans le référentiel local (si vous les créez). Une fois que vous avez configuré tous les paramètres, cliquez sur Create repository.
4. Envoyer un référentiel local Git existant
Une fois le nouveau référentiel Git créé, GitHub vous donne plusieurs options pour démarrer avec ce référentiel. Vous pouvez le copier sur votre système local, créer un nouveau référentiel sur votre système et le lier, ou importer du code à partir d’un autre référentiel.
En ce qui nous concerne, nous voulons pousser (« push ») un référentiel Git existant à partir de la ligne de commande. Nous avons déjà un référentiel local Git que nous voulons lier à notre nouveau référentiel distant sur GitHub, ceci afin d’y envoyer notre code. Cliquez sur l’icône « Copy » pour enregistrer cet extrait de code et l’exécuter sur notre terminal PowerShell.
Avant d’exécuter le code dans mon terminal PowerShell, il faut savoir à quoi sert chaque commande, car elles sont toutes essentielles pour comprendre la fusion dans Git.
Git Remote Add Origin
Cette commande configurera le nouveau référentiel GitHub en tant que référentiel distant et en fera la source pour la suite. Lorsque d’autres collaborateurs apporteront des modifications au référentiel hébergé sur GitHub, vous pourrez par la suite tirer ces mises à jour vers votre système local. Vous pouvez vérifier le paramètre modifié en exécutant git remote -v pour vérifier que l’URL de l’origine correspond au référentiel distant.
Le nom de l’origine peut être tout ce que vous voulez ; cependant, dans le monde des committers, la connexion à distance du référentiel est habituellement nommée « origin ».
Git Branch
Cette commande oblige à renommer la branche locale « branche principale » (« main ») pour s’assurer qu’elle correspond au nom de la branche principale du référentiel GitHub. Cette étape peut ne pas être nécessaire, mais il est bon de l’exécuter pour vérifier que les noms des branches correspondent.
Enfin, nous devons envoyer notre référentiel local vers le référentiel distant GitHub à l’aide de la commande git push.
Git Push
Ici, origin fait référence au référentiel distant que nous avons configuré précédemment, et main fait référence à la branche du référentiel local à copier vers le référentiel distant.
Comme c’est la première fois que nous envoyons du code dans le référentiel distant GitHub pour la branche principale, nous devons spécifier le paramètre -u, qui est mis pour –set-upstream. Définir la branche en amont (« upstream ») configurera la branche distante par défaut pour la branche locale actuelle. Cette relation est configurée dans la sortie de la commande d’envoi « push ».
5. Visualiser le référentiel GitHub mis à jour
De retour dans GitHub, actualisez la page du référentiel affichant actuellement les exemples de code, et vos fichiers locaux devraient maintenant s’afficher comme disponibles dans le référentiel. Dans le cas de mon projet, je peux voir le script HelloWorld.ps1 avec mon message de validation.
6. Fusionner les historiques non liés
Lors de la création du référentiel GitHub, vous avez la possibilité d’initialiser le référentiel avec plusieurs fichiers, comme un fichier README.md. Ce fichier est écrit en Markdown et affiche son contenu dans la page du référentiel. Il est souvent utilisé pour expliquer le projet ou fournir de la documentation sur la façon de l’utiliser.
Puisque j’allais importer un référentiel existant à partir de mon système local, il n’était pas nécessaire d’initialiser le référentiel avec ce fichier. Toutefois, examinons ce qui se passe si je crée le référentiel distant avec des fichiers et que j’ai besoin de le synchroniser avec mon référentiel local.
De retour dans GitHub, j’ai créé un nouveau référentiel nommé mon_projet_2 pour stocker mon deuxième projet PowerShell. J’ai coché la case pour inclure un fichier README.md lors de la configuration du référentiel. Voici à quoi ressemble ce nouveau référentiel de projet (notez le contenu du fichier README affiché) :
Avant de revenir à mon terminal, j’ai besoin de l’URL de ce référentiel pour pouvoir l’ajouter comme origine dans mon référentiel local. Pour trouver l’URL, cliquez sur le bouton Code et copiez l’URL HTTPS.
Revenons maintenant à ma fenêtre PowerShell, dans laquelle j’ai déjà créé le référentiel local et effectué la première validation. Tout d’abord, je dois ajouter l’URL que je viens de copier en tant qu’origine nommée du référentiel source :
Ensuite, je dois tirer le contenu du référentiel distant GitHub (c’est à dire le fichier README.md) vers mon système local. Je peux le faire en utilisant la commande « git pull » et en spécifiant le référentiel distant d’origine et la branche principale locale :
Cependant, cette commande entraînera une erreur fatale :
Fatal: refusing to merge unrelated histories
Étant donné que nous avons deux projets sans lien entre eux avec des historiques différents, Git refuse de les fusionner. Les deux projets possèdent des historiques de validation distincts, qui ne sont pas compatibles entre eux. Heureusement, nous pouvons forcer Git à fusionner les deux malgré les historiques non liés grâce au paramètre –allow-unrelated-histories, comme ceci :
Le fichier README.md du référentiel distant GitHub est maintenant disponible dans mon projet local. De là, je peux modifier le fichier README.nd localement, valider les changements et les renvoyer vers GitHub.
Dans cet article, j’ai expliqué comment fusionner des référentiels dans Git en prenant un référentiel local de code et en le reliant à un référentiel distant GitHub. En plaçant votre code dans un référentiel hébergé à distance, d’autres personnes peuvent collaborer avec vous en envoyant leurs modifications vers le code du projet. Travailler avec Git et les référentiels est une compétence essentielle pour tout développeur ou administrateur qui doit collaborer sur un projet de codage ou le partager.
Que dois-je faire maintenant ?
Vous trouverez ci-dessous trois solutions pour poursuivre vos efforts visant à réduire les risques liés aux données dans votre entreprise:
Planifiez une démonstration avec nous pour voir Varonis en action. Nous personnaliserons la session en fonction des besoins de votre organisation en matière de sécurité des données et répondrons à vos questions.
Consultez un exemple de notre évaluation des risques liés aux données et découvrez les risques qui pourraient subsister dans votre environnement. Cette évaluation est gratuite et vous montre clairement comment procéder à une remédiation automatisée.
Suivez-nous sur LinkedIn, YouTube et X (Twitter) for pour obtenir des informations sur tous les aspects de la sécurité des données, y compris la DSPM, la détection des menaces, la sécurité de l’IA et plus encore.