Por que não cometer alterações não resolvidas?

15

Em um VCS tradicional, posso entender por que você não envia arquivos não resolvidos porque pode quebrar a compilação. No entanto, não entendo por que você não deve enviar arquivos não resolvidos em um DVCS (alguns deles impedirão você de confirmar os arquivos).

Em vez disso, acho que seu repositório deve ser bloqueado de push e puxando , mas não comprometendo.

Ser capaz de confirmar durante o processo de mesclagem tem várias vantagens (como eu vejo):

  • As alterações reais de mesclagem estão no histórico.
  • Se a mesclagem for muito grande, você poderá fazer confirmações periódicas.
  • Se você cometer um erro, seria muito mais fácil retroceder (sem precisar refazer toda a mesclagem).
  • Os arquivos podem permanecer marcados como não resolvidos até serem marcados como resolvidos. Isso evitaria empurrar / puxar.

Você também pode ter um conjunto de conjuntos de alterações agindo como a mesclagem em vez de apenas um único. Isso permitiria que você ainda usasse ferramentas como git rerere .

Então, por que se comprometer com arquivos não resolvidos desaprovados / prevenidos? Existe alguma outra razão além da tradição?

    
por Explosion Pills 10.10.2012 / 15:34
fonte

7 respostas

6

O maior problema que eu vejo é que ele cria uma janela de commits onde as coisas são meio mescladas e (provavelmente) não funcionam corretamente. Quando você envia o último conjunto de commits locais, todos os commits intermediários também aparecem para todos os outros. No mundo ideal, eu deveria ser capaz de puxar qualquer commit e o código deveria funcionar. Se você começar a consolidar no meio das mesclagens, o estado do código não estará bem definido.

Uma coisa que você pode fazer é fazer commits locais para a sua mesclagem, e depois empacotá-los em um commit grande quando você apertar (embora eu não tenha certeza de como (se?) algum vcs suporta isso). Embora isso possa gerar alguns dos benefícios que você mencionou, não tenho certeza se vale a pena a complexidade extra (já estamos lidando com uma área bastante confusa e complexa).

    
por 10.10.2012 / 16:10
fonte
3

Estou mais familiarizado com o Git, por isso responderei por essa perspectiva.

Eu não vejo uma razão pela qual você ou qualquer bom VCS gostaria de permitir o envio de um arquivo não-mesclado, especialmente se fosse código. Você precisa manter o repositório em um estado consistente, e o que você está sugerindo violaria a atomicidade. Muitos VCS alteram fisicamente o arquivo para mostrar onde estão os conflitos - Git, SVN e CVS usam > > > > < < < < < < < digite marcadores. Em um VCS com commits e mesclagens em nível de repositório atômico, você teria criado um nó que não faz sentido para ninguém além de você. No desenvolvimento de software, seu projeto não pôde ser construído. No documento de um grupo, ninguém sabe quais alterações estão corretas.

Agora, o Git fornece algumas ferramentas que poderiam facilitar isso, se o tipo de commit sugerido fosse permitido. Você poderia esmagar tudo o que você mesclar commits juntos antes de você empurrou, por exemplo. Isso acaba sendo o mesmo que um commit típico de merge.

Preocupações específicas sobre sua lista de benefícios:

  1. As alterações reais de mesclagem estão no histórico. Por que você precisa de informações extras? Os DVCS são muito bons em limitar conflitos a áreas confinadas. Depois de escolher o conjunto de alterações a ser mantido, comparar a cópia do nó de consolidação de mesclagem com a cópia anterior fornecerá exatamente isso.
  2. Se a mesclagem fosse muito grande, você poderia fazer commits periódicos. Esta é uma preocupação válida, mas você não deveria nunca chegar aqui em primeiro lugar. Os branches devem estar constantemente fazendo alterações upstream apenas para que isso nunca aconteça. Ferramentas como rebase ou cherry-pickking com commit de cada vez também podem ajudá-lo aqui em algumas situações.
  3. Se você cometer um erro, seria muito mais fácil retroceder (sem precisar refazer toda a mesclagem). Veja acima - seus conflitos não devem se tornar tão difíceis de gerenciar.

A única maneira que essa sugestão poderia funcionar é se a ramificação era se toda a mesclagem fosse atômica - você poderia ver uma série de commits, mas eles seriam meros passos em um commit maior de merge que tinha que ser tratado como um node em a árvore de confirmação. Eu não acho que qualquer VCS atual tenha suporte para esse tipo de fluxo de trabalho, e não acho que seja necessário.

    
por 10.10.2012 / 16:19
fonte
1

Minha principal experiência é com o Mercurial, embora eu também use git esporadicamente.

