Git poule ? Git canard ? 🤯

Hello,

Aujourd’hui, on va parler de GIT.

Git, juste pour rappel, est le gestionnaire de version de code le plus en vogue.

Il est hyper puissant...mais comme tout, il y a des bases à avoir

Je te rassure on ne va pas entrer dans le détail des commandes

On va voir une façon de faire et ses avantages.

---

Si ce n'est pas déjà fait, tu peux : 

• Découvrir notre formation sur le DevOps 

• Lire toutes les éditions précédentes de la newsletter 

---

Au programme :

• Une histoire de branche

• Quel intérêt ?

---

Une histoire de branche

Git permet un développement collaboratif.

Chaque Dev développe dans son coin des features et puis on peut tout remettre ensemble de façon sereine.

Ça marche grâce aux branches :

 

On a une branche principale 'master' (ou 'main') : c'est là que sera le code en production

On crée une branche secondaire dite de "dev" : c'est là que sera le code en phase de développement et de tests

À chaque développement (nouvelle feature ou correction de bug), on utilise une nouvelle branche.

Donc le workflow.

Je dois développer une nouvelle feature, je crée une branche à partir de Dev

Quand j'ai fini mon dev, je fais un merge de ma branche dans Dev

Je teste que tout est OK sur Dev

On fait ça quelques fois.

On se retrouve avec Dev qui est bien avancé maintenant.

Je décide que les dernières features doivent être poussées en production.

Je fais un merge de Dev dans Main/Master.

J'ai maintenant le code source dans Master qui est prêt à être déployé sur le serveur de prod.

Quel intérêt ?

Ben si tu dév sur ton projet tout seul dans ton coin, aucun intérêt, a priori. (en fait, si ca a toujours un intérêt)

Par contre, cette façon de faire est assez répandue dans les équipes.

Le fait d'utiliser les branches et les merges te permettent d'associer des actions automatiques.

Par exemple : dès qu'une demande de merge est faite sur la branche Dev, lancer les tests automatiquement. Si le résultat est OK, on peut merger, sinon c'est automatiquement refuser.

Dès que le merge est OK, déployer automatiquement le code source sur l'environnement de test

Idem pour un merge de Dev vers Main pour un environnement de production

Un outil pour faire tout ça est par exemple Gitlab

Maintenant que ce mécanisme fonctionne, on peut ajouter une notion de responsabilité

Un Dev est responsable de la branche Dev et des tests associés (tests unitaires ou fonctionnels)

Il est le seul à avoir les droits d'accepter un merge sur Dev

Un Lead Tech est responsable de la branche Main. Idem il est le seul à avoir les droits d'accepter un merge du Main.

Ça permet de limiter le risque de mettre des conneries sur la production (en théorie)

Pour aller plus loin

• Tu peux apprendre les différentes commandes GIT pour gérer les branches et les merges

• Tu peux essayer GitLab pour faire gérer tes projets selon cette méthode même si t'es seul

• Tu peux regarder d'autres méthodes (sur des projets Open Source sur GitHub par exemple)

Conclusion

GIT ça permet de faire plein de choses. Mais commencer par une méthode simple te permettra de monter en compétence et même inventer tes propres workflow

Dans tous les cas, ça doit être fait dans un but : gagner du temps, automatiser, limiter les erreurs...

Voilà :)

---

Tes cadeaux pour te remercier de partager la newsletter

Pour rappel, si tu recommandes la newsletter à d’autres personnes, voici les récompenses que tu peux gagner :

• 25 recommandation → On met en avant ton profil dans un article

• 50 recommandations → Une visio de 20 min de mentoring DevSecOps avec nous

• 100 recommandations → Une de nos formations aux choix offertes

Il te suffit de cliquer sur le bouton juste en dessous pour obtenir ton lien personnalisé :

---

Voilà, c’est tout pour aujourd’hui.

On est curieux d’avoir tes retours.

1. Partage nous tes réactions en répondant à ce mail.

2. Si tu as aimé cet article, n’oublie pas de mettre un petit like ! Ça nous aide à comprendre quels sujets on dois creuser.

Passe une excellente journée et à la prochaine.