Share
Cet article se veut un guide définitif sur la manière de contrôler correctement les versions de vos projets Unity.!
Le contrôle de version est l’un des outils les plus importants de l’arsenal des développeurs. Il vous permet d’annuler facilement les modifications si vous cassez accidentellement quelque chose, de comparer les versions les plus anciennes et les plus récentes de votre code pour voir ce qui est différent, et permet aux équipes de travailler sur le même code sans écraser par inadvertance le travail des autres. Jusqu'à récemment, seuls les projets Unity Pro pouvaient être correctement contrôlés par la version. Cependant, depuis Unity 3.5, il est désormais possible de contrôler les versions dans la version gratuite de Unity..
Un système de contrôle de version, ou VCS, assure le suivi des modifications apportées aux fichiers dans un dossier, également appelé "copie de travail". Ces modifications sont stockées à côté du dossier dans une base de données appelée "référentiel". Chaque fois que vous modifiez quelque chose dans votre copie de travail, vous devez enregistrer ces modifications dans le référentiel. Le VCS compare ensuite ce qui est déjà dans le référentiel aux modifications entrantes et ne stocke que les différences. Ceci garde le dépôt aussi petit que possible.
Pour ce projet, nous utiliserons Mercurial, un VCS distribué. Contrairement aux systèmes VCS centralisés tels que Subversion (SVN), qui reposent généralement sur un référentiel distant stocké sur un serveur, un VCS distribué peut héberger des référentiels locaux, parfois appelés "branches locales", directement sur votre ordinateur. Cela signifie que vous pouvez apporter des modifications, les engager dans votre branche locale, les tester et même les ignorer en cas de problème, sans devoir soumettre les membres de votre équipe à vos modifications jusqu'à ce que vous sachiez qu'elles sont parfaites. Une fois que vous en êtes sûr, vous pouvez "transférer" ces modifications dans un référentiel distant afin que votre équipe puisse "accéder" à leurs propres branches locales..
Un projet Unity nécessite certaines méta-informations pour mémoriser les composants et les connexions définis sur les différents actifs. Traditionnellement, ces méta-informations étaient stockées sous la forme d'un ensemble de fichiers binaires dans le dossier Bibliothèque d'un projet Unity. Toutefois, ce "blob binaire" ne peut pas être fusionné correctement. Par conséquent, les modifications apportées par deux personnes risquent de se superposer, ce qui entraînerait des dysfonctionnements dans l'éditeur, même s'ils éditaient des actifs différents..
La solution consiste à activer les fichiers méta dans les paramètres du projet..
Ainsi, Unity créera des méta-fichiers à côté de chaque actif dans le dossier Assets du projet. Désormais, lorsqu'un actif est modifié dans l'éditeur, seul l'actif et son méta-fichier associé rapporteront les modifications, au lieu du dossier entier de la bibliothèque..
Windows et OSX ont tous deux des programmes d’installation Mercurial. Visitez le site Web Mercurial et cliquez sur le gros bouton de téléchargement. Le site reconnaîtra automatiquement le système d'exploitation que vous utilisez et téléchargera le programme d'installation approprié..
Décompressez le programme d'installation et exécutez-le. Cliquez à travers toutes les étapes et il devrait s'installer sans aucune intervention nécessaire.
Pour vous assurer que Mercurial est correctement installé, ouvrez une ligne de commande. Sous Windows, appuyez sur Début et le type cmd dans la boîte de recherche. Sur OSX, ouvrez Projecteur et rechercher Terminal.
Sur la ligne de commande, entrez:
hg .
Une courte liste d’informations devrait apparaître, y compris la version de Mercurial que vous utilisez, ainsi qu’une liste des commandes courantes. Pour obtenir la liste complète des commandes, entrez:
hg aide
Et pour obtenir de l'aide sur une commande spécifique, entrez simplement le nom de la commande après aide:
hg aide cloner
REMARQUE: Les commandes mercurielles commencent toujours par hg, l'élément pour le mercure sur le tableau périodique. Heureusement, ce nom malin a été utilisé car il est facile de taper.
La première chose à faire est de donner à notre dossier de projet un référentiel..
Sur la ligne de commande, entrez:
hg init
C'est tout. Notre dossier a maintenant un référentiel et est prêt pour le contrôle de version. Si vous avez activé les fichiers cachés, vous remarquerez un .hg Le dossier a été créé dans le dossier du projet. C'est là que réside le référentiel. Si, pour une raison quelconque, vous souhaitez supprimer le contrôle de version, supprimez simplement le .hg dossier. Votre copie de travail des fichiers ne sera pas endommagée.
Maintenant que notre dossier de projet a un référentiel, vérifions son statut pour voir ce qui a changé. Mercurial acceptera les noms de commande abrégés. Par conséquent, l'un des éléments suivants fonctionnera:
hg statut hg stat hg st
Un rapport d’état doit fournir une liste de fichiers, chacun avec une lettre à côté. Dans ce cas, tous les fichiers auront des points d'interrogation à côté. Le point d'interrogation indique que le fichier n'est pas encore sous contrôle de version dans le référentiel.
| ? | Un fichier qui est dans la copie de travail mais qui n'est pas suivi par le référentiel. |
| ! | Un fichier suivi par le référentiel mais manquant dans la copie de travail. |
| UNE | Un fichier qui a été ajouté au référentiel depuis le dernier commit. |
| M | Un fichier qui a été modifié depuis le dernier commit. |
| R | Un fichier qui doit être supprimé du référentiel lors du prochain commit. |
Nous devons explicitement ajouter des fichiers à notre référentiel afin de faire savoir à Mercurial que nous voulons qu'ils soient contrôlés par la version..
Des fichiers individuels peuvent être ajoutés:
hg add myfile.txt
Des dossiers entiers peuvent être ajoutés:
hg ajouter des scripts /
Ajoutons chaque fichier sans version (avec un ? point d’interrogation dans le rapport d’état) en un seul coup en ne spécifiant aucun nom de fichier:
hg ajouter
Effectuer une vérification de statut.
statut hg
Tous les fichiers ajoutés doivent maintenant avoir une lettre UNE à côté d'eux, indiquant qu'ils ont été ajoutés au référentiel et que Mercurial en assure le suivi.
Maintenant que nous avons indiqué à Mercurial quels fichiers nous souhaitons contrôler par la version, nous devons les valider dans le référentiel. Chaque commit est comme un instantané appelé révision, qui garde la trace des différences entre les révisions précédentes et la révision actuelle..
Chaque commit est composé de deux parties: un message et votre nom d'utilisateur. Le message est l'endroit où vous décrivez ce que vous avez fait, mais soyez bref et gentil. Le nom d'utilisateur est simplement un identifiant permettant d'informer toute autre personne susceptible d'utiliser le référentiel qui a effectué certaines modifications. Le nom d'utilisateur est défini avec le -vous drapeau et le message est défini avec le -m drapeau:
hg commit -u ian -m "initial"
Pour vous assurer que la validation a réussi, nous devons vérifier le journal:
journal hg
Pour être tout à fait sûr, vérifiez le statut pour vous assurer qu'il ne reste plus de modifications..
statut hg
Un rapport d'état vide signifie que tout a été correctement commis.
REMARQUE: Il est recommandé de vous engager souvent. Chaque commit devrait être aussi "atomique" que possible. C'est-à-dire qu'il devrait être facilement décrit par une phrase simple comme "augmentation de la hauteur de saut du joueur". Si vous avez besoin d'utiliser "et" ou des virgules dans vos messages de validation, il est probablement temps de procéder à deux validations distinctes. La raison en est de faciliter l’annulation des modifications spécifiques que vous avez apportées lorsque vous rencontrez des problèmes..
Il existe deux méthodes principales pour corriger les erreurs: une restauration ou une restauration. Une annulation annulera la dernière commande que vous avez entrée, ce qui est idéal pour corriger les fautes d'orthographe dans vos messages de commit ou pour ajouter des ajouts trop zélés..
retour en arrière
Effectuer une vérification de l'état pour s'assurer que tout a été annulé correctement.
statut hg
Un retour est plus puissant, vous permettant de remonter dans le temps grâce à plusieurs révisions, au cas où vous auriez à annuler plusieurs modifications que vous avez apportées. Pour savoir quelle révision vous souhaitez revenir, vous devez d'abord consulter le journal:
journal hg
Le numéro ou le hachage peut être utilisé pour faire référence à une révision spécifique lors de la restauration. Le numéro est spécifique à votre référentiel, car la branche de quelqu'un d'autre pourrait avoir plus de modifications, donc leur nombre serait différent. Le hachage est universel, cela signifie que n'importe qui peut revenir à une révision spécifique sur un référentiel partagé en utilisant cette chaîne de hachage..
Pour revenir à une révision spécifique, nous devons spécifier le numéro de révision à l'aide de la touche -r drapeau. Nous devons également dire à Mercurial de "rétablir tout" en utilisant le -une drapeau. Enfin, nous devons dire à Mercurial que nous ne voulons pas créer de fichiers de sauvegarde à l’aide du --pas de sauvegarde drapeau.
hg retourne -r 0 -a --no-backup
Effectuer une vérification de l'état pour s'assurer que tout est retourné correctement.
statut hg
REMARQUE: Si vous omettez le --pas de sauvegarde Mercurial créera des fichiers de sauvegarde pour tous les fichiers concernés par la procédure de restauration. Ces fichiers de sauvegarde auront tous une .orig extension. Assurez-vous de ne pas ajouter .orig des dossiers.
Maintenant que nous avons corrigé notre erreur, faisons en sorte que cela ne se reproduise plus. Nous voulons ignorer de manière permanente les dossiers Library et Temp afin qu’ils ne puissent pas être ajoutés accidentellement la prochaine fois que nous serons heureux avec la commande add..
Mercurial utilise un fichier spécial appelé .hgignore pour stocker les noms des fichiers et des dossiers que vous souhaitez ignorer de manière permanente. Ce fichier se trouve directement dans votre dossier de projet et sa version est contrôlée comme tout le reste. Cela garantit que tous ceux qui utilisent le référentiel ne pourront pas le polluer accidentellement avec des fichiers indésirables.
Utilisez votre éditeur de texte favori pour entrer les informations suivantes:
syntaxe: glob Bibliothèque Temp * .pidb * .sln * .userprefs * .csprog * .orig
Cela indique à Mercurial ce que nous voulons utiliser comme syntaxe de style shell (connue sous le nom de "glob") pour ignorer les dossiers Library et Temp, ignorer plusieurs fichiers temporaires créés par MonoDevelop et ignorer les dossiers. .orig fichiers juste au cas où nous les créons accidentellement lors de la restauration.
Enregistrez le fichier à la racine du dossier de votre projet sous .Hignor (notant le point au début). Puis effectuez une autre vérification de statut:
statut hg
le .Hignor Le fichier doit maintenant figurer dans le rapport d'état, mais pas le dossier Bibliothèque, le dossier Temp ni les autres fichiers ignorés. Ainsi, nous pouvons utiliser la commande add en toute sécurité sans avoir à utiliser des noms de fichiers exacts, puis valider les résultats..
hg ajouter hg commettre -u ian -m "Initial"
Consultez le journal pour vous assurer que la validation a réussi.
journal hg
REMARQUE: Vous trouverez plus d'informations sur les fichiers hgignore ici.
Si vous souhaitez partager votre référentiel avec d'autres développeurs, le moyen le plus simple consiste à créer un référentiel distant sur un serveur et à y appliquer vos modifications..
La première chose à faire est de trouver un hôte Mercurial. Plusieurs existent, y compris BitBucket et Kiln; Les deux ont des comptes gratuits pour les petites équipes. Dans notre cas, nous utiliserons BitBucket, mais les deux services fonctionnent essentiellement de la même manière. Une fois que vous avez ouvert un compte sur l'un des services, veillez à créer un nouveau référentiel à l'aide de leur interface Web..
Une fois créé, recherchez le "chemin de clonage". Ça devrait ressembler a quelque chose comme ca:
hg clone https://bitbucket.org/username/reponame
Normalement, cette commande serait utilisée pour créer une copie locale du référentiel. Mais nous avons déjà un référentiel local et nous voulons plutôt envoyer les modifications de celui-ci au référentiel distant. Pour ce faire, nous pouvons prendre l'adresse URL à la fin de la chaîne de clonage et l'utiliser comme destination pour la commande push.
hg push https://bitbucket.org/username/reponame
Mercurial comparera le référentiel local au référentiel distant pour voir en quoi ils diffèrent. Il verra que notre référentiel local a des modifications plus récentes que le référentiel distant est manquant et les enverra au référentiel distant.
Cependant, il demandera d'abord un nom d'utilisateur et un mot de passe. Ceux-ci doivent correspondre au nom d'utilisateur / email et au mot de passe que vous avez inscrits au service hôte avec.
Mercurial doit signaler que toutes les modifications ont été appliquées avec succès, ce qui signifie que toute personne dépendant de votre référentiel peut désormais "en extraire" pour recevoir vos modifications. Tout d'abord, ils devront cloner le référentiel pour en faire une copie locale.
hg clone https://bitbucket.org/username/reponame
Et puis retirez tous les changements que vous ou toute autre personne apportez au fil du temps:
hg pull
Vous devrez ensuite faire une "mise à jour" pour vous assurer que votre copie de travail est mise à jour:
hg mise à jour
Mais pour gagner du temps, vous pouvez tirer et mettre à jour tout à la fois en utilisant le -vous drapeau:
hg pull -u
REMARQUE: Mercurial vous le demandera chaque fois qu'un fichier binaire est mis à jour ou fusionné. Sauf si vous êtes certain d’avoir apporté des modifications aux fichiers binaires locaux, choisissez toujours la "(O) autre" option au lieu de "(Local" option.
Il y a plusieurs aspects fastidieux à exécuter sans cesse les mêmes commandes, tels que devoir se rappeler de fournir un nom d'utilisateur lors de la validation, devoir saisir un mot de passe chaque fois que vous appuyez, etc. Nombre de ces paramètres peuvent être stockés dans ce que un hgrc fichier. Pour créer un hgrc fichier, utilisez votre éditeur de texte favori et entrez les informations suivantes:
[chemins] default = https://bitbucket.org/username/reponame
Cela indique à Mercurial quel chemin utiliser par défaut pour les commandes push et pull. Assurez-vous de remplacer cette adresse fictive par l'adresse réelle de votre référentiel distant. Ensuite, entrez les informations suivantes:
[ui] nomutilisateur = Prénom Nom
Cela indique à Mercurial le nom d'utilisateur à utiliser par défaut lors de la validation. Encore une fois, remplacez-le par vos références correctes et assurez-vous que l'adresse électronique correspond à celle avec laquelle vous vous êtes inscrit. Enfin, entrez:
[auth] host.prefix = bitbucket.org host.username = nom d'utilisateur host.password = mot de passe host.schemes = http https
Cela indique à Mercurial les informations d'identification à utiliser lors de l'insertion dans un référentiel distant sécurisé afin que vous n'ayez pas à saisir un nom d'utilisateur et un mot de passe à chaque poussée ou extraction. Assurez-vous de remplacer le préfixe par la partie la plus courte possible de l'adresse de votre hôte et n'incluez pas le http: // protocole dans le préfixe soit. Ensuite, remplacez le nom d'utilisateur et le mot de passe par ceux que vous avez inscrits sur votre hôte. Le schéma indique à Mercurial avec quels protocoles essayer de se connecter.
Enfin, enregistrez le fichier sous hgrc (sans point ni extension à la fin) à l'intérieur la .hg dossier dans votre référentiel. Vous ne devriez plus avoir besoin de donner manuellement des noms d'utilisateur, des mots de passe ou des chemins lorsque vous lancez des commandes.
Le contrôle des versions peut sembler un peu intimidant aux non-initiés, mais l'effort en vaut la peine. Cela vous rassure de savoir qu'à tout moment vous pouvez ramener un projet cassé à un point où il fonctionnait auparavant. De même, l'utilisation de référentiels distants signifie que le code peut non seulement être partagé avec les membres de l'équipe, mais qu'il est facile de récupérer votre projet après une catastrophe (comme une panne de disque dur)..
Pour en savoir plus sur le contrôle de version distribué et Mercurial, je vous recommande vivement de vous rendre sur Hg Init. Il contient une série d'articles expliquant en détail les pratiques de contrôle de version et les fonctionnalités de Mercurial. C'est bref, très instructif, facile à lire, facile à comprendre et même un peu drôle.
Accentsconagua