DEV Community

Cover image for Avec Git : Accroche-toi aux branches 🌳
OCLKA
OCLKA

Posted on

Avec Git : Accroche-toi aux branches 🌳

#french #git #webdev #tutorial

Tu bosses en solo ou en petite Ă©quipe, et c’est Ă  chaque fois la panique avec tes repos. Dans cet article, je reviens sur un flow simple, structurĂ© et largement Ă©prouvĂ©, qui va te sortir Ă  coup sĂ»r du Nether.

Baaah alors, mon lapinou...
T’arrives pas Ă  dĂ©passer ta gitophobie, hooooooooo... Tu nous fais un civet Ă  chaque fois que tu vas pousser un commit ? C’est malheureux... đŸ„č
Bon, ça tombe bien, je vais te proposer dans cet article une bonne recette pour que tu t’accroches à des branches solides.

🚹 ALERTE 🚹

Tu ne trouveras pas ici les commandes qui feront de toi un Git Guru, ce n’est pas le sujet. Ici, on parle seulement d’organisation.

Ce billet décrit une version ultra simplifée de Git Flow et n'en garde seulement que l'essentiel main, develop et des branches de features. GitFlow est parfois critiqué pour sa complexité sur les projets avec des releases fréquentes (ex : les apps mobiles). Ce workflow simplifié évite ces écueils.

Un workflow qui marche

Il existe une mĂ©thode simple pour structurer tes branches sans te prendre la tĂȘte. Pas de Git Flow compliquĂ©, pas de rĂšgles incomprĂ©hensibles. Juste un workflow efficace, mĂȘme quand ton projet ressemble Ă  un plat de spaghettis.

La structure 

main
└── develop
    ├── feat/payment-form
    ├── feat/ui-components
    └── feat/github-workflows
Enter fullscreen mode Exit fullscreen mode
Branche Rîle Rùgles d’or
main Production (toujours stable). ✅ Jamais de commit direct. Seulement des merges depuis develop.
develop IntĂ©gration (pour les features terminĂ©es). ✅ Toujours Ă  jour avec main. ✅ TestĂ©e avant merge.
feat/* FonctionnalitĂ©s distinctes. ✅ CrĂ©Ă©es depuis develop. ✅ Noms clairs : feat/login, fix/login-button, docs/specs.

Le principe

Je vais faire une analogie pour t’expliquer le principe avec des mots simples. Fais preuve d’un peu d’imagination : notre repo est un restaurant !

[đŸœïž Salle = main] ← [đŸș Comptoir = develop] ← [👹‍🍳 Cuisine = feat/fix/docs]

main : c’est la salle ou la terrasse !

C’est lĂ  oĂč se trouve le client. C’est toujours nickel-propre ! Tout s’y passe bien, tout est fonctionnel. Pas question d’y montrer quoi que ce soit de bancal, Ă  moins de vouloir perdre des ⭐. Ici, il en va de la rĂ©putation de la maison !

develop : c’est le comptoir !

C’est ici que passent tous les plats qui vont ĂȘtre servis au client (ou pas). Parce qu’il y a toujours le boss 😡 de prĂ©sent, aux aguets, et il ne laisse rien passer :

  • Est-ce que c’est bon et goĂ»tu ?
  • Est-ce que c’est conforme Ă  la demande du client ?
  • Est-ce que ça s’intĂšgre bien dans la carte ?
  • Est-ce que ça rĂ©pond au standing de la maison ?
  • Est-ce qu’on ne sert pas le dessert avant l’entrĂ©e ?
  • Blablabla... toujours lĂ  pour t’emmerder, l’patron, pffff.

feat/..., fix/..., etc. : c’est la cuisine !

  • On y prĂ©pare des recettes prĂ©sentes Ă  la carte.
  • On essaie des nouveaux trucs, des expĂ©riences culinaires qui parfois marchent et parfois non.
  • On amĂ©liore les recettes, on change des ingrĂ©dients.
  • C’est dans ces branches-lĂ  qu’on fait les foufous et qu’on se lĂąche !
  • Une rĂšgle d’or : on ne mĂ©lange pas les torchons et les serviettes, une branche par recette !

Un exemple simple

On est un petit pool de trois devs. On bosse sur un SaaS de ouf qui va révolutionner le truc.

  • Moi, je bosse sur les composants UI.
  • DaphnĂ©e, sur le workflow.
  • Et toi, sur le formulaire de paiement. 
main
└── develop
    ├── feat/ui-components       <-- Moi
    ├── feat/github-workflows    <-- DaphnĂ©e (j'la kif 💖)
    └── feat/payment-form        <-- Toi
Enter fullscreen mode Exit fullscreen mode

De mon cÎté

  1. Je viens de finaliser ma lib UI sur ma branche feat/ui-components.
  2. Tous mes tests sont au vert.
  3. J’ai bien documentĂ© mon taf.
  4. Je fais une Pull Request vers develop.
  5. Mon code passe en revue (le fameux boss 😡), tout est OK !
  6. Ma branche est mergée sur develop.
  7. Je supprime ma branche feat/ui-components et je passe Ă  autre chose.

ParallÚlement, de ton cÎté

  1. Tu bosses tranquillement sur ton formulaire sur ta branche feat/payment-form.
  2. Lorsque la mienne est mergĂ©e sur develop, tu rebase develop. Tu bĂ©nĂ©ficies ainsi de la lib UI sans rien perdre de ton taf. Magique ! đŸȘ„
  3. Tu finalises ton formulaire.
  4. Tu fais une Pull Request vers develop.
  5. Ton code passe en revue, tout est OK !
  6. Ta branche est mergée sur develop.
  7. Tu supprimes ta branche feat/payment-form et tu passes Ă  autre chose.

La suite

  1. DaphnĂ©e n’a pas fini son taf, mais ça n’a pas beaucoup d’impact sur la suite.
  2. develop est mergée sur main.
  3. Daphnée rebase develop et poursuit son taf.

Attention : Un rebase est puissant mais rĂ©Ă©crit l’historique : utilise-le seulement si tu es seul·e sur ta branche ! Si vous travaillez Ă  plusieurs sur une branche, privilĂ©gie le merge pour Ă©viter les conflits.

Pour ceux qui veulent aller plus loin : Ressources francophones :

  1. Vidéos :
  1. Documentation officielle de GitFlow (en français) :
  1. Livre gratuit :
  • Pro Git de Scott Chacon (chapitre sur les branching models, dont GitFlow).
  1. Article court et pratique :

En conclusion

Ce workflow simple t’éviteras bien des dĂ©convenues !
Alors, bien sĂ»r, il y a des edge cases, mais dans ce billet, je voulais surtout te parler de mĂ©thodologie et de principe. Si t’as un souci prĂ©cis, n’hĂ©site pas Ă  m’appeler đŸ€Ł.

Mon conseil : mĂȘme si tu bosses seul, expĂ©rimente une ou deux fois cette approche. Promis, ça va te paraĂźtre lumineux !

Je viens de me relire, je dois avoir la dalle, je parle que de bouffe !

AprÚs coup, je me dis qu'un lapinou qui s'accroche aux branches, ça commence furieusement à ressembler à un écurou (putain, c'est Pokémon ce blog !)

Top comments (0)