loading

JohnnyBEHAGUE

Télécharger mon CV

Débuter avec Git : Le flux de travail

Vous commencez votre projet, votre répertoire Git est prêt, votre hébergement est prêt, mais il manque quelque chose… une organisation! Comment allez-vous organiser votre travail pour ne pas polluer votre historique et être plus efficace dans la gestion de vos branches lors de vos mises en production ? Certains y ont déjà pensé, et plusieurs flux se dégagent des autres.

Git Flow

Pour Gitflow, nous avons plusieurs branches qui vont se démarquer :

  • la branche master est notre branche mère. Elle doit être toujours livrable pour une mise en production
  • la branche develop contient le code de la version en cours de développement, qui doit être également stable (par exemple pour une démonstration auprès du métier de l’avancement)
  • les branches feature sont les branches qu’un développeur va créer lorsqu’il va vouloir ajouter des fonctionnalités. Une fois que sa fonctionnalité sera testée et validée en Pull Request, la branche sera fusionnée dans develop puis détruite.
  • les branches release sont les branches qui vont représenter les différentes versions de notre application. Lors d’un passage en recette par exemple, on peut créer une branche release : les développeurs pourront travailler sur la version suivante de l’application dans develop, et si un bug est déclaré par la qualification il suffira de créer un fix sur la branche release.
Pour plus d’informations sur Gitflow, n’hésitez pas à lire ce ticket Xebia!

Github Flow

Vous pensez peut-être que le Gitflow est trop complexe et pas adapté à votre besoin ? Le GithubFlow devrait vous rendre heureux!

Comme vous pouvez le voir ici, tout est plus simple! Il n’y a déjà plus de branches develop et release, et ça simplifie la vie.

  • On a toujours la branche master : tout ce que contient master doit être livrable!
  • On a toujours nos branches feature lorsqu’il faut créer un ajout de fonctionnalités. Lors d’une Pull Request, elle sera fusionnée sur master (et non sur develop) et supprimée.
  • A chaque modification de master, un déploiement peut (et doit) être fait!

Ce flux met en avant la puissance de l’intégration continue, et dans des projets personnels où on n’a pas de date de production prévue et que le développement est continue, cela est un gain de temps considérable!

Présentation du Github Workflow par Github

Leave a comment