Por que os DVCSes parecem todos ter uma fobia irracional de alterações não confirmadas?


10

Vindo de um plano de fundo do SVN, uma das coisas mais difíceis de se acostumar ao trabalhar com sistemas DVCS é a maneira como todos parecem considerar qualquer mudança não confirmada como uma bomba-relógio.

No Mercurial, se você tentar buscar alterações e tiver alguma alteração não confirmada em sua cópia de trabalho, precisará passar por bastidores para conseguir que apenas as alterações recebidas sejam mescladas. Tente alternar ramificações? Isso forçará você a arquivar tudo e, em seguida, você deverá desmontar tudo do outro lado. (O SVN não tem problemas com nenhum desses cenários.)

Git é da mesma maneira. Estou trabalhando lado a lado com outro desenvolvedor em um projeto e apenas tentei escolher um de seus commits no meu fork. Ele se recusou a me deixar porque eu tinha alterações não confirmadas em minha cópia de trabalho, em arquivos completamente diferentes dos que foram alterados em seu commit. Não há nem uma opção de mesclagem; aparentemente eu tenho que esconder minhas alterações primeiro!

Se uma pessoa tratasse algo completamente inofensivo com tanta cautela, eu chamaria isso de "fobia", um medo irracional que deveria ser considerado um distúrbio mental. Mas Git e Mercurial foram projetados por duas equipes diferentes de desenvolvedores inteligentes e racionais, então eu tenho que me perguntar se eles sabem de algo que eu não conheço.

Existe uma razão técnica que justifique essa atitude em relação a mudanças não confirmadas? E se sim, por que o problema em questão parece existir apenas nos DVCSes?


7
Não é o ponto principal dessas coisas que você pode verificar em sua filial local trivialmente? A fusão do outro desenvolvedor torna-se uma mesclagem real, em vez de tentar resolver três fontes (sua versão, suas alterações, a versão deles). Não sou especialista nesta área, portanto, pode estar fora da base.
Telastyn 16/09/15

3
Eu concordo com Telastyn. Acho que o motivo pelo qual você encontra restrições aparentemente irracionais é porque não está usando o Git de maneira idiomática. Um dos principais pontos fortes do Git é que você pode se comprometer localmente. Se eu tivesse que mesclar o código de outra pessoa na minha cópia de trabalho, eu com certeza iria confirmar primeiro localmente. As confirmações locais são baratas, fáceis de limpar e uma incrível rede de segurança. Não é surpresa que os fluxos de trabalho do Git giram em torno dele (e, consequentemente, os avisos e restrições pressupõem que você prefere confirmar do que trabalhar em arquivos não confirmados).
MetaFight 16/09/2015

3
@Telastyn: Não, você não pode, porque um check-in - mesmo para sua filial local - exige um motivo de confirmação e cria um registro no histórico. Portanto, se você fizer o check-in de algo que ainda não estava pronto para ser confirmado, eventualmente, quando estiver pronto para enviar alterações ao repositório remoto, esse histórico estará presente, a menos que você realize operações adicionais para reescrever o histórico. Isso não se encaixa em nenhuma definição de "trivial" que reconheço e me parece muita complexidade extra sem nenhum benefício articulável.
Mason Wheeler

Realmente? "XYZ estabilizado para mesclar do main" é um fardo ou vai para uma história excessivamente educada?
Telastyn 17/09/2015

1
Você enviaria um artigo para publicação sem pelo menos editar para maior clareza? Em seguida, não envie sua série de confirmação do primeiro rascunho para publicação. Faça a todos que lerem seu código um grande favor: volte e produza a série de commit que você escreveria se tivesse a previsão de fazê-lo dessa maneira em primeiro lugar. Rebase interativo não é difícil ..
jthill

Respostas:


4
  1. No mundo DVCS, os commits são baratos e a história é mutável. O WIP pode ser "sujo", como você deseja: e não vejo nenhum motivo contra "descartar meu estado atual no changeset para armazenar"
  2. O histórico do SVN é linear, portanto - você deve mesclar seus rascunhos com as alterações das novas revisões. O DVCS usa DAG (nativamente) e cabeça adicional (commit + pull + up) para histórico divergente é mais segura do que mesclar o diretório de trabalho modificado em tempo real com alterações externas obtidas
  3. Ao alternar (para algum nó ) o WC modificado no Subversion, você se livra de uma possível mesclagem adicional (ao contrário de "confirmar com o antigo" - "alternar" - "mesclar 1 intervalo de rev.") ... e sabemos: mescla no SVN não são o lado perfeito da ferramenta, embora não seja um problema para os DVCSes

Currículo

Não é uma fobia, é (por vezes dura) a aplicação de seguir de boas maneiras "cometer muitas vezes" (SVN-usuários, por vezes, têm medo deste estilo)

E, finalmente, hg qnew|qpop|qpushé um pequeno preço justo pela organização e ordem


1

Quando você mescla ou seleciona cereja git, você está criando um commit imediatamente. A operação não será concluída até que a confirmação seja concluída e faça parte do histórico.

Agora, o que aconteceria se gitlhe permitisse encobrir as alterações não confirmadas no seu diretório de trabalho? Você teria dificuldade (mais ou menos) de diferenciar entre os conflitos de alterações / mesclagem dos quais precisa cuidar da seleção de mesclagem / cereja e as alterações que você se apresentou. Além disso, seria quase impossível para você testar o que realmente está comprometendo.

Assim, forçar um diretório de trabalho limpo para situações de mesclagem ajuda a manter as coisas simples e gerenciáveis. Afinal, tudo o que você precisa fazer é ocultar suas alterações não confirmadas antes da mesclagem e descompactá-las posteriormente. Observe que no fluxo de trabalho

git stash
git pull
git stash pop

você tem duas (!) operações de mesclagem. Um que mescla sua última confirmação com as alterações recebidas e outro que mescla suas alterações não confirmadas com a confirmação de mesclagem resultante. Dessa forma, você só precisará mesclar duas coisas em uma, evitando a confusão que resultaria da tentativa de mesclar três coisas em uma em uma única operação enquanto tentava ignorar essas três coisas. O git stash/ git stash poptorna fácil e explícito que você esteja ignorando as alterações não confirmadas para a mesclagem.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.