Trabalhamos da seguinte maneira em nossa equipe:

nós temos apenas ummaster branch em nosso repositório do GitHub, não é estável - acha que é empurrado para lá todos os dias; para versões estáveis, usamos tags (para desenvolvimento, usamos garfos privados no GitHub)nós lançamos uma nova versão menor a cada 3 semanas, que contém correções de bugs e novos recursos (digamos 1.2.4, 1.2.5, 1.2.6 ...)nós também temos que manter cada versão antiga menor por um tempo limitado (alguns meses), então quando alguém usa 1.2.4 enquanto a versão mais nova é 1.2.7, e eles encontram um bug, eles podem nos solicitar para corrigir o bug no ramo que eles usam. Então nós lançamos umversão patch1.2.4A.os patches são bastante excepcionais. Geralmente, não fazemos mais que 1-2 remendos para o lançamento menor. Para a maioria das versões, não fazemos patches.

A questão é: qual é a melhor estratégia para corrigir o bug no master e no branch antigo ao mesmo tempo?

Eu posso pensar nas duas principais estratégias:

Corrigir o bug nomastere depois checkoutv1.2.4, entãocolher cerejas o commit apropriado (suponha que o bugfix seja um commit que sempre é válido) e marque o commit resultante comov1.2.4A.

Confirav1.2.4, corrija o bug e confirme, marque o commit comov1.2.4Ae incorporá-lo amasterfaça umfundir.

Sou bastante a favor da primeira versão (cherry-picking), mas gostaria de ouvir os comentários do outro sobre prós e contras.

É claro, as coisas podem ficar complicadas quando os commits no meio introduzem algumas mudanças importantes que podem resultar no fato de que não é possível criar um commit que funcionará tanto no 1.2.4 quanto no master (por exemplo quando algum nome de função mudou ou coisas mais complicadas). Mas a situação mais comum é que a correção pode ser portada sem problemas.

Vantagens da escolha de cereja do mestre:

Eu acho que a história é mais "comestível" com cherry picking. Considere isto:

| <- bugfix done on master
|
|
| <- v1.2.7
...
|
|
|
|
|
|
|
|
|
|  - <- v.1.2.4A (cherry-picked from master)
| / 
| <- v1.2.4

vs isso:

| <- bugfix merged to master
|\ 
| \
|  |
|  |   <- v1.2.7
...
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  - <- v.1.2.4A (direct bugfix)
| / 
| <- v1.2.4

Pense em ter dezenas de commits no meio. Considere ter vários patches aplicados assim em paralelo. Metade da tela será poluída.

Digamos que eu consertei um problemav1.2.4, mas em alguns dias alguém me pede um patchv1.2.3. Cherry-pick é a maneira mais sensata de fazer isso.

Existe alguma vantagem de se fundir no nosso caso que eu negligenciei? Eu posso entender que preserva a conexão entre os dois commits melhor do que o cherry-picking, mas nós mantemos uma documentação de lançamentos e tudo isso também é rastreado lá.