Meilleures pratiques pour le contrôle des versions

C'est de loin l'amélioration la plus simple que vous puissiez apporter à votre flux de travail, mais c'est celle qui pose le plus de problèmes à certains développeurs. Lorsque vous utilisez d'autres outils de gestion de projet, il est probable que vous ayez déjà divisé le travail en petites tâches faciles à gérer. Les engagements devraient être traités de la même manière.

Un seul commit ne devrait concerner qu'une seule tâche ou ticket, à moins qu'une seule ligne de code ne corrige par magie plusieurs bogues. Si vous travaillez sur une fonctionnalité importante, décomposez-la en tâches plus petites et faites des commits pour chacune d'entre elles.

Le plus grand avantage de l'utilisation de commits plus petits est que, si quelque chose ne va pas, vous pouvez détecter et annuler les changements indésirables beaucoup plus facilement.

Les messages d'engagement décrivent l'historique de votre projet. Après tout, il est beaucoup plus facile de trouver la modification qui a ajouté des tables de score élevé à votre jeu si le message de validation indique "ajout de tables de score élevé au menu" plutôt que "je parie que vous ne pouvez pas battre mon score avec ces nouvelles tables !

Si vous travaillez avec un système de tickets de tâches comme Jira ou GitLab, il est encore mieux d'inclure un numéro de ticket dans votre livraison. De nombreux systèmes peuvent être configurés pour fonctionner avec des commits intelligents, de sorte que vous puissiez référencer des tickets et modifier leur statut à partir de votre message de commit.

Par exemple, un commit qui dit "JRA-123 #close #comment task completed" mettrait le ticket Jira JRA-123 à fermé, laissant le commentaire "task completed" sur le ticket.

Pour plus d'informations sur la configuration de ce flux de travail, consultez la documentation dans Jira ou le service Pivotal Tracker dans GitLab.

La seule fois où "commit -a" (la commande Git pour "commettre tous les changements") ou l'un de ses équivalents doit être utilisé, c'est lors de la première livraison d'un projet. En général, c'est le cas lorsque les seuls fichiers du projet sont README.md.

Une livraison ne doit inclure que les fichiers liés à la modification que vous livrez au repo. Vous devez être particulièrement prudent lorsque vous travaillez avec des projets Unity, car certaines modifications peuvent avoir pour effet de marquer plusieurs fichiers comme modifiés, tels que des scènes, des Prefabs ou des Sprite Atlases, même si vous n'aviez pas l'intention d'y apporter des modifications.

Si vous modifiez accidentellement une scène sur laquelle quelqu'un d'autre travaille, par exemple, cela peut lui causer un mal de tête lorsqu'il s'apprête à valider ses modifications et se rend compte qu'il doit d'abord fusionner les vôtres.

C'est l'une des erreurs les plus courantes que commettent les novices en matière de contrôle de version. Il est important de comprendre que vous ne devez livrer que vos propres modifications au projet. Pour en savoir plus, consultez cet article de blog sur la façon d'accélérer votre flux de travail.

Aussi souvent qu'il le faut, intégrez les dernières modifications du dépôt dans votre copie de travail. Ce n'est pas une bonne idée de travailler de manière isolée, car cela ne fait qu'augmenter la probabilité de conflits de fusion. Le tableau ci-dessus donne une idée du flux de travail quotidien typique pour chaque système.

Les flux de travail de Plastic SCM sont un peu différents car vous pouvez travailler dans des configurations centralisées, distribuées ou multisites.

Les configurations multisites peuvent être assez uniques, chaque utilisateur travaillant dans un flux de travail centralisé ou distribué.

Prenons l'exemple suivant :

• Deux équipes
• Chaque équipe dispose d'un serveur sur place
• Les membres de l'équipe s'enregistrent localement ou de manière distribuée sur chaque site, mais bénéficient de la rapidité d'un serveur situé à proximité.
• Les serveurs se poussent et se tirent les uns les autres pour rester totalement ou partiellement synchronisés.

Quel que soit le VCS choisi par votre équipe, assurez-vous que chacun se sente à l'aise dans son utilisation et comprenne les outils mis à sa disposition.

Si vous travaillez avec Git, tout le monde n'a pas besoin d'utiliser le même client GUI. Mais c'est une priorité de s'assurer que tout le monde se sente à l'aise avec le flux de travail " commit" > "pull" > "push". En d'autres termes, ils doivent être en mesure de n'engager que les fichiers dont ils ont besoin.

