Qu’est-ce que c’est ?
Vous avez probablement déjà entendu parler de git, mais à moins que vous ne l'utilisez déjà (auquel cas cette page ne vous apprendra pas grand chose), c'est un outil qui vous parait certainement assez complexe et mystérieux. Mais comme pour tout, une fois qu'on a compris, c'est en fait très simple ! C'est parti pour démystifier ça !
A quoi ça sert ?
Git est donc un logiciel qui permet de travailler à plusieurs sur un même projet sans se marcher sur les pieds, mais aussi de versionner son projet pour pouvoir à tout moment revenir en arrière, ce qui est très pratique en cas de problème, mais également lorsqu’on avance dans une direction incertaine ! L’idée de base est d’avoir le projet (= un dossier contenant divers fichiers, ce peut être n’importe quoi) hébergé à un endroit accessible à tous les participants, servant de projet de référence. Les participants se basent alors sur ce projet (qu’on appelle “repo”) pour en créer une copie en local (sur son ordinateur) pour ensuite faire leur modifications. Ils publient ensuite leur modifications au projet de référence et peuvent demander à ce dernier quelques changements que les autres participants ont fait pour se mettre à jour.
Quelle différence entre Git et Github ?
Et bien c’est simple : Github, tout comme Gitlab et bien d'autres, n'est qu'un site qui héberge du code et utilise Git pour gérer ce dernier. Il propose également quelques outils additionnel de gestion de projet comme des issues (= tâches), ce forum de discussion et autres intégrations diverses (il est parfois difficile de savoir ce qui est Git et ce qui ne l'est pas, mais c'est suffisamment bien fait pour qu'on ai pas besoin de se poser la question !)
Ce n’est que pour du code ?
Oui … et non ! C’est pensé pour gérer du code, mais ça peut en réalité être utilisé pour gérer n’importe quel type de fichier et peut donc parfaitement être utilisé pour gérer le pack de ressource ou une map entière !
Pourquoi l’utiliser ?
Il y a 4 bonnes raisons d’utiliser git et github pour gérer son projet :
- La collaboration : 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 étant fait pour collaborer ensemble sur un projet en gérant la fusion des modifications de chacun, le travail d’équipe devient bien plus simple ! C’est un peu comme un google doc où tout le monde peut écrire et voir les modifications des autres, mais en adapté à des gros projets sur plusieurs fichiers et où les membres peuvent travailler même en étant temporairement hors ligne !
- Le versionnage : 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.
- L’organisation : cet aspect est d’avantage fournit par Github, qui offre un système d’“issues” (= tâches) pouvant être associé à des labels pour les trier par type ou priorité, le tout pouvant être organisé sous la forme de tableau Kanban (à la façon de Trello) avec différentes visualisation possible dans ce que Github appel les “projets”. Github offre également des forums de discussions qui peuvent être utilisé pour des choix techniques importants, là où des discussions Discord sont très volatile 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. 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.
- L’ouverture et les feedbacks : 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 de 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 ! (on va voir ça un peu plus loin)
Vocabulaire
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.
Répertoire git (ou "repo" pour les intimes)
(Repository en anglais) Il s'agit simplement du nom donné à votre projet une fois qu'il utilise git, tout simplement ! Cette distinction est importante car là où en temps normal, si vous supprimez votre projet, vous le perdez complètement, ici le projet sera a plusieurs endroits, dont un endroit qui servira de projet "maitre" (celui sur lequel les autres vont se base pour se mettre à jour, qu'on appel "origin"). Cet endroit, c'est généralement Github/Gitlab/autre de sorte à ce que tout le monde puisse y avoir accès tout en étant sûr que le projet risque pas d'être perdu parce que vous avez renversé du café sur votre ordinateur.
Cloner un répo
Consiste à créer une copie locale (sur votre ordinateur) du projet lié à celui qui est hébergé sur Github (le fameux emplacement qu'on appel "origin"). Il ne suffit donc pas de télécharger le code depuis la page Github ! En faisant ça, vous aurez le code, mais pas un dossier caché ".git" qui contient des informations précieuses permettant à Git de savoir qu'il s'agit d'un répertoire et où se trouve l'origine, l'historique etc.
Pull
Récupère toutes les modifications apporté sur origin et les applique en local (en gros, ça synchronise Github -> votre ordi). Contrairement à copier/coller un dossier sur un autre, cette opération n'écrase pas tout votre projet local, elle ne fait qu'appliquer les modifications qu'origin a subit depuis votre dernier pull ! Autrement dit, si vous éditez le fichier A et que quelqu'un fait une modif sur le fichier B qu'il envoi sur Github, lorsque vous allez pull, seul le fichier B va être modifié. Si vous avez tous les deux modifié 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, on ne s'en préoccupe pas.
Commit
Git permet de faire du versionnage, c'est à dire que vous aurez la possibilité de retracer tout l'historique de l'évolution du projet et potentiellement revenir a une version précédente. C'est très pratique lorsque vous vous adonnez à un système complexe et que vous rencontrez un problème de design 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. A chaque lot de modification de votre projet, une fois que vous en êtes satisfait, vous ferez alors un commit, qui est une sorte de sauvegarde de ces modifications et qui, cumulée à TOUS les commits (= lots de modification) précédents, permet à git de reconstruire l'état exacte du code au moment où le commit est fait (c'est foutrement bien fait !). Un commit se fait en local, sur votre ordinateur donc, et vous devrez ensuite envoyer vos commits à Github via un "push"
Push
L'opération inverse du pull. Ici, vous envoyer à Github vos modifications (synchronisation local -> origin). 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é !