5 erreurs à ne jamais faire quand on utilise Git

Table des matières

Utiliser Git sans une méthode de travail

J’ai vu des développeurs débutants commençaient à appréhender Git en premier lieu pour versionner son travail. C’est tout à fait notable et c’est toujours mieux que rien sur le principe. On fait les commits sur branche master, on voit le flux de son travail avec les dates et l’heure, bref l’évolution et l’avancée de son code pour son projet.

Ouais, mais Git ce n’est pas juste tracker son travail et le versionner, c’est surtout de la collaboration sur du code en équipe pour un projet. Et il faut un minimum de rigueurs et d’organisations pour que cela se passe bien et que cela ne devienne pas un bordel monstre sans nom.

Heureusement, il existe des méthodes éprouvées pour travailler efficacement sans se marcher dessus et faire en sorte que la collaboration au niveau du code se passe sans encombre, dont une, que j’utilise tous les jours et que j’ai déjà présenté dans un article c’est Git Flow.

Mais peu importe la méthode, retenez juste qu’il faut structurer et organiser vos repositories par rapport vos objectifs de travail ainsi que votre équipe.

Avoir une branche develop et master non fonctionnelle

Là encore c’est une autre erreur qu’un débutant peut faire, c’est pousser tout et n’importe quoi sur ces branches permanentes. Vous devez absolument garder en tête que ces branches doivent être absolument fonctionnelles en termes de code et applicative.

Ce ne doit donc pas être des branches de travail en cours avec des fonctionnalités en cours de développement ou une application non fonctionnelle.

Master doit contenir du code terminé, testé et surtout mis en production pour utilisation.

Develop doit contenir en principe des fonctionnalités complètement terminées.

Pour le reste, cela doit se retrouver sur des branches de travail. C’est très important de respecter cela, car cela ajoute une organisation à votre travail et cela vous assure que des branches de votre application sont fonctionnelles.

Car pensez à une personne qui intégrerait votre équipe de développeur en cours de route. Elle n’aurait pas de question à se poser et vous n’avez pas besoin de lui expliquer pour faire fonctionner l’application. Il sait automatiquement que ce qui est sur master c’est l’application telle qu’elle est utilisée et sur develop les fonctionnalités développées qui iront bientôt en production.

Travailler à plusieurs sur la même branche

J’ai déjà vu ça plusieurs fois, je pense que les développeurs avaient une raison légitime, mais je n’ai jamais compris comment on peut arriver à faire cela. Le plus souvent c’est 2 développeurs qui travaille sur la même branche.

Là vous allez tuer purement et simplement l’efficacité de Git et la productivité dans votre travail.

Vous vous risquez non seulement à énormément de conflits entre vos commits mais en plus vous risquez d’écraser sans le vouloir le travail de votre collègue ou vice-versa. Vous ne devez JAMAIS, mais alors JAMAIS travaillé à plusieurs sur la même branche.

La seule fois où vous pouvez travailler à plusieurs sur la même branche c’est lorsque vous avez un problème technique et que votre collègue peut vous dépanner.

Vous allez alors passer la main à votre collègue pour votre branche (vous ne travaillez plus dessus pendant qu’il y travaille). Une fois qu’il vous a dépanné, vous récupérez son ou ses commits sur votre branche (grâce à la commande git pull) et vous pouvez ensuite reprendre votre travail en cours sur votre branche.

S’il y a bien une erreur à ne jamais faire, c’est bien celle-ci.

Coder plusieurs features sur une seule branche

Si vous adoptez Git Flow, vous savez qu’il existe plusieurs types de branches de travail, dont celle qui m’intéresse ici, qui est la branche de feature. Une feature est la réalisation d’une nouvelle fonctionnalité.

Mais lorsque l’on développe, on peut être vite tenté de réaliser plusieurs fonctionnalités sur une seule et même branche. Tout simplement parce que l’on juge que ce sont des petites fonctionnalités et que ce n’est pas grave.

Détrompez-vous, car ça l’est ! Même si sur le moment vous pensez le contraire sur plus long terme ça l’est vraiment. Tout d’abord au niveau de la clarté. Une branche de feature qui contient plusieurs features c’est très fouillis et ce n’est pas très clair à lire.

Pensez-vous aux personnes qui feront la review de votre code ? Croyez-vous que faire la review fichier après fichier avec plusieurs fonctionnalités développées dedans sera une chose aisée pour la personne ?

Bien sûr que non ! Ce sera pénible pour lui au point de bâcler la review et de passer à côté d’éventuels bugs ou d’incohérences au niveau métier.

Autre exemple : admettons que pour une raison quelconque vous deviez annuler votre fonctionnalité. Il sera beaucoup plus simple d’isoler et d’annuler le code de cette fonctionnalité s’il est contenu sur une branche dédiée plutôt qu’une branche qui contient beaucoup de features.

Réaliser des commits n’importe comment

Lorsque l’on débute sur Git, on nous explique qu’il ne faut pas hésiter à réaliser beaucoup de commits par sécurité pour sauvegarder son travail. C’est un bon conseil que je recommande vivement moi aussi.

Seulement ce conseil est incomplet ou plutôt pas assez précis. Faire des commits régulièrement ne veut pas dire faire des commits n’importe comment.

Il faut faire des commits cohérents par rapport à ce que vous êtes en train de réaliser. Voyez cela un peu comme une histoire. Votre branche de travail est un livre et vos commits sont des chapitres. Vous devez donc avoir un début, un milieu et une fin.

Lorsque l’on parcourt les commits de votre branche, on doit pouvoir retracer la logique de conception de votre fonctionnalité. Donc si vous devez développer du code backend puis du code frontend et enfin connecter les 2 alors vous devez le faire avec au minimum 3 commits bien distincts.

Cela vous implique également de nommer correctement vos commits et de décrire le plus possible ce que vous avez fait. Cela prend du temps, mais c’est du temps très bien investi, car vous vous constituez inconsciemment votre documentation technique.

Épilogue

il existe bien entendu beaucoup d’autres erreurs à ne pas faire avec Git mais ces 5 erreurs que je vous ai décrites vont déjà vous permettre d’avoir des repositories bien organisés et surtout très propres.

Je vous donne comme dernier conseil de toujours garder en tête ce que vous êtes en train de faire et de toujours bien le décrire lorsque vous terminez quelques choses.