Si vous travaillez avec Plastic SCM, encouragez les artistes de votre équipe à s'habituer à Gluon, une interface graphique conviviale qui simplifie leur flux de travail. Gluon vous permet de choisir les fichiers sur lesquels vous souhaitez travailler, sans avoir à télécharger et à gérer l'ensemble du projet. Il vous permet également de verrouiller des fichiers, ce qui empêche d'autres personnes de travailler dessus. Une fois que vous avez terminé, renvoyez les fichiers au dépôt et déverrouillez-les à nouveau si nécessaire.

Lorsque vous travaillez sur un projet de longue durée avec plusieurs cycles de publication, le branchement des fonctionnalités est très utile pour votre flux de travail. Souvent, les équipes travaillent à partir de la même branche d'un repo, souvent appelée trunk, master ou main.

Dans ce cas, l'ensemble du projet suit le même calendrier. Toutefois, il peut être utile de diviser le travail en plusieurs branches afin de collaborer plus efficacement au sein de l'équipe.

Dans Git, un flux de travail spécifique appelé Git Flow se concentre sur l'utilisation de différentes branches pour les fonctionnalités, les corrections de bogues et les versions.

Ainsi, si un développeur commence à travailler sur une nouvelle fonctionnalité à l'intérieur d'une branche isolée, celle-ci sera réintégrée dans la branche principale une fois qu'il aura terminé. Pendant ce temps, un autre coéquipier peut apporter un correctif à la version précédente, ou corriger un bogue, et publier une nouvelle version en toute sécurité, sans inclure aucune des fonctionnalités encore en cours de développement.

Plastic SCM propose également des branches de tâches. Pour ce modèle, vous créez une nouvelle branche pour chaque tâche que vous suivez. Alors que dans Git Flow, nous utilisons des branches de fonctionnalités pour développer des fonctionnalités complètes, parfois de grande taille. Les branches de tâches dans Plastic SCM sont conçues pour être éphémères. Si la mise en œuvre d'une tâche nécessite plus d'une poignée de commits, il y a de fortes chances qu'elle puisse être décomposée en tâches plus petites.

Perforce Helix Core utilise un système appelé Streams pour faciliter ce type de flux de travail. Lorsque vous créez un dépôt pour y travailler, vous devez le configurer comme un type de dépôt de flux. Vous pouvez ensuite utiliser la vue Graphique des flux pour créer de nouveaux flux. Chaque flux (autre que le flux principal) devra avoir un flux parent, afin que les modifications puissent être copiées en amont.

Il existe différents types de cours d'eau pour différents objectifs. Lorsque vous passez d'un flux à l'autre sur votre poste de travail local ou que vous copiez des modifications en amont, seules les métadonnées des fichiers modifiés sont fusionnées, ce qui accélère le changement de contexte.

Une fois que vous avez terminé votre travail sur une branche de fonctionnalité, il est bon d'utiliser les demandes de retrait pour réintégrer vos modifications dans le flux principal du repo. Les pull requests sont créées par les développeurs de la fonctionnalité ou de la tâche. Il incombe généralement à un développeur senior ou à DevOps d'examiner les modifications avant de les accepter dans la ligne principale.

Plastic SCM et Perforce disposent tous deux d'outils automatisés pour aider à gérer la fusion des branches dans la ligne principale. Plastic SCM le fait avec l'aide de Mergebot, qui fusionne automatiquement les branches d'un repo une fois qu'elles ont été revues et qu'elles ont passé la validation. Perforce dispose d'une plateforme supplémentaire, Helix Swarm, utilisée pour gérer les revues de code, qui peut également être configurée avec des tests automatisés.

Même si vous travaillez sur un projet individuel, les principes d'organisation et de contrôle des versions peuvent s'avérer très utiles.

Lorsqu'on travaille en équipe, il est essentiel de privilégier une communication claire. En tant que groupe, vous devez vous mettre d'accord sur vos lignes directrices : comment structurer votre projet, quel système de contrôle de version utiliser et à quoi doit ressembler votre flux de travail dans ce système.

Ainsi, lorsque vous commencerez à intégrer d'autres outils tels que Jira, GitLab, des outils de construction ou des tests automatisés, le travail que vous avez déjà effectué pour structurer votre projet et votre flux de travail prendra tout son sens.