Source Control Management (SCM) est le nom donné à la méthode de travail avec des sous-versions ou des sauvegardes de vos projets via un référentiel et une source locale. Fondamentalement, une solution SCM est un progiciel indépendant qui contrôle tous les aspects de la maintenance, de la modification et de la comparaison des versions de votre projet au fur et à mesure que vous y travaillez. Ceci est particulièrement utile pour ceux qui travaillent en équipe et qui doivent pouvoir contrôler qui fait quoi et ne pas s'inquiéter de perdre des données ou de faire des changements qui pourraient devoir être annulés à une date ultérieure, mais les individus peuvent bénéficier de ce puissant mais flexible système aussi.

Plusieurs outils SCM sont à votre disposition, et GameMaker Studio 2 est livré avec un plugin Git qui peut être utilisé immédiatement, et vous n'avez pas besoin d'installer des paquets supplémentaires car ils sont tous fournis avec le plugin lui-même. Ci-dessous nous donnons un petit tutoriel sur comment configurer ce plugin et utiliser les outils SCM avec un projet. Au bas de la page, nous donnons également un aperçu du menu contextuel SCM, qui est également référencé dans les sections du didacticiel.

Configuration du plugin Git de contrôle de source

Tout d'abord, nous devons configurer une identité pour que Git s'engage, ce qui signifie que nous devons aller à la section PLugins - Source Control (Git) des Préférences et ajouter vos détails d'authentification.

Cette identité d'authentification sera utilisée pour tous les projets futurs, et GameMaker Studio 2 vous donne deux façons différentes de le configurer:

• Nom d'utilisateur et mot de passe: Cliquer sur le bouton "Ajouter un nouvel utilisateur / Passer l'authentification" vous présentera la fenêtre suivante où vous pouvez entrer l' URL du référentiel, le nom d' utilisateur et le mot de passe: Si vous souhaitez que cela affecte uniquement un référentiel spécifique, placez l'URL du référentiel dans le champ supérieur. Cependant, si c'est l'authentification à l'échelle du domaine que vous voulez (c.-à-d. bitbucket.org " ou " github.com Ensuite, il suffit de placer le domaine et rien d'autre.Quand quelque chose doit vérifier l'authentification, il recherchera une correspondance de référentiel spécifique d'abord, puis une correspondance de domaine.Cela vous permettra d'avoir une authentification par défaut pour un domaine, et remplacer avec des détails spécifiques pour certains dépôts plus tard.
  REMARQUE: Si vous utilisez un référentiel externe, vous devez utiliser le nom d'utilisateur et le mot de passe associés au compte configuré pour ce référentiel, mais si vous souhaitez utiliser un référentiel local, vous pouvez utiliser n'importe quel nom d'utilisateur et mot de passe.
  
  
  
• Claviers SSH: Cliquez sur le bouton "Ajouter une nouvelle authentification Keypair SSH" pour afficher la fenêtre suivante dans laquelle vous pouvez saisir l' URL et le mot de passe du référentiel avant de donner les chemins d'accès aux fichiers Clé publique et Clé privée requis: Comme les authentifications Nom d'utilisateur / Mot de passe, vous pouvez avoir des authentifications spécifiques au domaine et au référentiel lors de l'utilisation de paires de clés SSH. Si vous avez déjà une paire de clés SSH générée, vous pouvez définir les chemins ici, ainsi que tout mot de passe requis pour y accéder. Notez que si vous avez besoin d'un accès rapide à la clé publique, le bouton de copie copiera automatiquement le contenu dans le presse-papiers pour vous. Si vous ne disposez pas déjà d'une paire de clés SSH, cliquez sur le bouton Créer une paire de clés pour ouvrir une boîte de dialogue indiquant où placer la clé privée et la clé publique sera créée à côté de celle-ci. clés publiques et privées automatiquement pour vous.

Ces paramètres seront désormais utilisés pour communiquer avec le référentiel (IE: Git Hub, Bit Bucket, etc.) lors de la gestion des requêtes clones, push et pull. Cependant, vous devez toujours configurer les options par projet, ce qui peut être fait en ouvrant les options principales et en cliquant sur l'option Activer le contrôle de source. Cela activera SCM pour le projet en cours.

