Après les 5 mauvaises pratiques qu’on peut trouver dans Git (http://evanboissonnot.fr/les-5-1-erreurs-les-plus-communes-dans-lutilisation-de-git/), il est temps de passer du côté lumineux de la force, vous ne pensez pas ?!
Nous allons ici retrouver des bonnes pratiques dans Git, certaines sont le côté pile du dernier article, d’autres des ajouts essentiels pour bien réussir à créer un socle fondamental de cohésion technique dans l’équipe (http://evanboissonnot.fr/cultiver-la-cohesion/).
Concevoir votre projet Git comme un voyage, une aventure
Imaginez votre projet Git, votre travail comme un voyage, direction vos vacances. Intéressant de le penser comme ça, non ?
L’idée ici, en pensant voyages, c’est de se focaliser sur trois points :
où je vais : le but, l’objectif, la vision de notre voyage
ce que je souhaite me rappeler de mon voyage d’ici 6 mois, 1 an, 10 ans
comment je vais pouvoir raconter mon voyage à mes amis, ma famille
Utilisez les commits Git pour marquer les étapes de vos voyages
Quand on part en voyage, on prend bien souvent un ou plusieurs appareils photos.
Ici, dans notre projet, Git est notre appareil photo.
CHAQUE PHOTO PRISE MARQUE UNE ÉTAPE DE NOTRE AVENTURE.PLUTÔT QUE DE DIRE À SES AMIS, ALORS LÀ TU VOIS, HEU J’AI FAIT … AH FLÛTE JE ME RAPPELLE PLUS.C’EST PLUS SYMPA DE POUVOIR DIRE : J’AI D’ABORD VU LA TOUR DE PISE, PUIS JE SUIS ALLÉ MANGER JUSTE À CÔTÉ, ..ET SURTOUT DE POUVOIR LE DIRE, 10 ANS APRÈS !
Vos commits sont vos photos dans votre code, ce n’est pas un simple moyen pour envoyer une archive de votre code sur github, gitlab.Faites autant de commit que vous avez envie de raconter d’étapes.
Bichonnez le nommage de vos étapes
OK, vous committez fréquemment, de manière unitaires et vos messages ressemblent à « commit » ou bien « écriture de code », … ?
Imaginez-vous dans votre voyage, durant votre voyage, tout est ok vous vous rappelez de ce que vous avez fait dans la journée. A peu près … De ce que vous avez fait hier … et si votre voyage est un roadtrip d’un an ?
Un projet de développement c’est la même chose : vous partez pour un long voyage.
Pensez à bien nommer vos messages de commits. Indiquez :
le type de commit (bug, feature, refacto, …)
un titre rapide qui résume le commit
un contenu qui détail ce qui a été fait.
Et si vous avez envie de vous cadrer encore plus, utilisez : commitizen (https://github.com/commitizen/cz-cli) par exemple.
Tentez plusieurs aventures en même temps avec les branches Git locales
Des fois, dans un voyage, un roadtrip par exemple, on peut hésiter entre deux chemins : partir sur cette route, ou sur une autre.
Oui mais une fois qu’on part, on part vraiment. Est-il possible de revenir sur l’ancien chemin ?
D’une certaine façon oui, mais ça prend du temps.
Avec Git, vous allez pouvoir aller encore plus loin que tester deux chemins !
Plutôt que tout tester sur le même chemin : mieux vaut privilégier l’essai / erreur :
je crée une branche locale depuis mon dernier commit
je teste mon idée dans cette branche
si c’est ok, je fusionne (ou rebase) dans ma branche parente.
ça ne me plait pas : je supprime la branche
Et ainsi, on a une aventure, où l’on peut tester plusieurs aventures en même temps !
Et capitaliser à fond sur tout ce que l’on apprend, teste !
Rapportez vos souvenirs de la bonne manière : Rebase ou Merge
Bon, c’est décidé, vous voulez tester Tokyo, et Kyoto, et revenir à l’aéroport pour voir le meilleur chemin à prendre.
Dans le futur, vous voulez voir quoi : que vous avez tenté Tokyo, et tenté Kyoto, ou bien que vous avez fait Tokyo puis Kyoto sans parler de cette hésitation, de ces choix ?
Voilà toute la différence entre un merge et un rebase (https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Rebaser-Rebasing) !
Des bons réflexes sont à adopter, et surtout le plus important : que tout le monde face de même dans l’équipe.
A retenir :
on va faire des merge quand ce sont des fonctionnalités impactantes, du code commun
vous allez créer un rebase d’une branche local (https://delicious-insights.com/fr/articles/bien-utiliser-git-merge-et-rebase/) vers une branche commune par exemple.
Concevoir votre projet Git comme un voyage collaboratif
En plus d’un voyage, un roadtrip super sympa seul, votre projet Git peut aussi devenir un voyage collaboratif !
Ca va amener plein de réfléxions :
on part tous ensemble, oui mais chacun peut aller dans un pays différent ?
si on s’arrête dans une ville, comment on fait pour alimenter l’histoire de notre voyage facilement ?
si deux collègues sont dans la même ville, comment on gère ça ? et en plus, si c’est pas en même temps ?
Capitalisez ensemble votre travail avec les pushs
Pour continuer à raconter une belle histoire, toutes et tous ensemble, vous allez devoir utiliser un moyen de partage des infos découvertes, des lieux sympas, des moments fun, …
En projet avec Git, c’est la même chose ! Et le plus important est que vous partagiez assez souvent pour que tout le monde soit au courant. Pas trop souvent quand même, sinon, ça peut vite devenir lourd, et/ou amener de la confusion dans ce qu’il se passe.
Utilisez donc des pushs, pas à chaque commit, à minima une à deux fois par jour, ou sur demandes de vos collègues.
Cadrez les échanges de votre voyage avec Git
Si chacun part dans une ville différente, un pays différent, vous faites comment pour que tout soit clair ? Sans cadrage avec vos amis, votre famille, ça va vite partir en cacahuète ce roadtrip à plusieurs
Dans Git, nous allons utiliser les branches partagées, et donc choisir un cadrage (flow) Git (http://evanboissonnot.fr/comment-bien-choisir-son-flow-git-pour-son-projet-de-developpement/) adéquat à notre projet (à notre voyage).
Faites des propositions collaboratives avec les PR/MR
Voilà, le roadtrip est lancé, et ça commence plutôt bien ! Et puis, arrive le moment du choix de nouvelles villes, de nouveaux pays. Et puis, des idées de balades en kangourou arrivent alors que d’autres s’y refusent, … bref vous voyez le topo ! Et puis, certains ont déjà visité Moscou et veulent nous partager ce qu’ils-elles ont vu.
Bien utilisées, et fréquemment, les PR/MR, alias Pull Request / Merge Request (https://support.atlassian.com/bitbucket-cloud/docs/use-pull-requests-for-code-review/), c’est essentiel dans Git en collaboratif !
Utilisez-les pour :
sécuriser le code commun du projet : qualité de code, norme, …
s’assurer que le fonctionnel a bien été compris
travailler à plus que 10 dans un projet
Et en plus, priviligiez les échanges à travers une Pull Request, quand vous avez un doute sur ce que vous avez fait. Vous faites une proposition de code, et vos collègues peuvent argumenter, valider, ou refuser.
Profitez des mêmes expériences, réellement
Bon là, c’est presque de la science-fiction Imaginez, un-e de vos ami-e-s est parti-e voir Sao Paulo et vous souhaitez pouvoir vivre ce qu’il-elle a déjà vécu. Impossible, n’est-ce pas ? Même en regardant une vidéo, ce n’est pas la même chose que le vivre vraiment …
Bon Ok, prenons un autre exemple : et si votre ami-e avait créé tout un sentier super intéressant, tout un itinéraire, spécial, caché. Vous arrivez à votre tour dans la ville, et vous ne souhaitez pas trouver / construire vous aussi cet itinéraire ? Comment faire ? Il-elle vous envoie un mail, non ?
Sous Git, une bonne pratique, enfin, est de profiter des cherry-picks, souvent peu utilisés !
Ils vous permettent de récupérer du code d’un autre commit, d’une autre branche, et de le rajouter dans votre code courant ! Pratique, et pas besoin de recréer le code vous même…
