Bonnes pratiques de gestion des versions

C'est de loin l'amélioration la plus simple que vous puissiez apporter à votre flux de travail, pourtant c'est celle avec laquelle certains développeurs ont le plus de mal. Lorsque vous travaillez avec d'autres outils de gestion de projet, il est probable que vous ayez déjà décomposé le travail en petites tâches gérables. Les commits doivent être traités de la même manière.

Un seul commit ne doit concerner qu'une seule tâche ou ticket, à moins qu'une seule ligne de code ne corrige magiquement plusieurs bugs. Si vous travaillez sur une fonctionnalité plus grande, décomposez-la en tâches plus petites et faites des commits pour chacune.

Le plus grand avantage d'utiliser des 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 de commit décrivent l'historique de votre projet. Après tout, il est beaucoup plus facile de trouver le changement qui a ajouté des tableaux de scores à votre jeu si son message de commit indique « ajouté des tableaux de scores au menu » plutôt que « pariez que vous ne pouvez pas battre mon score sur ces nouveaux tableaux ! »

Lorsque 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 commit. De nombreux systèmes peuvent être configurés pour fonctionner ensemble avec des commits intelligents afin que vous puissiez réellement référencer des tickets et changer leur statut depuis votre message de commit.

Par exemple, un commit qui indique « JRA-123 #close #comment tâche terminée » fermerait le ticket Jira JRA-123, laissant le commentaire « tâche terminée » 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é est lors du premier commit d'un projet. En général, c'est lorsque les seuls fichiers dans le projet sont README.md.

Un commit ne doit inclure que des fichiers qui sont liés au changement que vous engagez dans le dépôt. Vous devez être particulièrement prudent lorsque vous travaillez avec des projets Unity car certains changements peuvent entraîner plusieurs fichiers marqués comme modifiés, tels que des scènes, des Prefabs ou des Sprite Atlases, même si vous n'aviez pas l'intention d'apporter des modifications à ceux-ci.

Si vous engagez accidentellement un changement à une scène sur laquelle quelqu'un d'autre travaille, par exemple, cela peut lui causer des maux de tête lorsqu'il va engager ses changements et voit qu'il doit d'abord fusionner vos changements.

C'est l'une des erreurs les plus courantes que les personnes qui sont nouvelles dans le contrôle de version commettent. Il est important de comprendre que vous ne devez engager que vos propres changements dans le projet. Pour en savoir plus, consultez cet article de blog sur la façon d'accélérer votre flux de travail.

Aussi souvent que cela a du sens, tirez les derniers changements du dépôt dans votre copie de travail. Ce n'est pas une bonne idée de travailler en isolation, car cela augmente seulement la probabilité de conflits de fusion. Voir le tableau ci-dessus pour avoir une idée d'un 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é.

Considérez l'exemple suivant :

• Deux équipes
• Chaque équipe a un serveur sur site
• Les membres de l'équipe s'enregistrent localement ou de manière distribuée à chaque site, mais bénéficient de la rapidité d'un serveur sur site proche
• Les serveurs se poussent et se tirent entre eux pour rester entièrement ou partiellement synchronisés

Quel que soit le VCS avec lequel votre équipe choisit de travailler, assurez-vous que tout le monde est à l'aise avec son utilisation et comprend les outils à sa disposition.

Si vous travaillez avec Git, tout le monde n'a pas besoin d'utiliser le même client GUI. Mais faites-en une priorité de veiller à ce que tout le monde se sente à l'aise avec le flux de travail commit > pull > push. En d'autres termes, ils devraient avoir les connaissances nécessaires pour ne valider 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 pour simplifier leur flux de travail. Gluon vous permet de décider des fichiers sur lesquels vous souhaitez travailler, supprimant ainsi le besoin de télécharger et de gérer l'ensemble du projet. Il vous permet également de verrouiller des fichiers, ce qui empêche les autres de travailler dessus. Une fois que vous avez terminé, soumettez les fichiers à nouveau dans le dépôt et déverrouillez-les au besoin.

Lorsque vous travaillez sur un projet de longue date avec plusieurs cycles de publication, le branchement de fonctionnalités est très bénéfique pour votre flux de travail. Souvent, les équipes travaillent à partir de la même branche d'un dépôt, probablement appelée tronc, maître ou principal.

Lorsque vous faites cela, l'ensemble de votre projet avance le long de la même chronologie. Cependant, il peut être utile de diviser le travail en plusieurs branches pour collaborer plus efficacement en tant qu'é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 publications.

Ainsi, si un développeur commence à travailler sur une nouvelle fonctionnalité dans une branche isolée, elle sera fusionnée dans la branche principale une fois qu'il aura terminé. Pendant ce temps, un autre membre de l'équipe peut effectuer un correctif sur la publication précédente, ou corriger un bogue, et publier une nouvelle version en toute sécurité, sans inclure aucune des fonctionnalités encore en 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 grandes. Les branches de tâches dans Plastic SCM sont destinées à être de courte durée. Si une tâche prend plus qu'une poignée de commits à mettre en œuvre, 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 style de flux de travail. Lors de la création d'un dépôt pour travailler, vous devez le configurer comme un type de dépôt de flux. Ensuite, vous pouvez utiliser la vue Graphique de Flux pour créer de nouveaux flux. Chaque flux (autre que le flux principal) doit avoir un flux parent, afin que les modifications puissent être copiées en amont.

Il existe différents types de flux pour différents objectifs. Lorsque vous passez d'un flux à l'autre sur votre station de travail locale ou que vous copiez des modifications en amont, seules les métadonnées des fichiers modifiés sont fusionnées, ce qui rend le changement de contexte plus rapide.

Une fois que vous avez terminé le travail sur une branche de fonctionnalité, il est bon de pratiquer l'utilisation de demandes de tirage pour ramener vos modifications dans le flux principal du dépôt. Les demandes de tirage sont créées par les développeurs de la fonctionnalité ou de la tâche. C'est généralement la responsabilité d'un développeur senior ou d'un DevOps de revoir les modifications avant de les accepter dans le flux principal.

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

Même si vous travaillez sur un projet solo, les principes d'organisation et de contrôle de version peuvent être vraiment utiles.

Lorsque vous travaillez en équipe, il est crucial de prioriser une communication claire. En tant que groupe, vous devez vous mettre d'accord sur vos directives : comment vous devez structurer votre projet, quel système de contrôle de version utiliser et à quoi devrait ressembler votre flux de travail dans ce système.

De cette façon, lorsque vous commencez à intégrer d'autres outils comme Jira, GitLab, des outils de construction ou des tests automatisés, le travail que vous avez déjà fait pour structurer votre projet et votre flux de travail sera mis en valeur.