gestion des versions de git

Question

Je ne pouvais pas trouver quoi que ce soit, est la "bonne" méthode pour gérer les rejets à l'aide de git. Dis, j'ai de maître, relâchez-1, version-2 et dégagement-3 branches. La version 1 est déjà sorti et je n'ai fait que bugfixing et publié des versions de marquage sur elle. Version 2 va bientôt sortir et je développe principalement sur cette branche, alors que le 3 je développe des choses qui seront nécessaires dans un avenir plus lointain.

1. Lorsque je ajouter une fonction à la libération-2 et il devrait aller à 3, mais pas à 1, il faut que j':

   • fusion de presse-2 de master et de cherry-pick fonctionnalité liée commettre de presse-3?
   • cherry-pick fonctionnalité liée commettre de master et de cherry-pick pour la libération-3?
   • qqch d'autre?

2. Quand j'ai besoin de changements qqch dans toutes les versions, dois-je le faire sur le master et cherry-pick à toutes les branches?

3. Dois-je garder le à jour avec la plus récente(version-3-direction), ou plutôt le développeur de presse-3 et la fusion avec le maître juste avant, j'ai besoin de presse-4 branche?

4. Quand j'ai corrigé qqch sur la version 1 ou version-2, dois-je les fusionner ou de cherry-pick à maître ou plutôt?

Je ne suis pas tout à fait sûr de quand dois-je choisir, quand dois-je les fusionner et si le flux de la code entre les branches de ce droit.

Answer 1

Voir les posts suivants sur Junio C Hamano (git responsable) blog:

• Remplir une fusion
• Ne jamais recommencer (sur les branches fourchues avec l'intention de ne pas recommencer)
• La résolution des conflits/les dépendances entre un sujet de branches début de l'
• Du plaisir avec les branches distantes (1)
• Du plaisir avec les branches distantes (2)

Prendre aussi regarder gitworkflows page de manuel.

Answer 2

Ce que vous demandez est un exemple typique d'une fusion de workflow problème: quoi de fusion à partir d'où et où.

Mais vous devez aussi vous rappeler que, dans un DVCS, une fusion sera également l'influence par la publication des considérations (sont ces branches ont poussé à des espaces de stockage locaux, publics ou)

"maître" de la branche, en particulier, est l'un visible par défaut lorsque quelqu'un clone de votre dépôt, le sens qu'il doit faire référence à ce que vous considérez comme la plus utile à l'utilisateur/développeur. (depuis les autres branches ne sont pas référencé localement par défaut)

---

1/ Quand-je ajouter une fonction à la libération-2 et il devrait aller à 3, mais pas à 1

En effet, vous pouvez fusionner r2 pour le maître, après avoir fait un certain nombre de commits à r2 afin de réaliser les évolutions nécessaires. De cette façon, seul un nombre limité de commits sont visibles en maître, en évitant de commettre encombrer".
Pour r3 cependant, vous pouvez cerise choisir ce dont vous avez besoin à partir de r2, si r3 est poussé et publié. Sinon, vous risquez de rebase r3 sur r2. Voir "workflow git et rebase vs fusion" question

2/ Quand j'ai besoin de changements qqch dans toutes les versions, dois-je le faire sur le master et cherry-pick à toutes les branches?

Vous devriez le faire sur r2, et puis les fusionner sur le master et r1 et r3. De cette façon, un seul commit est ajouté à ces branches.

3/ dois-je garder le à jour avec la plus récente(version-3-direction), ou plutôt le développeur de presse-3 et la fusion avec le maître juste avant, j'ai besoin de presse-4 branche?

Cela dépend de ce que vous voulez que votre autre collègue pour voir quand ils cloner le repo.
Mais à partir de 1/, je rassemble maître représente r2 (en cours de développement) et pas de r3 (avenir, à long terme refactoring)

4/ Quand j'ai corrigé qqch sur la version 1 ou version-2, dois-je les fusionner ou de cherry-pick à maître ou plutôt?

• r1: cherry-pick: pas tout ce que vous êtes la fixation sur r1 est destinée à être fusionnée de développement en cours.
  En fait, je serais plutôt joyeux-pick r1 fixe sur r2, assurez-vous que tout ce travail là, et puis les fusionner sur le master.
• r2: la fusion. Si le maître représente r2, une simple opération de fusion est assez.

Answer 3

Je voudrais faire:

1) Fusion de r2 pour le maître, et le maître de r3 (r3 doit être en mesure d'accepter tous les changements de master)

2) s'Engager à r1, fusion de r2, de fusion et r2 pour le maître, et fusionner maître de r3

3) Peut-être que vous devriez utiliser le maître au lieu de r3, et seulement à développer sur la branche de r3, lorsque la publication est en cours de préparation et fusionner tous les changements ici pour maître (qui sera la prochaine version). Ou utilisez le "maître" et "suivant" de la branche de Linux.

4) Fusion de maître

Je pense que la fusion est plus propre que le cherry-picking et pense que vous devez seulement choisir quand vous avez besoin de rétroporter une fonction ou d'une correction d'une ancienne branche que vous ne vous attendiez pas lors de la validation a été faite (d'autre commit sur la branche la plus ancienne/release vous voulez le code).