O Mercurial não permite que você envie arquivos não resolvidos, apenas desencoraja você . A mesma coisa que empurrar antes de fazer alterações que você não tem.

Tudo o que você precisa fazer no Mercurial é, uma vez que você tenha os arquivos da maneira que deseja cometer:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

- mark marcará os arquivos como resolvidos sem avisar sobre a ferramenta de mesclagem. --all cuidará de selecionar todos os arquivos marcados com conflitos.

Se você quiser empurrar sem puxar (e consequentemente ter que mesclar as alterações dos outros) faça como um Jedi :

hg push --force

O próximo cara que puxar receberá uma cabeça +1 (sem trocadilhos)

Tenho certeza que existe uma maneira de fazer o mesmo com o Git (embora provavelmente seja mais complicado).

    
por 10.10.2012 / 21:37
fonte
1

Quando eu mesclo no git, eu imediatamente confirmo todas as alterações (incluindo os conflitos de mesclagem). Então, no meu próximo commit (s), eu resolvo os conflitos de mesclagem através de um editor de texto. Depois que os conflitos são resolvidos, eu então empurro se desejar.

Honestamente, não entendo por que os outros não o fazem assim, ou o git não o impõe.

  • A "consolidação de mesclagem" agora é um histórico limpo de exatamente o que precisava ser mesclado.
  • As seguintes confirmações mostram exatamente o que você fez para resolver os conflitos de mesclagem.
  • Quando você pressiona, os conflitos são resolvidos e a compilação é interrompida na ponta da ramificação.
  • A qualquer momento, se você estragar a resolução de conflitos, basta reverter para uma das confirmações "pós-mesclagem" e tentar novamente.

Uma grande desvantagem do fluxo de trabalho padrão de resolver conflitos antes de confirmar é que as alterações da sua cópia local podem entrar. As adições são ocultadas da revisão de código pelo diff de mesclagem massivo, Não perceba que você acidentalmente cometeu uma chave de API ou etc.

Meu fluxo de trabalho descrito acima evita esse problema de cópia local e também permite que os revisores de código examinem (apenas) os detalhes de sua resolução de mesclagem em um diff de consolidação que se parece exatamente com um diff de confirmação padrão.

    
por 19.02.2016 / 09:33
fonte
0

Eu acho que é melhor empurrar pequenas mudanças e apertar frequentemente, quando é possível (e é claro que nem sempre é), e não comete código que não constrói, ou é meio completa (todos cometemos erros, mas não fazemos isso de propósito). Eu também venho do git, e uma das melhores coisas que eu acho é que você pode ter uma cópia viável do repositório em sua área de trabalho ... que você pode modificar para o conteúdo do seu coração. Quando suas grandes mudanças forem concluídas, envie-as.

Fazer um monte de código aberto com git a maior frustração para mim foi obter metade do código colocado no repositório, e tentar fazer uma compilação, mas não conseguiu, porque o cara fez metade do trabalho e disse "eu" estou ocupado agora, vou terminar em uma semana ". Então eu acabaria tendo que desfazer isso (o que incomodaria o cara), ou ter tempo para terminar e integrá-lo completamente.

Eu acho que, do meu ponto de vista, manter as coisas da metade da bunda localmente, enviar as coisas boas pelo fio.

    
por 10.10.2012 / 19:21
fonte
0

Não seja escravo das suas ferramentas.

O objetivo de um VCS é permitir que você faça o seu trabalho. Seu trabalho não é para manter um repositório local novo, seu trabalho é escrever código. Se se comprometer cedo e com frequência localmente permitir que você trabalhe melhor, faça isso.

Você não deve, no entanto, empurrar o código quebrado para o upstream.

    
por 10.10.2012 / 20:41
fonte
0

Porque, fundamentalmente, é uma má ideia - isso o levará a um repositório que está em estado lastimável (e é precipitado supor que você vá para algum lugar, embora alguém argumente que você sempre deve ter pelo menos uma cópia ).

Eu posso ver que, no caso de uma fusão grande / complexa, você pode querer salvar seu trabalho em andamento e estabelecer um ponto de referência, mas você ainda estaria deixando o sistema em um estado confuso que precisa ser resolvido .

E há alternativas - você tem a opção de mesclar a partir do início do que a cabeça - o que pode lhe dar a capacidade de se adaptar às mudanças sem fusões épicas (ou pelo menos com fusões maiores e mais fáceis de compreender). p>

Este é o caso que eu acho que o rebase do git é particularmente útil (sujeito às ressalvas habituais sobre rebasing) porque você está repetindo suas alterações sobre o estado atual para corrigir conflitos em partes menores.

    
por 19.02.2016 / 09:57
fonte