Gitflow: o acabamento do recurso não faz uma mesclagem --no-ff

Criado em 14 fev. 2011  ·  12Comentários  ·  Fonte: nvie/gitflow

Agradeço o fluxo de trabalho apresentado no artigo "Um modelo de ramificação Git de sucesso". Eu gosto especialmente do uso de objetos de commit para fusões de recursos.

Acabei de notar que o git-flow pode usar um --no-ff merge, e outras vezes não. Por que é isso? É por design?

Preciso fazer um fork do git-flow para fazê-lo funcionar com mesclagens de recursos --no-ff ou há alguma maneira de configurar isso?

Obrigado,
Scott

Comentários muito úteis

Oi Vincent,

Eu posso definitivamente entender o pensamento por trás desse design, mas acho que a escolha de se o commit de mesclagem deve ser criado deve ser ditado pelo usuário escolher iniciar um branch de recurso. Às vezes, posso fazer mudanças rápidas no branch de desenvolvimento, mas vou escolher criar um branch de recurso _especificamente_ porque quero ver o commit de mesclagem. Posso fazer apenas um único commit para um branch de recurso, mas pode não ser o que eu, como usuário, considero insignificante o suficiente para garantir a desconsideração de um commit de mesclagem explícito.

Em última análise, acho que a escolha deve ser do usuário, e acho que o usuário está expressando uma escolha diferente usando um branch de recurso em vez de fazer um rápido commit para o branch de desenvolvimento.

Quaisquer sugestões sobre onde eu possa ir na base de código para fazer essa alteração de forma privada seriam muito apreciadas!

Muito obrigado por uma ótima ferramenta!
-Scott

Todos 12 comentários

Oi Scott,

Por design, git-flow usa a opção --no-ff ao mesclar para registrar que os commits pertencem historicamente. No entanto, quando o branch do recurso contém apenas um único commit, o commit extra de mesclagem não adiciona nada e apenas complica a árvore do branch desnecessariamente. Portanto, para branches de commit único, mesclagens fast-forward estão sendo feitas como se o commit fosse feito em develop diretamente.

Saúde,
Vincent

Oi Vincent,

Eu posso definitivamente entender o pensamento por trás desse design, mas acho que a escolha de se o commit de mesclagem deve ser criado deve ser ditado pelo usuário escolher iniciar um branch de recurso. Às vezes, posso fazer mudanças rápidas no branch de desenvolvimento, mas vou escolher criar um branch de recurso _especificamente_ porque quero ver o commit de mesclagem. Posso fazer apenas um único commit para um branch de recurso, mas pode não ser o que eu, como usuário, considero insignificante o suficiente para garantir a desconsideração de um commit de mesclagem explícito.

Em última análise, acho que a escolha deve ser do usuário, e acho que o usuário está expressando uma escolha diferente usando um branch de recurso em vez de fazer um rápido commit para o branch de desenvolvimento.

Quaisquer sugestões sobre onde eu possa ir na base de código para fazer essa alteração de forma privada seriam muito apreciadas!

Muito obrigado por uma ótima ferramenta!
-Scott

É aqui que a mágica acontece: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

Não vou adicionar uma opção para fazer os branches do recurso single-commit se fundirem explicitamente com --no-ff, já que ainda não acho que isso adiciona nada (além da complexidade adicionada de outro sinalizador de linha de comando), mas sinta-se à vontade para fazer uma alteração privada se insistir nisso.

Saúde,
Vincent

Obrigado, Vincent! Agradeço o ponteiro!

melhor,
Scott

Se eu puder adicionar meus 5 centavos,

Eu gostaria muito de ter a opção de ter um commit de mesclagem, mesmo ao finalizar um recurso de commit.

Na maneira como uso o git flow, meus recursos incluem no nome o número do tíquete no qual estou trabalhando. Quando terminar um recurso, gostaria muito de ver o commit de mesclagem especificando o nome do recurso (que inclui o número do tíquete).

Isso é útil para rastrear cada confirmação até o tíquete real, sem ter que escrever o número do tíquete em cada mensagem de confirmação.

@DonGiulio Não sei se você já deu uma olhada, mas tenho certeza que a edição AVH faz o que você quer.

Obrigado, não sabia disso, vou dar uma olhada.

Também estou optando por simplesmente adicionar uma opção para ter um comportamento sem ff de commit único. Seria bom se você pudesse reconsiderar isso.

(Não tenho certeza do que mais está na edição AVH).

@nvie Posso como por quê ?! "_Eu ainda acho que não acrescenta nada_"
Eu honestamente pensei que quando muitas pessoas acreditam que ele adiciona algo e alguns pensam que não, nós adicionamos uma opção em algum lugar ou pelo menos documentamos para que as pessoas não precisem encontrar por tentativa e erro. Esta não pode ser uma decisão tão grande de se tomar!

Se o usuário se deu ao trabalho de fazer um recurso e escolheu fazer um único commit nele, isso significa que ele precisava que fosse dessa forma (digamos, para manter o histórico visual) e não empurrar para o desenvolvimento diretamente . Eu diria o contrário e ignorar o caminho que o usuário tomou não faz sentido.

Você gostaria de elaborar? Devemos concordar que, nem todo mundo pode querer ramificar um trabalho tão sólido por causa dessas pequenas mudanças.

@Mehradzie Não houve um commit neste repo em 5 anos. A edição AVH tem sido a bifurcação por algum tempo e é bastante estável. Eu não prenderia minha respiração por uma resposta aqui, muito menos uma mudança de código.

@jawshooah para ser honesto, nem
O gitflow é o que SourceTree usa para fazer seus fluxos? Estou um pouco confuso agora: D
E se assim for, posso cortar e alterar como você sugeriu para usar o trabalho de algum outro repositório!

@Mehradzie AFAIK SourceTree incorpora uma versão ligeiramente modificada da versão original da nvie. Existem pedidos pendentes para eles atualizarem para a versão AVH (veja aqui e aqui ).

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

nvaken picture nvaken  ·  5Comentários

primeminister picture primeminister  ·  4Comentários

nvie picture nvie  ·  10Comentários

keithamus picture keithamus  ·  32Comentários

ripper234 picture ripper234  ·  9Comentários