A mesclagem de avanço rápido faz sentido para ramificações de vida curta, mas em um histórico mais complexo , a mesclagem sem avanço rápido pode facilitar a compreensão do histórico e reverter um grupo de confirmações.
Aviso : O avanço rápido não tem efeitos colaterais potenciais. Revise https://sandofsky.com/blog/git-workflow.html , evite o 'no-ff' com seus "pontos de verificação confirmados" que quebram a bissetriz ou a culpa e considere cuidadosamente se deve ser sua abordagem padrão master.
(De nvie.com , Vincent Driessen , poste " Um modelo de ramificação Git bem-sucedido ")
Incorporando um recurso finalizado no desenvolvimento
Os recursos finalizados podem ser mesclados no ramo de desenvolvimento para adicioná-los ao próximo lançamento:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
O --no-ffsinalizador faz com que a mesclagem sempre crie um novo objeto de confirmação, mesmo que a mesclagem possa ser executada com um avanço rápido. Isso evita a perda de informações sobre a existência histórica de uma ramificação de recurso e agrupa todas as confirmações que adicionaram o recurso.
Jakub Narębski também menciona a configuraçãomerge.ff :
Por padrão, o Git não cria uma confirmação de mesclagem extra ao mesclar uma confirmação que é descendente da confirmação atual. Em vez disso, a ponta da ramificação atual é encaminhada rapidamente.
Quando definida como false, essa variável diz ao Git para criar um commit de mesclagem extra nesse caso (equivalente a dar a --no-ffopção na linha de comando).
Quando definido como ' only', apenas essas mesclagens de avanço rápido são permitidas (equivalente a dar a --ff-onlyopção na linha de comando).
O avanço rápido é o padrão porque:
- ramificações de vida curta são muito fáceis de criar e usar no Git
- ramificações de vida curta freqüentemente isolam muitos commits que podem ser reorganizados livremente dentro dessa ramificação
- esses commits fazem parte da ramificação principal: uma vez reorganizados, a ramificação principal é encaminhada rapidamente para incluí-los.
Mas se você antecipar um fluxo de trabalho iterativo em uma ramificação de tópico / recurso (por exemplo, mesclo, voltarei a essa ramificação de recurso e adicionarei mais confirmações), será útil incluir apenas a mesclagem na ramificação principal, em vez de todo o intermediário confirma a ramificação do recurso.
Nesse caso, você pode acabar configurando esse tipo de arquivo de configuração :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
O PO acrescenta nos comentários:
Eu vejo algum sentido em avançar rapidamente para ramificações [de curta duração], mas torná-la a ação padrão significa que o git assume que você ... geralmente tem ramificações [de curta duração]. Razoável?
Jefromi responde:
Eu acho que a vida útil dos ramos varia muito de usuário para usuário. Entre os usuários experientes, porém, provavelmente há uma tendência a ter muito mais ramificações de vida curta.
Para mim, uma ramificação de vida curta é a que eu crio para facilitar uma determinada operação (rebasing, provável ou rápida correção e teste) e, em seguida, exclua imediatamente assim que terminar.
Isso significa que provavelmente deve ser absorvido pelo ramo de tópicos do qual foi bifurcado e o ramo de tópicos será mesclado como um ramo. Ninguém precisa saber o que eu fiz internamente para criar a série de confirmações implementando esse recurso.
De maneira mais geral, eu adiciono:
isso realmente depende do seu fluxo de trabalho de desenvolvimento :
- se for linear, um ramo faz sentido.
- Se você precisar isolar recursos e trabalhar neles por um longo período de tempo e mesclá-los repetidamente, vários ramos farão sentido.
Consulte " Quando você deve ramificar? "
Na verdade, quando você considera o modelo de ramificação do Mercurial, ele é basicamente um ramo por repositório (mesmo que você possa criar cabeças anônimas, marcadores e até ramificações nomeadas )
Consulte "Git e Mercurial - Compare e Contraste" .
Mercurial, por padrão, usa linhas de código leves anônimas, que em sua terminologia são chamadas de "cabeças".
O Git usa ramificações nomeadas leves, com mapeamento injetivo para mapear nomes de ramificações no repositório remoto para nomes de ramificações de rastreamento remoto.
O Git "força" você a nomear ramificações (bem, com exceção de uma única ramificação sem nome, que é uma situação chamada " HEAD desanexada "), mas acho que isso funciona melhor com fluxos de trabalho pesados, como fluxo de tópicos, significando várias ramificações em um único paradigma de repositório.
no-ff' com seus "pontos de verificação confirmados" que quebram a bissetriz ou a culpa.