Contexte[modifier | modifier le wikicode]
Imaginons plusieurs scénarios assez classique lorsque l’on travaille sur la conception de pack dans Minecraft (pack de données, pack de ressources) :
Scénario 1
Vous travaillez avec votre ami·e sur un nouveau pack de données. Vous possédez un serveur sur lequel vous testez votre pack et vous travaillez chacun sur votre machine sur une partie du code. Afin de mettre à jour le pack de données, vous mettez en ligne régulièrement vos fonctions en passant par des outils comme Filezilla ou directement par le panel de votre serveur et régulièrement vous téléchargez l’ensemble du pack du serveur afin de mettre à jour la version que vous avez sur votre machine. Mais voilà, vous devez faire attention à n’envoyer sur le serveur que les fonctions sur lesquels vous avez travaillé pour ne pas écraser le travail de votre ami·e. Même avec toutes les précautions que vous prenez, il vous arrive parfois d’avoir édité un même fichier que vous mettez tous les deux sur le serveur et n’étant pas au courant que votre ami·e à toucher ce fichier, vous supprimer ses modifications par inadvertance. Le pire dans tout cela, c’est que votre ami·e, pas au courant que vous avez écrasé son fichier à télécharger le pack pour se maintenir à jour, et toutes les modifications que vous avez écrasé sont perdues à jamais…
Scénario 2
Vous êtes en train de travailler sur un nouveau pack de ressources qui personnalise les modèles du jeu. Pour un modèle, vous n’êtes pas pleinement satisfait du résultat, il s’intègre bien avec le reste de vos modèles, mais voilà, vous pensez que vous pouvez faire mieux et vous souhaitez explorer vos idées. Comme celles-ci risquent de beaucoup impacter votre modèle, vous décidez de faire une copie du fichier nommée “mon_super_modèle (1)” afin de pouvoir le récupérer si vos idées ne vous mènent finalement nulle part. Vous refaites cette opération à chaque fois que vous bouclez l’une de vos idées afin de garder chacune de vos pistes : “mon_super_modèle (2)”, “mon_super_modèle (3)”, …, “mon_super_modèle (6)”. Une fois votre exploration finie, vous revisualisez l’ensemble de vos modèles : le 3e vous plaît beaucoup, mais cette partie du 5e aussi, vous vous lancez donc dans une fusion des deux modèles.
Ces scénarios vous parlent ? Et si je vous disais qu’il existe des outils qui vous simplifieraient grandement la vie si maîtrisé un minimum…
Git[modifier | modifier le wikicode]
Git est un logiciel dit “de gestion de versions”. Il permet à un utilisateur de travailler sur son une base de code (dans notre cas, des packs Minecraft) et de faire des versions de ce projet tout en gardant l’historique complet de celui-ci. Cela signifie qu'il garde une trace de toutes les versions des fichiers de vos projets, vous permettant ainsi de parcourir toute l’évolution de votre projet voire de repartir d’une étape précédente de celui-ci. Bref, plus jamais vous ne perdrez traces de vos travaux (ou presque) !
Mais là où la vraie puissance de git se révèle, c’est dans son fonctionnement… En fait avec git, tous les fichiers de votre pack sont sur votre machine, mais lorsque vous jugez votre progression suffisante, vous pouvez demandé au logiciel de les envoyer directement sur un serveur git ! Ce qui est bien avec cela, c’est que plusieurs utilisateurs peuvent envoyer leurs modifications sur ce serveur, ce qui permet la collaboration sur un même pack. Git propose également des facilités lorsqu’un conflit apparaît, c’est-à-dire lorsque deux utilisateurs modifient le même fichier. Le logiciel est alors soit capable de fusionner les deux versions du fichier comme un grand, soit il demande à un utilisateur de le faire en lui montrant ce qui a été modifié par les deux utilisateurs : fini donc d’écraser le travail de votre ami·e sans qu’aucun de vous ne le remarquiez.
Nous reviendrons plus en détail sur le fonctionnement de git plus tard dans ce guide.
Le terme de “serveur” pour git peut vous effrayez un peu, mais pas d’inquiétude, vous n’aurez rien à héberger vous même ! Il existe des sites web qui le font pour vous et nous allons maintenant nous concentrer sur l’un d’eux : Github.
Github[modifier | modifier le wikicode]
Github est l’une des plateformes supportant git les plus connues. Possédé par Microsoft, celle-ci vous propose comme son nom peut le laisser sous-entendre d’héberger votre code, il joue alors le rôle du “serveur git” que nous avons abordé dans la partie précédente. Mais Github, c’est aussi bien plus que ça : là où git permet la collaboration d’utilisateur sur une base de code (donc dans notre cas les packs Minecraft), Github permet une véritable collaboration sur le projet dans son ensemble : permettre à une communauté de discuter autour de votre projet par le biais d’un page de discussion dédiée ; remonter des problèmes comme des bugs ; proposer de nouvelles fonctionnalités ; contribuer au projet ; faire un wiki pour son projet ; ordonner et répartir les tâches à réaliser (comme de la résolution de bug) entre les différents participants au projet… Bref, il s’agit d’une véritable forge de la gestion de projet !
TL;DR : pourquoi vous devriez utiliser git et Github[modifier | modifier le wikicode]
Il y a 4 bonnes raisons d’utiliser git et github pour gérer son projet :
- Collaborer : travailler en équipe peut être assez compliqué surtout quand, comme pour beaucoup de créateurs sur Minecraft, ce n’est pas quelque chose d’habituel. Git permet de faciliter grandement la tâche car il facilite la gestion de conflit entre les modifications apportés par deux utilisateurs, et même si vous arrivez à écraser le travail d’un autre, ce n’est pas grave, l’historique vous permet de “remonter dans le temps”. Bref, le travail d’équipe devient bien plus simple !
- Versionner : si un projet est suffisamment complexe et/ou long, il peut être intéressant d’avoir accès à des versions précédente, ce qui permet aussi bien de revenir à l’une de ces versions si un problème a été introduit quelques temps en arrière, mais ça permet également de faire des tentatives pour faire évoluer le projet, et si cette tentative n’aboutit à rien de satisfaisant, il suffit d’abandonner et de revenir à l’état du projet avant le début de la tentative.
- Organiser : cet aspect est d’avantage fournit par Github, qui comme mentionné dans la partie dédiée offre par exemple un système pour remonter des problèmes. Ces problèmes, comme des bugs peuvent se voir associer des labels pour les trier par type ou priorité. Les participants aux projets peuvent ensuite organiser ses problèmes sous forme de tâche dans des tableaux ou des Kanban (à la façon de Trello). Ces tâches peuvent ensuite être associées aux participants qui s’en occuperont, ça permet alors une vraie gestion de projet. Github offre également des forums de discussions qui peuvent par exemple être utilisés pour des choix techniques importants. Là où des discussions sur Discord sont très volatiles et peuvent partir n’importe où, les forums Github pousse à se concentrer sur le sujet et le conserve de sorte à ce qu’il soit facile de retrouver la discussion et les informations qu’elle contient. Bref, il y a moins ce côté “instantané”, et ce n’est pas plus mal. Enfin, Github dispose d’”actions”, des petites fonctions simples à ajouter au repo et qui vont se déclencher automatiquement pour, par exemple, envoyer le code sur un serveur pour le mettre à jour automatiquement après chaque modification, ou encore envoyer un mail au chef de projet, tout est possible ! Ces possibles connexions et interactions vont permettre de simplifier des tâches qui peuvent être parfois fastidieuses.
- S'ouvrir à une communauté : ce dernier point est sans doute le plus important, il vous permet de ne jamais vous isoler ! Un projet mené seul de façon complètement isolé finit très souvent par être laissé à l’abandon ou être exploité dans un cas personnel uniquement alors même qu’il pourrait rendre service à d’autres. Github est une sorte de réseau social du code, il ne faut donc jamais hésiter à mettre ses projets en public dessus si l’idée de partager ces derniers vous plait. C’est le meilleur moyen pour le reste du monde de voir sur quoi vous travaillez, de vous faire des retours et même, parfois, de vous aider en proposant des modifications ! (nous verrons cela un peu plus loin)
Vocabulaire[modifier | modifier le wikicode]
Voici tous les termes techniques de git que vous finirez par utiliser naturellement. Pas la peine de lire toute cette partie d'une traite, vous pouvez y revenir quand vous bloquez sur un mot.
Dépôt git (ou "repo" pour les intimes)[modifier | modifier le wikicode]
(Repository en anglais) Il s'agit de l'endroit où est votre pack qui utilise git, concrètement… sur votre ordinateur, il s'agit d'un dossier qui a quelques informations cachées spécifiques à git, comme l'historique de votre pack par exemple.
Comme nous l'indiquions plus tôt, ce qui est bien avec git c'est la possibilité d'envoyer les modifications apportés à son pack sur un serveur, comme Github par exemple. Eh bien même sur ce serveur, votre pack sera stocké dans un dépôt ! Finalement, envoyer ces modifications, c'est les porter dans un autre dépôt que l'on appelle "dépôt distant", à l'opposé de celui sur votre machine que l'on appelle "dépôt local". C'est donc sur ce dépôt distant que se porte la collaboration. Chaque utilisateur à son dépôt local et envoie ses modifications sur ce même dépôt distant. Un utilisateur peut par la suite se resynchroniser avec le dépôt distant afin d'avoir les modifications apportés par les autres dans son propre dépôt local. Nous verrons ces actions plus en détail plus tard.
Avec ce dépôt distant, votre pack sera protégé, fini la perte de données lorsque vous avez renversé du café sur votre ordinateur !
En pratique, git permet même d'avoir plusieurs dépôts distants pour un même code. Cela est un usage avancé que nous ne détaillerons pas dans ce guide. Ce qui est important à retenir, c'est qu'il est possible de donner un nom à ces dépôts distants pour les différencier. Par défaut et par convention, le nom du premier dépôt distant (et du seul dans la plupart du temps) est "origin".
Cloner un répo[modifier | modifier le wikicode]
Consiste à créer une copie locale (sur votre ordinateur) du code lié à celui qui est hébergé sur Github (le fameux emplacement qu'on appel "origin"). Autrement dit, cela créé un nouveau dépôt local par copie d'un dépôt distant. Il ne s'agit pas d'un simple téléchargement de votre pack depuis Github, car vous aurez en plus des fichiers cachés dans un dossier ".git" qui contient plein d'informations essentielles pour git, comme l'historique de votre pack par exemple ou où se trouve votre dépôt distant.
Pull[modifier | modifier le wikicode]
Récupère toutes les modifications apporté sur le dépôt distant et les applique en local (en gros, ça synchronise le dépôt distant avec votre dépôt local). Contrairement à copier/coller un dossier sur un autre, cette opération n'écrase pas tout votre dépôt local, elle ne fait qu'appliquer les modifications que le dépôt distant a subit depuis votre dernier pull ! Autrement dit, si vous éditez le fichier A et que quelqu'un fait une modification sur le fichier B qu'il envoie sur Github, lorsque vous allez pull, seul le fichier B va être modifié. Si vous avez tous les deux modifiés le même fichier mais sur des lignes éloignées, git est également capable de faire la distinction ! Par contre, si vous modifiez les mêmes lignes, il y aura un conflit qu'il faudra résoudre, mais pour le moment, nous nous en préoccupons pas.
Commit[modifier | modifier le wikicode]
Les modifications que vous apportez à votre pack ne sont pas envoyés de façon instantanée sur le dépôt distant et bien heureusement, comme ça vos collaborateurs ne recevront pas le code de votre pack de données avec tous les "say toto" pour savoir d'où vient votre bug (oui oui, on vous voit ceux qui font ça). C'est donc à vous de choisir quoi envoyer sur le dépôt distant, et c'est à cela que servent les commits. Commiter, c'est soumettre vos modifications, ça ne les envoie pas directement sur le dépôt distant, mais ça les ajoute à l'historique local et ça les prépare à être envoyé. C'est pour cela que l'on parle de "logiciel de gestion de versions", car un commit est une version de votre pack et que le commit est le concept fondamental de git. Tant que vous ne commitez pas vos fichiers, vous pouvez encore perdre vos données si vous les écraser mais une fois commité, peu importe ce que vous ferez dans vos fichiers, vous pourrez les restaurer grâce à l'historique. C'est très pratique lorsque vous vous adonnez à un système complexe et que vous rencontrez un problème de conception qui nécessite de refaire une partie de ce que vous avez fait. Plutôt que d'essayer de retrouver chaque modification que vous avez apporter pour la défaire (et généralement en oublier plein), vous pourrez simplement revenir a un commit précédent, où le soucis de design n'a pas encore été introduit.
Néanmoins il ne faut pas commiter à chaque modification non plus ! Un commit est permanent (bon en vrai pas vraiment, mais disons pour simplifier que ça l'est) et sera une fois envoyé sur le dépôt distant visible par tous les autres collaborateurs (voire par tous le monde si votre projet est ouvert à tous, open source). Commiter, c'est donc s'engager (traduction du mot anglais "commit") vis-à-vis des autres : vous vous engagez à ne pas casser ce que l'on fait les autres, vous vous engagez à garder à ce que vos modifications gardent le pack fonctionnel. Par exemple, on ne commit pas des modifications qui rendent tout ou parti du pack illisible par Minecraft ! La bonne pratique est de commit lorsque l'on arrive dans un état stable de notre pack, autrement dit lorsque l'on est satisfait de nos modifications, qu'il n'y a pas (trop) de bugs et que c'est fonctionnel dans le jeu. Par exemple, si je développe un pack de données qui a pour but d'ajouter un nouveau boss au jeu, je commit lorsque j'ai fini de programmer un nouveau sort qui fonctionne pour le boss et je ne commit pas si je suis au milieu du développement de mon sort.
Un commit se fait en local, sur votre ordinateur donc, et vous devrez ensuite envoyer vos commits à Github via un "push".
Push[modifier | modifier le wikicode]
L'opération inverse du pull. Ici, vous envoyer à Github vos modifications (synchronisation du dépôt local avec le dépôt distant). De la même façon, ça ne modifiera sur Github que ce que vous avez modifié, rien d'autre, ce qui permet à d'autres utilisateurs d'appliquer des modifications en parallèle ! Même si on y reviendra en détail, vous l'aurez compris rien qu'à ces définitions, l'idée est de d'abord pull pour se mettre à jour localement, puis modifier son code, commit à chaque fois qu'on fait une avancée satisfaisante, puis push une fois la fonctionnalité implémenté !