Une fois que vous avez activé le contrôle de la source (et l'avez appliqué ou fermé), un nouveau menu contextuel apparaîtra en haut de l'EDI avec l'option suivante (que nous explorerons dans les autres sections de cette page):

REMARQUE: Si vous devez modifier à nouveau les détails d'authentification, double-cliquez sur l'entrée et la fenêtre de détails s'ouvrira pour que vous puissiez la modifier, mais vous ne pourrez pas renommer l'URL. Si vous devez modifier l'URL, vous devrez supprimer les détails d'authentification et les ajouter à nouveau. Pour supprimer les détails d'authentification, cliquez sur le bouton de fermeture à gauche de la ligne dans la fenêtre principale des Préférences.

Options de référentiel

Vous devez maintenant lier l' GameMaker Studio 2 à un référentiel:

• Créer un référentiel de projet
• Poussez le projet en cours dans un référentiel externe
• Cloner un référentiel existant

Dans le premier cas, en créant un référentiel de projet, cela créera un référentiel Git directement sur votre projet. Dans le langage Git, il s'agit d'un "référentiel non nu", le Push / Pull n'a donc aucun sens dans ce cas, mais vous pouvez toujours valider et suivre les modifications du projet, et inverser les modifications et les révisions si nécessaire. Pour le configurer, il suffit de cliquer sur Contrôle de la source > Créer un référentiel de projet dans le menu principal.

Cependant, vous avez peut-être déjà un projet existant et vous voulez le mettre dans un référentiel externe pour le suivi et le partage parmi votre équipe. Cela nécessite qu'un référentiel externe ait déjà été configuré, ainsi que le nom d'utilisateur et le mot de passe corrects définis dans vos préférences d'identité pour y accéder. Si vous avez cette option, cliquez sur Contrôle de la source > Importer le projet dans le référentiel et remplissez l'URL.

Enfin, en tant que fonction de commodité, vous pouvez Cloner un référentiel externe via l'EDI. Encore une fois, vous aurez besoin du nom d'utilisateur et du mot de passe pour le référentiel que vous allez connecter à configurer dans vos préférences d'identité, puis il suffit de cliquer sur Contrôle de la source > Référentiel de clonage. Remplissez l'URL (en utilisant la variante HTTPS plutôt que SSH) et dites où vous voulez que ça se passe.

Une fois le clonage terminé, un navigateur de fichiers s'ouvre automatiquement pour que vous puissiez ouvrir le projet si vous le souhaitez.

Flux de travail standard

Au fur et à mesure que vous travaillez sur votre projet, vous créez naturellement des sprites, éditez des scripts, supprimez des lignes de temps et tout ce qui est nécessaire au fur et à mesure que votre projet se développe avec le temps. Ce sont toutes des actions que vous voudrez peut-être suivre et revenir en cas de problème. C'est la raison principale pour utiliser le contrôle de la source - de sorte que les accidents peuvent être annulés - et nous allons rapidement vous guider à travers le flux de travail de base dès le début afin que vous compreniez comment cela fonctionne.

Depuis le début, créez un nouveau projet GML, puis activez le contrôle de la source via les options principales. Cela nous donne accès au menu Contrôle de la source en haut, donc nous allons immédiatement créer un référentiel de projet. Si vous regardez les ressources de la pièce, vous pouvez voir que la pièce par défaut a gagné une exclamation rouge , ce qui signifie qu'il a été modifié à partir de son dernier état. Si nous avions d'autres ressources dans le projet, vous verriez qu'ils ont tous la même icône que celle montrée dans l'image ci-dessous:

Nous avons maintenant la possibilité soit de valider le projet vide tel quel, soit de l'amener à un état de base. Pour l'instant, nous allons faire notre première validation, donc cliquez sur Contrôle de la source > Commit Changes. Ce sera Nous allons maintenant obtenir une fenêtre divisée en trois zones:

• Changements par étapes - Ceci représente les changements qui seront affectés à la source. Ce sera probablement vide, mais il peut montrer un changement des options principales, ce qui est bien.
  
  
• Changements non planifiés - Cela montre les fichiers qui ont changé, mais que nous n'avons pas dit à Git que nous voulons les valider - ils sont en attente de changements.
  
  
• Message de validation - Il s'agit d'une note que nous pouvons ajouter pour expliquer les changements.

Pour l'instant, cliquez sur le bouton Tout afficher, car nous voulons valider tous les changements, et tapez quelque chose comme "Première validation!" dans le message Valider et cliquez sur Valider. Toutes nos ressources devraient maintenant avoir une coche verte , ce qui signifie qu'il n'y a pas de modifications trouvées.

Notre processus de travail peut maintenant commencer, et nous pouvons commencer à construire notre projet et enregistrer et valider les changements, comme nous l'avons fait dans les paragraphes ci-dessus.

Après avoir travaillé pendant un certain temps, vous voudrez peut-être vérifier et voir ce que vous avez commis à un moment donné, et pour cela, vous voudrez ouvrir l' historique de validation. Pour ouvrir la fenêtre d'historique, allez simplement dans Contrôle de la source > Afficher l'historique, qui ouvre une autre fenêtre avec trois volets:

Le volet supérieur décrit les validations, le volet central décrit le commentaire donné à la validation sélectionnée et le volet inférieur décrit les fichiers qui ont été modifiés dans cette validation. Notez que si vous avez configuré un outil Diff, un double-clic sur n'importe quel fichier de cette fenêtre ouvrira l'outil de comparaison et vous pourrez voir les changements entre les fichiers.

Rétablir les fichiers

Ci-dessus, vous avez vu comment créer un référentiel et y apporter des modifications, mais que se passe-t-il si vous faites une erreur et que vous voulez "revenir" à un commit précédent? Faisons une erreur délibérée et voyons comment nous pouvons y faire face alors...

Tout d'abord, créez une nouvelle ressource - dans cet exemple, nous allons créer une ressource de script - et vous ne verrez pas d'icône de statut au début car, pour ce qui est du contrôle de la source, il n'existe pas encore. Dans la ressource de script, ajoutez une simple ligne de code, comme:

show_debug_message("Hello World");

Si vous fermez maintenant l'éditeur de code, le script va enregistrer et l'icône du fichier modifié apparaîtra à côté dans l'arbre des ressources. Maintenant, ouvrez la fenêtre Commit et vous verrez qu'il y a quatre changements par étapes, car de nouvelles ressources sont automatiquement ajoutées:

Les changements mis en scène seront:

• le fichier de projet.yyp
• un fichier de vue
• le script GML lui-même
• le fichier.yy le référençant

Vous devez taper un message de validation, puis cliquez sur le bouton Valider, comme expliqué précédemment. Maintenant, nous revenons à notre script et changeons la ligne de code en (par exemple):

show_debug_message("Hello World, how are you?");

Quand nous fermons l'éditeur de code, une icône rouge apparaît à côté du script, mais nous avons réalisé que nous avions fait une erreur avec notre code et que nous voulions revenir à une version précédente pour la réparer (évidemment, vous pourriez juste ouvrez le script et corrigez-le facilement, car l'exemple est si simple, mais dans les grands projets, ce n'est normalement pas une approche réalisable). Ce que nous devons faire, c'est inverser nos changements.

Pour annuler une modification, nous devons d'abord ouvrir à nouveau la fenêtre de validation. Nous passons donc à Contrôle de la source > Valider les modifications une fois de plus. Notre fichier modifié sera à nouveau prêt à être validé, mais ce n'est pas ce que nous voulons, donc nous cliquons sur le bouton Tout désinstaller pour le sortir de la zone de transit.

Si maintenant nous faisons un clic droit sur le fichier que nous avons modifié, nous aurons un menu contextuel avec une option pour Rétablir le chemin:

Lorsque vous sélectionnez cette option, vous rétablissez les fichiers à l'état précédent dans lequel ils se trouvaient.

IMPORTANT! Lorsque vous rétablissez, un message vous demande de recharger ou d'enregistrer le projet en cours en raison de la détection des modifications sur le disque par le vérificateur de fichiers: Vous devez cliquer sur Recharger et ne pas enregistrer, car la sauvegarde économisera ce qui est de la mémoire plutôt que de recharger les fichiers restaurés.

C'est très bien quand vous éditez quelque chose et que vous voulez revenir en arrière sans avoir déjà effectué un commit, mais qu'en est-il lorsque vous avez effectué un ou plusieurs changements et que vous voulez revenir à un commit précédent? Eh bien, modifions à nouveau notre script pour dire:

show_debug_message("This is a bad idea");

Maintenant, nous l'engageons comme auparavant pour l'obtenir sous le contrôle de la source. Donc, c'était une mauvaise idée et nous voulons revenir en arrière, ce qui signifie que pour commencer, nous devons à nouveau ouvrir la fenêtre Contrôle de la source > Voir l'historique. Nous allons voir une liste de toutes les validations précédentes dans cette fenêtre, en commençant par la validation initiale, la validation du script, puis la validation du script que nous avons édité comme une "mauvaise idée":

Nous avons maintenant deux choix. Nous pouvons inverser une révision entière - qui va restaurer tous les fichiers qui ont été changés à ceux du commit choisi - ou nous pouvons choisir de rétablir un chemin - qui va simplement retourner un seul fichier. Faisons la première option pour commencer:

• Clic-droit notre deuxième commit dans le panneau Commit History (le commit "Hello World").
  
  
• Sélectionnez Revenir à cette révision, puis choisissez Recharger dans le message d'avertissement.
  
  

Vous devriez voir que le script a maintenant une icône de statut rouge et si nous l'ouvrons, nous aurons ce qui suit:

Nous pouvons ensuite faire un engagement sur le projet et nous serons de retour à l'endroit où nous étions encore une fois. Cependant, nous pouvons également annuler cette action pour le fichier et récupérer notre "mauvaise idée" en procédant comme suit:

• Ouvrez la fenêtre Commit Changes.
  
  
• Désinstallez le script avec le code "Hello World".
  
  
• Clic-droit et retournez le chemin.

Maintenant, nous sommes de retour à avoir le fichier erroné dans le projet à nouveau! Eh bien, nous pouvons profiter de cette opportunité pour ne restaurer que ce chemin de fichier au lieu de tout mettre à jour dans une révision précédente. Pour cela, nous devons faire ce qui suit:

• Ouvrez la fenêtre Afficher l'historique.
  
  
• Cliquez sur le second commit (le commit "Hello World").
  
  
• Clic-droit sur notre script GML dans le volet Fichiers et sélectionnez Rétablir le chemin.

Nous devrions revenir à notre code "Hello World" et nous pouvons alors faire un nouvel engagement pour mettre à jour le contrôle source avec le fichier corrigé.

Clonage d'un référentiel

Lorsque votre projet est stocké dans un référentiel externe, vous devez vous souvenir de pousser vos modifications et d'en extraire de nouvelles. La raison en est que lorsque vous validez, vous stockez vos modifications localement, ce qui vous permet de travailler loin d'une connexion Internet et de vous synchroniser lorsque vous êtes prêt, et de synchroniser vos modifications vers le référentiel distant. Tirer des modifications signifie que vous voulez tirer toutes les modifications que d'autres ont apportées depuis le dépôt distant dans votre dépôt local. Cependant, cela signifie qu'il peut arriver que des personnes modifient les mêmes fichiers, ce qui crée un conflit de fusion. Vous devez savoir comment gérer ces conflits, nous allons donc en créer délibérément un maintenant et vous montrer comment y faire face.

REMARQUE: Le partage d'un référentiel de projet local (même via un service de synchronisation de fichiers tel que Dropbox) n'est pas recommandé car les validations y sont généralement écrites directement, ce qui réduit considérablement la protection contre les conflits.

Pour générer notre conflit, nous devons d'abord avoir deux référentiels locaux, un pour le référentiel maître et un pour notre copie. Pour créer cela, nous devons cloner le dépôt, ce qui est fait avec les étapes suivantes:

• Accédez à Contrôle de la source > Référentiel de clonage.
  
  
• Dans le champ URL, tapez le chemin d'accès au projet que nous avons configuré dans le guide Rétablir les fichiers ci-dessus (par défaut, cela sera D:\Users\<Username>\Documents\GameMakerStudio2\<ProjectName> ).
• Vous devez ensuite définir un chemin à cloner vers: Lorsque vous cliquez sur le bouton "OK", vous obtenez l'avertissement suivant concernant la tentative de clonage d'un référentiel "non-vide": Vous pouvez cliquer sur "OK" ici encore.
  
  
• Vous allez maintenant voir un explorateur de répertoires pour créer un référentiel de proxy "nu" (c'est un référentiel que vous pouvez stocker en toute sécurité sur Dropbox, par exemple). Accédez à l'emplacement où vous souhaitez créer ce référentiel proxy et sélectionnez (ou créez) le dossier à utiliser.

Une fois cette opération effectuée, GameMaker Studio 2 votre projet original au proxy et en place un nouveau dans le chemin défini dans la fenêtre Référentiel de clonage, puis ouvre automatiquement un explorateur de fichiers pour que vous puissiez ouvrir le projet stocké. Si vous allez maintenant à Contrôle de la source > Afficher l'historique, nous verrons nos commits d'origine plus un nouveau "Push For Clone":

Vous avez maintenant cloné votre référentiel et pouvez continuer à travailler sur la version locale du projet.

Conflits

Dans cette section, nous allons examiner la résolution des conflits entre un référentiel local cloné et un référentiel maître (voir la section sur le clonage pour plus de détails). En supposant que vous utilisez maintenant un référentiel local, nous aurons besoin d'éditer un fichier, puis de provoquer un conflit, alors ouvrez le script de test que nous avons utilisé et changez le message "Hello World" en quelque chose comme ceci:

show_debug_message("Hello World, How Are You?");

Vous devez maintenant enregistrer le projet et le valider dans le référentiel local. Maintenant, étant donné que nous sommes liés à un référentiel maître distant (même s'il s'agit d'un référentiel que nous avons cloné sur le même disque), nous devons effectuer un Push pour que les modifications soient appliquées au master. Pour cela, allez dans Contrôle de la source > Pousser les modifications, ce qui nous donnera une mise à jour de l'état dans l' onglet Sortie du contrôle de la source:

Nous devons maintenant ouvrir notre projet d' origine (pas le cloné), alors naviguez jusqu'à l'endroit où vous l'avez sauvegardé sur le disque - ou vérifiez simplement les projets récents dans le menu Fichier, comme il se doit directement sous le fichier actuel - et chargez-le dans GameMaker Studio 2. Un moyen facile de vérifier que vous avez le bon projet est de simplement vérifier le script que vous avez et si le message est "Hello World" alors vous avez le bon, ou vous pouvez ouvrir la fenêtre Voir l'historique et vérifier de cette façon.

Vous devez maintenant modifier à nouveau le script, alors faites-le lire quelque chose comme ceci:

show_debug_message("This will cause a conflict.");

Cela peut être sauvegardé sur le disque, et les modifications peuvent être validées, mais si vous essayez d'appuyer sur ces modifications, vous obtiendrez le message suivant:

Quelqu'un a déjà poussé des changements que vous n'avez pas encore! Cela signifie que vous devez effectuer une extraction sur le référentiel et voir quel est exactement le problème, alors allez dans Contrôle de la source > Tirer les modifications. Cela montrera deux fenêtres, la première est un avertissement sur les fichiers modifiés (comme avec les actions précédentes, vous voulez choisir Recharger ici et non Sauvegarder), et l'autre est la fenêtre Conflits:

Cette fenêtre affiche les fichiers en conflit dans une liste à gauche, et vous pouvez sélectionner les fichiers de cette liste en utilisant le bouton gauche de la souris (ou sélectionnez plusieurs fichiers en utilisant + ). Vous avez quatre options pour traiter les fichiers en conflit, disponibles à partir des boutons sur la droite:

• Utilisez-les - Cela remplacera les changements que vous avez faits avec celui du dépôt distant.
  
  
• Utiliser le mien - Cela annulera les changements du dépôt distant avec ceux que vous venez de faire.
  
  
• Fusionner - Cela va tenter d'ouvrir un outil de fusion externe pour gérer le conflit.
  
  
• Choisir l'outil de fusion - Cela vous permettra de configurer l'outil de fusion (voir la section sur l'utilisation d'un outil de fusion externe ci-dessous pour plus de détails).

Maintenant, vous pouvez utiliser les boutons pour trier le conflit, mais avant cela, ouvrons simplement le fichier en conflit pour voir exactement quel est le problème. Si vous ouvrez le script en conflit, il ressemblera à ceci:

Cela montre que "Cela causera un conflit" est sur le HEAD (c'est ce que nous avons poussé vers le dépôt local) et que "Hello World, Comment allez-vous?" est tiré du maître, le dépôt distant. Vous pouvez maintenant revenir à la fenêtre Conflits et cliquer sur Utiliser les pour récupérer le fichier modifié et écraser le fichier HEAD actuel. Le script sera maintenant marqué comme modifié et vous devriez faire un nouveau commit et pousser avant de continuer.

Notez que nous pourrions réellement corriger cela dans l' GameMaker Studio 2. Si nous supprimons les lignes 1, 2, 3 et 5, nous restons avec juste show_debug_message(“Hello World, How Are You?”) et enregistrez-le, cela effacera le conflit, car Git supposera que vous savez ce que vous faites avec votre propre fichier. Il est sujet aux erreurs, il est donc recommandé d'installer un outil de fusion, puis de le configurer et de l'utiliser au lieu d'essayer manuellement de fusionner.

Configuration d'outils de fusion / diffusion externes

Lorsque vous travaillez sur un projet avec d'autres personnes, il y a toujours un risque de conflit, car plusieurs personnes modifient le même fichier et la plupart des systèmes de contrôle source peuvent tenter de fusionner les fichiers en conflit, mais lorsque des modifications sont apportées au même endroit, il faut un peu d'aide pour savoir quoi faire - c'est là qu'un outil de fusion intervient pour vous montrer les changements, et vous laisse décider.

Comme chaque outil de fusion est différent, quatre macros peuvent être utilisées pour vous aider à spécifier des fichiers qui peuvent être configurés à partir de la fenêtre Conflits en cliquant sur le bouton nommé Choisir un outil de fusion:

Lorsque vous cliquez sur ce bouton, la fenêtre Préférences s'ouvre sur le plugin Git:

Vous fournissez ici un chemin d'accès à l'outil de fusion choisi, puis une macro Options de l'outil de fusion (ou macros) à utiliser pour décider quoi faire, avec les options suivantes disponibles:

• ${scm_mine}: chemin vers votre version
  
  
• ${scm_thers}: chemin vers leur version
  
  
• ${scm_base}: chemin d'accès à la version avant que les modifications en conflit se produisent
  
  
• ${scm_merged}: chemin d'accès à l'emplacement où l'outil de fusion doit être enregistré
  

Pour aider à la configuration, lorsque vous donnez un chemin à certains outils de fusion, GameMaker Studio 2 remplira certains paramètres par défaut, en fonction de l'outil choisi:

• KDiff3: ${scm_theirs} ${scm_mine} -o ${scm_merged}
  
  
• Meld: ${scm_mine} ${scm_merged} ${scm_theirs}
  
  
• Notepadd ++: ${scm_merged}
  
  
• TortoiseMerge: /base:${scm_base} /theirs:${scm_theirs} /mine:${scm_mine} /merged:${scm_merged}
  

Notez que si vous n'avez pas (ou ne voulez pas utiliser) un outil de fusion, vous pouvez ouvrir le script dans l'EDI et essayer de le réparer à partir de là.

Donc, revenons à notre exemple de Conflit comme indiqué dans la section ci-dessus sur les Conflits... Vous avez fait un pull de master et l'un des fichiers est en conflit. Cela ouvre la fenêtre Conflits de contrôle de la source, où vous pouvez cliquer sur le script en conflit, et maintenant cliquez sur Fusionner, puisque vous avez configuré votre outil de fusion. En cliquant sur fusionner, vous ouvrez l'outil dans lequel vous pouvez gérer le conflit, puis utiliser la ou les macro (s) fournie (s) pour apporter les modifications requises. Une fois l'outil de fusion terminé et fermé, l'IDE de GameMaker Studio 2 affiche la fenêtre de confirmation suivante:

Répondez simplement "Oui" à cette invite comme vous venez de le faire vous-même en utilisant l'outil de fusion, puis vous devez valider cette modification pour indiquer la fin de l'opération de fusion ( Contrôle de la source > Commit Changes. qu'une fusion est en cours ainsi que des fichiers non stockés:

Ces fichiers non stockés sont notre fichier de script avec l'ajout de .base, .ours et .theirs. Nous pouvons supprimer tout cela en toute sécurité, donc cliquez sur le dessus, puis + sur le fond pour les sélectionner tous. Ensuite, faites un clic droit sur les fichiers sélectionnés et choisissez Supprimer le chemin pour les supprimer. Il y a aussi un message de validation pré-rempli pour vous, indiquant qu'il s'agissait d'une fusion, et qu'il y avait un conflit (vous pouvez ajouter ou éditer comme vous le souhaitez).

Vous pouvez cliquer sur Valider maintenant.

En raison du fait que vous pouvez rencontrer des problèmes avec les fichiers sortants, cela signifie que votre flux de travail lors de l'utilisation de référentiels distants ou partagés doit être le suivant:

Make Changes > Save > Commit > Pull > Merge > Push

Vous devez également configurer un outil Diff pour l'utiliser lors d'un commit dans un référentiel. Ceci est configuré à partir des Préférences, comme pour l'outil Fusionner:

L'outil Diff est configuré de la même manière que l'outil Fusionner, mais utilise uniquement ${scm_base} et ${scm_theirs} options - dans ce cas, ${scm_base} représente le fichier non modifié alors ${scm_theirs} représente l'état actuel du fichier. Les options d'outils doivent être préremplies avec les options par défaut pour Meld, KDiff3 et TortoiseMerge, comme elles l'étaient pour l'outil Fusionner. Notez que GameMaker Studio 2 ne prend pas en charge la sortie de patchs de fichiers uniques, par conséquent il n'y a pas de valeur par défaut pour le Bloc-notes.

Pour afficher les modifications entre les révisions actuelles et précédentes à l'aide de l'outil Diff, ouvrez simplement la fenêtre Valider, puis double-cliquez sur un fichier. Si l'outil a été configuré correctement, il sera lancé et vous pourrez voir les changements entre les fichiers.

Menu contextuel du contrôle de source

Lorsque vous avez activé le contrôle de source pour n'importe quel projet (voir la section Configuration du plugin Git de contrôle de source ci-dessus pour plus de détails), GameMaker Studio 2 affichera le menu contextuel suivant en haut:

Nous décrivons ici chacune des options disponibles (la plupart d'entre elles sont expliquées plus en détail dans les sections du tutoriel ci-dessus):

• Créer un référentiel de projet: cette option vous permet de créer un référentiel local dans le même répertoire que vos fichiers de projet.
  
  
• Importer un projet dans le référentiel: cette option vous permet d'importer un projet dans un référentiel externe.
  
  
• Cloner le référentiel: Cette option vous permettra de cloner un dépôt depuis une source vers une nouvelle destination.
  
  
• Commit Changes: Avec cette option, vous pouvez mettre en scène les fichiers modifiés dans votre projet, puis les valider dans le référentiel.
  
  
• Push Changes: Après avoir effectué une validation ou une fusion, cette option est utilisée pour transférer les modifications dans le référentiel maître.
  
  
• Pull Changes: Avec cette option, vous pouvez mettre à jour le référentiel local en extrayant les fichiers modifiés du référentiel maître.
  
  
• Voir l'historique: Ceci ouvrira la fenêtre de l'historique où vous pourrez voir tout l'historique des versions du projet et choisir de restaurer des chemins de fichiers spécifiques ou des révisions entières.
  
  
• Afficher les conflits: cela ouvre la fenêtre Conflits et répertorie tous les fichiers en conflit pouvant exister dans le projet, ce qui vous permet de les traiter via l' GameMaker Studio 2 ou en utilisant un outil de fusion spécifique.