Comment git va vous aider dans la cohésion de votre équipe ?

0
622
Comment git va vous accompagner dans la cohesion de votre equipe

Vous aller démarrer un projet de développement, ou bien vous en reprenez un. Et vous vous demandez comment bien suivre votre projet, l’historique, le code mis en place. Comment avoir un outil de suivi de vos sources qui favorise la pérennisation de votre projet IT ?

Git, un outil adapté pour la réussite de votre projet

Faire son choix

Dans le monde des outils de suivi des sources, il en existe beaucoup, des anciens, des plus jeunes.
Citons svn, ou bien mercurial par exemple.

Et l’un de ceux qui ressort le plus, qui a l’air le plus adapté, c’est git. Et ce n’est pas pour rien !

Comment choisir votre gestionnaire de source ?

  • Centralisé / décentralisé ?
  • Une communauté est-elle présente ?
  • Interface graphique ou non ?

Il est clair que c’est une question qui est très présente, et ça va faire partie des critères pour la réussite de votre projet !

Décentralisé, Git et Mercurial, le bon choix

La différence majeure entre git, mercurial et svn, c’est la notion de décentralisation (distributed) de la gestion des sources.

En résumé : il s’agit d’un moyen d’avoir un répertoire de suivi des sources en local, sur la machine de chaque développeur, développeuse, et d’avoir la possibilité de le connecter à un répertoire de sources distant.

Et déjà là, c’est une force extra-ordinaire, un avantage certain !

Pourquoi ?

  • Chaque développeur, développeuse, va pouvoir archiver chaque étape de son travail, en local, sans être dépendant-e du serveur centralisé : gain de temps, pas de dépendance de réseau
  • Au lieu de tout déposer directement sur le serveur centralisé, les bugs, le code à retravailler pour plus de propreté, peut être corrigé directement en local : gain de temps lors des mises en commun, un historique commun de projet plus clair, donc une plus forte cohésion technique et de l’équipe
  • Au lieu de lancer les tests de vérification à chaque archivage, sur le serveur, on peut les lancer, en local, sur sa machine. Et archiver sur le serveur après coup : code plus robuste, réactivité améliorée de l’équipe !

Git, le gagnant ?

Alors Mercurial, Git ? Comment bien choisir ?

En fait, ça peut dépendre de beaucoup de paramètres, de l’historique de votre entreprise, …

Cependant, il est clair qu’aujourd’hui, faire le choix de Git est une valeur sure pour la viabilité, la durabilité de votre projet. Et donc sa réussite !

  • Une très forte adhésion de la communauté pour Git. La courbe de progression est très forte.
  • Des services en ligne permettant l’intégration continue, l’échange entre développeurs et développeuses, existent, persistent et sont très appréciés par la communauté des développeurs, développeuses : github, gitlab, bitbucket.

Git, un outil adapté pour favoriser la cohésion de vos équipes

L’historique Git de code aide au suivi, au debuggage, à la connaissance de votre projet

Quelque soit le gestionnaire de sources que vous choisissez, l’historique des archivages (commit) va aider toute personne sur le projet à savoir ce qu’il s’est passé.

Avec git, l’historique va être amélioré, plus linéaire, plus clair :

Les services liés à Git favorisant les échanges dans l’équipe, même en remote

Vous travaillez à plusieurs, vous souhaitez pouvoir partager votre code, et pourtant vous avez un doute sur votre code. Vous avez besoin de poser des questions avant fusion de votre code avec l’existant commun.
Comment faire tout en gardant un historique des échanges avec votre équipe ?

Les Pull/Merge requests à la rescousse

Au moment de l’envoi de votre code sur le répertoire commun, vous pouvez proposer ce que l’on appelle une Pull Request (ou Merge request pour gitlab).

C’est un moyen très pratique de proposer un espace d’échange entre collègues du projet, en ligne, avant fusion de votre travail.

A chaque Pull / Merge Request créée, vous pouvez :

  • Inviter des collègues à relire votre code (pour plus de qualité, pour amélioration continue, …)
  • Proposer de discuter sur un point de code qui porte à controverse
  • Demander des détails supplémentaires fonctionnels, …
  • Înviter les personnes responsables (lead tech, chef de projet, …) à vérifier ce qui a été fait
exemple pull request

Un exemple est présenté sur la chaine Dev To Be curious (dédié aux développeurs et développeuses curieux, curieuses).

Organiser les projets de manière plus sûr avec les forks Git

Avec les Merge / Pull request pour échange / vérification, vous pourrez encore aller plus loin, en proposant à chaque développeuse, développeur de votre équipe d’avoir leur propre répertoire distant, tout en le connectant au répertoire commun du projet !

En réalisant un fork du projet, chaque personne de l’équipe va pouvoir isoler son travail, de manière encore plus sure.
Oui, mais attention, une isolation trop forte pourrait amener un danger pour le projet, pour sa viabilité future !

En fait, après réalisation du fork, chaque personne de l’équipe va pouvoir décider de faire également des Pull/Merge Request (PR) vers le répository (répertoire) commun !
Quel confort pour votre projet, quelle valeur ajoutée :

  • Pouvoir valider, ou invalider une proposition de mise à jour venant des projets forkés,
  • Pouvoir également commenter, échanger,
  • Pouvoir faire des revues de code,

Un autre moyen de favoriser la cohésion technique et humaine de l’équipe, des équipes de votre projet !

LAISSER UN COMMENTAIRE

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