Avant de voir ce qu’est Git et ce qu’il fait, je dois t’expliquer ce qu’il ne fait pas, et par conséquent ce que tu ne verras pas dans ce cours. 

Mais ne sois pas déçu à l’avance, on a d’autres cours qui traitent peut être déjà des sujets qui t’intéressent, et si ce n’est pas le cas, peut être que nous les créerons un jour prochain, et si t’es sympa, bien évidemment…

Git n'est pas un « serveur »

Pour commencer, Git n’est pas un serveur, il n’embarque pas de serveur. Il nous permet éventuellement de créer ce qu’on appelle un “bare repository” ou « dépôt nu » et qui nous permet de définir une destination pour notre partage et qui ne posséderai pas de copie de travail. C’est donc fait pour qu’on ne puisse pas travailler dedans. 

Je ne te parlerai donc pas de GitHub, GitLab, BitBucket, ni d’aucune autre solution d’hébergement Git, car c’est au-delà des concepts et il y a tellement à dire que ça mérite un cours dédié.

Git n’impose aucune règle

Tu dois aussi comprendre un point crucial de Git : il n’impose aucune règle. Ce que je veux dire par là et que tu dois bien retenir, c’est que Git te permet de faire tout ce que tu veux de tes versions. Il a été conçu pour ne créer aucune barrière. Ça veut dire que si tu veux, tu peux changer tout ton historique de commits, faire disparaître certaines parties, en ajouter ou en déplacer d’autres. 

Je te rassure quand même, il a en plus des mécanismes que te permettent de revenir en arrière en cas d’erreur ou face à une mauvaise intention. Ça veut dire que le mec rageux qui a voulu supprimer l’historique du projet en quittant la boite a fait un tir à blanc, car le projet pourra être reconstruit depuis les versions des différents postes utilisateurs. 

Sache aussi que Git n’impose aucune organisation du travail formelle, et c’est tant mieux, ça évite de se limiter à un type de cycle de de vie de projet. Donc si tu es « hype » et que bosses avec une méthodologie type Agile, voire Scrum, il n’est pas dit que tu appliques ta méthodologie à la lettre, et il n’est pas non plus dit que tu en changes plus tard, ce qui fait que tu sera plutôt content de ne pas être contraint et de pouvoir changer ton organisation dans ta gestion de versions.

Alors, quand je dis qu’il n’y a aucune contrainte, il faut relativiser, hein ! Parce que Git a ses commandes, sa syntaxe, son comportement nominal. Mais on peut quand même tuner tout ça depuis la configuration pour plein de petites choses, donc là aussi, Git est permissif.

Git ne valide pas tes contenus

Pour finir avec ce que Git ne fait pas pour toi, il ne fait pas de validation des contenus que tu versionnes à commencer par les messages de tes commits. Ça signifie que tu peux y mettre le texte que tu veux, comme tu veux. Tu peux même y mettre des emojis si ça te branche.

En réalité, tu peux mettre en place des systèmes de validation, que ce soit une assistance au moment de la saisie, comme Git commitizen, ou après la saisie pour vérifier le message avec des outils comme commitlint. En gros, tu peux déclencher ce que tu veux autour de la création de ton commit avec ce qu’on appelle les hooks Git.

Tu n’as également aucune contrainte sur les types de fichiers que tu versionnes. Tu peux aussi bien mettre du texte, que des images, des vidéos, des binaires… Par contre tu dois savoir que seuls les fichiers non binaires seront optimisés par Git. 

Là aussi c’est à moitié vrai, Git n’impose aucune contrainte, mais tu peux en créer toi même, que ce soit à l’aide du fichier .gitignore ou encore une fois des hooks, pour prévenir de l’ajout de fichiers non désirés.

Et pour finir, tout comme Git n’intègre pas de serveur à proprement parler, il n’intègre pas non plus de système d’intégration continue. Mais là encore, tu peux venir toi-même intégrer ça à l’aide des hooks.

Donc si on résume tout ça, Git ne nous contraint à rien, mais il nous donne quand même la possibilité de venir définir nous-même nos contraintes au sein d’un projet. Comme quoi le truc a été bien pensé !