Description de workflow pour l'utilisation git pour le développement en interne

Question

La société pour laquelle je travaille veut avoir des versions mensuelles, et j'essaie de les convaincre de passer à git. Je crois que le bon moyen de gérer cela est d'avoir une branche d'intégration pour chaque version (c'est-à-dire mensuellement) et avoir des branches d'entités hors des branches d'intégration pour de nouveaux développements et changements. L'environnement est chargé d'interdépendances et parfois une fonctionnalité doit être reportée à un autre mois en raison de retards dans les fonctionnalités requises d'autres systèmes externes. Les projets auront généralement une activité sur 2-3 branches d'intégration en parallèle et l'activité se limitera à un groupe de personnes en contact assez étroit. (Cela signifie que je pense que nous pouvons utiliser le rebasage tant que nous sommes sur la dernière branche d'intégration, ce qui est vrai au moins la moitié du temps pour la moitié des gens)

Il y a une bonne quantité de personnes impliquées, donc je vraiment besoin de quelques directives droites de la façon de le faire, à la fois une explication logique de la structure branche/fusion et les commandes git pratique pour le faire. Est-ce que quelqu'un sait d'une telle description qui est raisonnablement bien adapté pour un tel flux de travail?

Answer 1

une explication logique de la structure branche/fusion

La structure suit essentiellement ce que vous avez dit: une branche d'intégration et les caractéristiques des branches.
Dans ce type de flux de travail, il est essentiel de comprendre, comme vous l'avez fait, que tout développement ne se fera pas à la prochaine version.
Mais avec un DVCS, il est également essentiel de comprendre qu'une branche peut être publiée et clonée.

Ce dernier point (publication) aura une grande influence sur la fusion des commandes , à savoir:

• fusion
• rebasage.

Chaque fois qu'un développeur doit fusionner son travail sur une branche d'intégration (il a tiré à partir d'un référentiel « central »), je recommande:

# switch back to previous release tag (from where feature branches for next release where done) 
$ git checkout previousReleaseTag 
# create one's own private 
$ git checkout -b myIntegrationBranch 
# merge or cherry-pick what we want to actually put in the next release 
$ git merge... from our feature branch 
# rebase that private integration branch on top of actual integration branch 
$ git rebase integrationBranch 

Le dernier rebasage va réécrire l'histoire de votre région consolidations, mais dans une branche vous ne publierez pas de toute façon (donc pas de mal fait).
Une fois que toutes vos nouvelles fonctionnalités fonctionnent, vous pouvez fusionner cette branche privée vers la HEAD actuelle de la branche d'intégration concernée. La "branche privée - fusionner ou recomposer - rebaser - résolution locale - fusionner en arrière" est un workflow nécessaire puisque plusieurs équipes devront fusionner leur travail à une branche commune. Ils ont besoin de rejouer ce qu'ils veulent publier dans une branche privée avant de le fusionner avec la branche commune, sinon chaque équipe pourrait casser ce qui est représenté par la tête de la branche commune.

Autres détails dans les questions suivantes:

• git commit frequency
• git releases management (un autre flux de fusion)
• JC Hamano articles (grâce à Jakub Narębski)