Les 5 + 1 erreurs les plus communes dans l’utilisation de Git

0
207

Choisir un gestionnaire de sources pour son code, son projet, c’est une première belle étape. Et pourtant, les réflexes ont la vie dure !
Découvrons ensemble les 5 erreurs que l’on peut faire dans l’utilisation de Git et de son écosystème.

1 – Utiliser Git comme outil d’archivage

Lorsque l’on n’a pas l’habitude d’utiliser un outil de versionning et que l’on entend parler de Git (ou de svn, de mercurial, ..), on va commencer par l’utiliser comme outil d’archivage.

A savoir qu’on va envoyer toutes nos modifications uniquement dans un but d’archiver sur un serveur central.
C’est déjà une bonne étape.
En effet, on a au moins un historique par journée (c’est fréquent que « l’archive » est faite le soir, avant de partir).

Pourquoi ce n’est pas une bonne pratique ?

L’utilisation d’un Gestionnaire de sources comme Git permet d’aller beaucoup plus loin !
Pourquoi s’en priver ?

De plus, plus on envoie des commits gros, plus les conflits rencontrés seront difficiles à gérer, à corriger par vos collègues.
Très problématique quand on veut partir vite le soir, ou bien que l’on cherche une bonne cohésion d’équipe 🙂

2 – Ne faire qu’un commit par journée

Oui faire un commit ça prend du temps. Oui, c’est même par moment assez redondant. On aimerait tellement que ça soit automatique.
Ou bien … ne le faire qu’une fois par jour, au moins, on serait plus tranquille (pourquoi devoir faire ces satanées commits ?!)


Pourquoi ce n’est pas une bonne pratique ?

Lorsqu’on fait un commit, on crée une version de notre code.
C’est le point le plus important à garder.

A chaque version, c’est une histoire que vous racontez, que vous sauvegardez.
Comme si on partait en voyage : voulez-vous n’avoir qu’une photo par jour de ce beau voyage ?
Cherchez à avoir plein de beaux moments de votre journée de développements : favorisez de nombreux commits !

3 – Faire des pushs trop fréquents

A l’opposé d’un commit trop tardif, vous allez peut être chercher à appliquer ce que vous faisiez sous SVN : un commit = un push.
Et là, tout d’un coup, vous avez vos collègues qui vont venir vous sauter à la gorge pour tout le code non testé que vous leurs envoyez.

Pourquoi ce n’est pas une bonne pratique ?

C’est un art, un juste équilibre de trouver le bon rythme entre des push et des commits.

Si vous envoyez trop souvent votre code à la communauté, sans en plus tester, vous allez créer un historique / un partage commun de code qui sera à instant T instable (entendez ici : buggué).
Préférez le principe suivant : je push que lorsque j’ai :

  • Testé en local
  • Tous mes tests automatisés passent au vert

4 – Ne pas utiliser les branches locales et distantes

Les branches, vous savez que ça existe. Et vous savez aussi que ça favorise les conflits. Alors, ça non, qu’on ne vous y reprenne pas, vous n’utiliserez pas les branches, ça crée trop d’instabilité selon vous !

Pourquoi ce n’est pas une bonne pratique ?

Une branche, c’est comme un univers parallèle.
Ca va vous sortir de situations très compliquées à gérer sans branches ! Du genre :

  • Je veux livrer en production une correction, alors que j’étais en plein dev d’une évolution, non testée, ou non finie
  • Je souhaite récupérer toute une partie d’un travail effectué voila deux semaines, et le tester avant livraison, ou bien l’annuler
  • J’ai besoin de récupérer le travail d’un-e collègue et je veux l’isoler avant de le récupérer

Apprenez à utiliser les branches locales.
Respectez la durée d’une branche locale : une journée tout au plus.
Rebasez votre branches locale sur vos branches distantes, avant push.

5 – Ne pas avoir de Cadrage (Git flow)

Vous démarrez un projet Git, et vous souhaitez utiliser les branches locales, et distantes.
Personne ne donne de ligne directrice sur l’utilisation des branches, et comment on passe d’une à l’autre.

Pourquoi ce n’est pas une bonne pratique ?

Sans cadre, dans un projet avec plusieurs personnes, ça va vite partir dans tous les sens, devenir illisible. Et la reprise de code, par un nouveau, une nouvelle dans l’équipe va être difficile, voire impossible.
Choisissez un bon cadre flow. Et si vous ne savez pas lequel choisir, partez sur un existant.

Vous éviterez :d

  • L’abandon d’utilisation des branches
  • La perte de code non voulue
  • Les conflits trop nombreux
  • Du code en production, non testé, non souhaité.

6 – Faire des Pull / Merge requests trop grosses

Vous avez bien respecté le cadrage Git que vous avez choisi. Vous avez par exemple choisi Gitlab flow, ou bien Github flow ?
Vous savez donc que l’une des pièces maitresses de ce type de cadrage est la PR/MR (Pull / Merge Request).

Or, vous vous retrouvez à en créer des trop volumineuses.
Elles contiennent trop de commits, représentent trop de temps de développement.

Pourquoi ce n’est pas une bonne pratique ?

Comme le vieux sage dit : Mieux plusieurs petites qu’une très grosse. Et cet adage est présent partout en informatique ! 😀

Vous allez ainsi pouvoir très rapidement avoir le retour de la communauté sur votre code à pousser.
Les conflits seront courts et plus simples à résoudre !
Et en plus, vous allez favoriser la création d’une histoire de votre projet.

Saviez-vous par exemple que vous pouvez créer une PR/MR juste pour échanger avec vos collègues ?
Et oui, elles ne servent pas qu’à fusionner son code dans une autre branche ! 🙂

Votre équipe ?

Besoin de plus de cohésion !

Vos équipes peinent à se former ?

Vous souhaitez passer à l'étape supérieur pour vos projets ?

Plus de qualité, de plus de cohésion technique, d'équipe ?

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici