git avec des branches de développement, de mise en scène et de production

Question

Cet article semble intéressant, mais je suis presque sûr que les diagrammes sont faux. http://guides.beanstalkapp.com/version-control/branching-best-practices.html

Cela ne devrait-il pas être DEVELOPMENT > STAGING > PRODUCTION ?

Les fusions ne doivent s'effectuer que dans un seul sens : f effectuées dans leur propre branche ou dans les branches de développement Une fois testées, vous pouvez fusionner ces modifications du développement dans la branche production.

Ici, je suis un peu perdu. Donc je fusionne Staging vers Master ou Master vers Staging ?

J'utilise un client appelé SmartGit et je suis confus sur ce point. Normalement, je crée une branche pour une fonctionnalité, je fais un commit sur celle-ci, puis je passe sur master et je fusionne avec la branche (forward). Donc, dans ce nouveau workflow avec Staging et Production, je crée ces deux branches supplémentaires, puis je crée une branche à partir de master (aka dev) pour ma fonctionnalité. Je m'engage sur celle-ci, puis je passe à Staging et je fusionne (forward) avec la branche de ma fonctionnalité ? Est-ce que cela semble correct ?

---

En fait, ce qui a rendu cette situation si confuse, c'est que les gens de Beanstalk soutiennent leur utilisation très non standard de Staging (il vient avant le développement dans leur diagramme, et ce n'est pas une erreur ! https://twitter.com/Beanstalkapp/status/306129447885631488

J'ai décidé d'oublier Beanstalk et de me contenter de Github.

---

Depuis que j'ai posté ce message, les gens de Beanstalk ont suivi mon conseil et ont renommé leurs scènes, appelant désormais le développement "Stable".

Answer 1

Le processus de pensée ici est que vous passez la plupart de votre temps dans development . En cours de développement, vous créez un feature (à partir de development ), compléter la fonction, puis fusionner à nouveau dans la fonction development . On peut ensuite l'ajouter à la version finale de production en la fusionnant dans le fichier production .

Voir Un modèle de branchement Git réussi pour plus de détails sur cette approche.

Answer 2

Nous le faisons différemment. IMHO, nous le faisons d'une manière plus simple : en master nous travaillons sur la prochaine version majeure.

Chaque fonctionnalité importante obtient sa propre branche (dérivée de master) et sera régulièrement rebasée (+ poussée) sur master par le développeur. Le rebasement ne fonctionne bien que si un seul développeur travaille sur cette fonctionnalité. Si la fonctionnalité est terminée, elle sera fraîchement rebasée sur master et ensuite le master sera accéléré par le dernier commit de la fonctionnalité.

Pour éviter le rebasage/le push forcé, on peut aussi fusionner régulièrement les changements de master vers la branche feature et, si c'est terminé, fusionner la branche feature dans master (fusion normale ou squash merge). Mais, à mon avis, cela rend la branche des fonctionnalités moins claire et il est beaucoup plus difficile de réorganiser ou de nettoyer les commits.

Si une nouvelle version est prévue, nous créons une branche secondaire à partir de master, par exemple release-5 où seuls les bugs sont corrigés.

Answer 3

En fait, ce qui a rendu cette situation si confuse, c'est que les gens de Beanstalk défendent leur utilisation très peu standard de Staging (il vient avant le développement dans leur diagramme, et ce n'est pas une erreur !

https://twitter.com/Beanstalkapp/status/306129447885631488

Answer 4

L'une des meilleures choses à propos de git est que vous pouvez changer le flux de travail qui fonctionne le mieux pour vous J'utilise http://nvie.com/posts/a-successful-git-branching-model/ la plupart du temps, mais vous pouvez utiliser n'importe quel flux de travail qui correspond à vos besoins.