====== Gitflow ====== {{ :fr:git_icon.png?nolink |}} GitFLow est une organisation assez répandue des dépôts Git qui permet de cloisonner les choses proprement et donc de collaborer à un grand nombre de personnes. Des outils dédiés pour Git ont été créés pour permettre une plus grande facilité de travail dans les merges, commit et passage entre les différentes branches. Si l'organisation des branches est commune à toutes les personnes utilisant le dépôt, l'usage des outils GitFlow n'est nullement obligatoire. Vous pouvez parfaitement naviguer dans un dépôt géré selon les principes de GitFLow en vous servant des outils simples de Git. Ou mixer les deux. Recourir aux outils dédiés est un choix personnel, qui ne concernera que votre dépôt local. Ils ont juste été conçus pour faciliter le travail dans une telle configuration. Si vous avez surtout besoin de savoir comment Git s'utilise "basiquement", commencez par [[fr:git]]. Et si vous voulez intégrer ce gitflow dans la logique plus vaste de Gitlab, [[https://makina-corpus.com/blog/metier/2019/gitlab-astuces-projets/|Gérer des projets avec Gitlab]] peut aussi vous servir à mieux comprendre les possibilités de Gitlab. ===== Présentation ===== GitFlow se base sur une hiérarchie de branches bien claire, qui permet d'éviter les commits intempestifs sur les branches principales. L'idée est de rendre bien clair l'ajout de fonctionnalités, et de maintenir des états stables sur les branches principales. Il existe en général plusieurs branches de base dans un projet géré selon le modèle GitFlow : * la branche **Master**, qui la version de production ; * la branche **Develop**, qui est la version instable, mais dans un sens Debian-like : ce n'est pas le bazar, c'est juste qu'elle peut parfois avoir un fonctionnement imprévu, que des bugs peuvent y apparaître ; * des branches **Feature**, qui concernent chacune l'ajout d'une fonctionnalité complexe (cela peut-être lié à une [[http://docs.gitlab.com/ee/gitlab-basics/create-issue.html|Issue]] précise, voire un ensemble). Une fois le travail achevé, on merge sur **Develop**(et cela ferme automatiquement les Issue [[http://docs.gitlab.com/ce/customization/issue_closing.html|si on commite correctement]]) * une branche **Release**, qui est une nouvelle branche, basé sur **Develop**, créée lorsqu'on pense celui-ci mûre pour une nouvelle version de production. On y commite uniquement des corrections de bugs. Une fois ceux-ci achevés, on merge sur la branche principale, **Master** ; * des branches **Hotfix** qui concernent la branche **Master**, quand un bug y a été détecté et qu'il faut impérativement y remédier rapidement. Une fois la solution trouvée, on merge la branche **HotFix** sur la branche **Master** (et on inclue le correctif dans la branche **Develop**). En image, cela donne : {{ :fr:gitflow.png?nolink |Image extraite du site http://nvie.com/posts/a-successful-git-branching-model/ © Vincent Driessen}} ===== Présentation en vidéo ===== [[https://www.grafikart.fr/formations/git/git-flow|{{ :fr:grafikart.png?nolink |}}]] Grafikart propose une vidéo de [[https://www.grafikart.fr/formations/git/git-flow|présentation de GitFlow]], comme toujours d'excellente qualité. {{youtube>ZQAQ4HcskAY?medium}} ===== Sites ressource ===== * L'article originel de présentation par le créateur : http://nvie.com/posts/a-successful-git-branching-model/ * Une présentation en français : http://www.synbioz.com/blog/git-adopter-un-modele-de-versionnement-efficace * En image (et en français), les commandes des différentes étapes : https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html#features {{tag>Données Outils}}