Partout où je cherche la bonne façon d'utiliser git en équipe, nous nous référons toujours à git-flow.
Nous avons commencé à utiliser ce schéma comme notre bible au début.
Le temps passe et nous avons finalement découvert que garder master comme branche stable avec des commits balisés était une perte de temps.
Pourquoi marqueriez-vous votre commit stable, puis PUSH pour maîtriser la même version que vous avez déjà taguée. La balise existe, vous pouvez revenir sur ce commit à tout moment. Pourquoi devrais-je prendre la peine de garder cette branche pour ne contenir que les balises?
Voici le flux que nous utilisons et cela fonctionne comme un charme.
Master: est en fait notre branche de développement Release: Nous créons une branche de version pour faire notre dernier cas de test de version puis nous ajoutons un correctif si nécessaire. Fonctionnalité: Nous partons de Master pour créer une fonctionnalité, puis nous envoyons la pull request au master.
En fait, c'est le MÊME que gitflow, sans branche contenant stable.
Un autre avantage de ceci est que MASTER est la branche DEVELOP. Ainsi, lorsqu'un nouveau coéquipier arrive dans le projet, il peut commencer par cloner le projet et son maître est déjà à jour avec le développement réel.
Dans l'image:
Ma question est la suivante: pourquoi utiliseriez-vous le git-flow original avec 5 branches si vous ne pouviez gérer que 4 branches avec le même résultat?
3 Réponses :
Le résultat n'est pas le même: en clair, le master de git-flow est toujours stable - ce sont les livrables sur lesquels les personnes extérieures à votre équipe peuvent compter. Votre master est un mélange de develop et de master dans gitflow-speak. Après avoir fusionné de grandes fonctionnalités, les paris sont ouverts, que le résultat soit vraiment stable et prêt à être expédié ou que d'autres corrections de bogues soient nécessaires.
Cela dit: les workflows Git ne sont pas donnés par Dieu. Git-flow a eu pas mal de critiques. Si votre équipe et les équipes qui s'appuient sur votre code sont satisfaites, optez pour le flux de travail avec une surcharge minimale.
Dernière remarque:
Voici le Git-Flow que nous utilisons et il fonctionne comme un charme.
Veuillez PAS appeler votre flux de travail "git-flow". Choisissez un nom clairement différent. Diluer un bon terme de recherche n'aide personne.
Je mettrai à jour ma question pour éviter d'utiliser Git-flow car ce n'est pas un flux git. merci encore pour votre réponse!
Avec la méthode de @ChristopheChenel, le code "toujours stable" est la fin des branches de publication
À mon avis, votre flux de travail a un gros problème: la surutilisation de la branche develop / master.
En gros, vous dites qu'il n'est pas nécessaire de faire la distinction entre master et develop car il suffit de garder les balises sur develop. Et cela semble raisonnable à première vue, mais l'image que vous avez modifiée cache le besoin d'une branche: le hotfix.
Supposons que vous ayez une version stable de votre code et que vous ayez déjà terminé la phase de publication. Vous pensez maintenant que tout est prêt et créez une balise sur master / develop. Après un certain temps, votre client vous fait remarquer que vous avez un bogue et que vous n'êtes pas prêt pour une nouvelle version. Que faire?
Votre seul choix est de créer une branche depuis master / develop. Ainsi, les fonctionnalités, la version et le correctif proviendront de master. Un autre inconvénient de cette approche est qu'une fois qu'un bogue a été résolu sur la branche hotfix, vous le fusionnerez dans develop / master mais vous ne pouvez pas mettre de balise sur ce commit car la branche develop / master a probablement évolué entre-temps et elle aura plus ( non testé) caractéristiques que le client ne devrait pas avoir. Je pense que c'est trop et l'historique des engagements sera difficile à comprendre à un moment donné. MAIS, comme je l'ai dit au début, c'est discutable.
Votre flux de travail semble mélanger le développement basé sur git-flow et tronc (ou master), mais en prenant principalement des inconvénients.
Je pense que cette réponse souligne le plus gros problème avec le flux proposé par la question: en combinant Develop et Master, il est impossible de déployer un correctif pour une révision précédemment publiée et étiquetée sans inclure également des éléments de développement inédits.
Pour mon correctif, si je récupère la dernière balise (version que j'ai envoyée au client), je branche un relase / version-with-the-hot-fix. Ensuite, dans cette branche, je corrige le problème. relâchez-le et envoyez la pull request pour Master (Ma branche de développement active). Il semble que de cette façon je contourne le "désavantage" ou je manque un point.
Si j'ai bien compris cela, le problème persiste: même avec une pull request, develop / master pourrait ne pas être prêt à créer une version stable avec votre correctif de bogue, surtout parce que vous devez commettre le correctif de bogue dans les plus brefs délais. En fait, c'est un choix encore pire si vous pensez que vous créez un goulot d'étranglement dans votre flux de travail. Alors qu'avec le git-flow, vous pourriez avoir une équipe develop et une équipe master , maintenant ils sont tous deux bloqués par la nécessité d'intégrer votre correction de bogue.
Dans votre exemple, que se passe-t-il si vous devez créer un deuxième correctif? Il aurait besoin d'inclure les modifications du premier correctif, plus le nouveau correctif, mais rien d'autre de master / develop. Lorsque le premier correctif est fusionné via PR, il fusionne à la tête de développement / maître à l'époque. Par conséquent, vous ne pouvez pas créer un deuxième correctif à partir de ce premier point de fusion de correctif.
Les correctifs peuvent créer une branche à partir d'une balise et, comme ils finissent par devenir des balises, le processus est exactement le même pour un deuxième ou un troisième correctif. Le processus tel que décrit fonctionne. reallifeprogramming.com/…
Un an plus tard,
Je comprends enfin la nécessité de deux branches séparées dans le flux git.
La seule raison pour laquelle vous auriez besoin du Git-flow est lorsque vous avez un CI / CD avec déploiement automatique en production via n'importe quel commit que vous faites dans la branche master.
L'année dernière, lorsque j'ai posé la question, nous n'avions pas de déploiement automatique en production. Nous pouvons donc considérer que la méthode que nous avons utilisée sans Develop / Master était ok et cela nous a fait gagner un peu de temps car nous n'avions plus à gérer une branche supplémentaire.
Puisque nous utilisons le système de pipeline (Release to production après tout commit dans Master Branch), cela donne un but à cette branche! Oui, la branche master contient la version balisée, mais le script pour un déploiement automatique dans l'environnement de production y est également attaché!
La fusion pour maîtriser se fait par un droit de l'homme? Ce même humain ne pourrait-il pas simplement démarrer directement le pipeline de déploiement sur la branche de publication?
Votre pipeline peut démarrer le déploiement en fonction des balises, plutôt que d'une branche. Votre flux de travail d'origine est bon. Rien de mal à cela. La branche master dans git flow est inutile. reallifeprogramming.com/…
Vous pourriez être intéressé par le flux de travail CPython Git . Ils n'utilisent pas de branche
developmais lemasterpour le développement et branches de support pour la maintenance à long terme de plusieurs versions en parallèle.