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

Em um VCS tradicional, eu posso entender por que você não cometeu arquivos não resolvidos porque pode interromper a compilação. No entanto, não entendo por que você não deve confirmar arquivos não resolvidos em um DVCS (alguns deles realmente impedem que você confirme os arquivos).

Em vez disso, acho que seu repositório deve ser impedido de empurrar e puxar , mas não de confirmar.

Ser capaz de confirmar durante o processo de mesclagem tem várias vantagens (a meu ver):

• 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ê cometeu um erro, seria muito mais fácil reverter (sem precisar refazer toda a mesclagem).
• Os arquivos podem permanecer sinalizados como não resolvidos até serem marcados como resolvidos. Isso impediria empurrar / puxar.

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

Então, por que o comprometimento com arquivos não resolvidos é desaprovado / evitado? Existe alguma razão além da tradição?

O maior problema que vejo é que ele cria uma janela de confirmações onde as coisas são meio mescladas e (provavelmente) não estão funcionando corretamente. Quando você envia o conjunto final de confirmações locais, todas essas confirmações intermediárias também aparecem para todos os outros. No mundo ideal, eu devo conseguir qualquer commit e o código deve funcionar. Se você começar a confirmar no meio de mesclagens, o estado do código não está bem definido.

Uma coisa que você pode fazer é fazer confirmações locais para sua mesclagem e agrupá-las em uma grande confirmação quando você envia (embora eu não tenha certeza de como (se?) Algum vcs suporta isso). Embora isso possa render alguns dos benefícios que você mencionou, não sei se vale a pena a complexidade extra (já estamos lidando com uma área bastante confusa e complexa).

Eu estou mais familiarizado com o Git, então responderei por essa perspectiva.

Não vejo uma razão pela qual você ou qualquer bom VCS queira permitir a confirmação de um arquivo não imerso, principalmente se for código. Você precisa manter o repositório em um estado consistente, e o que você está sugerindo violaria a atomicidade da confirmação. Muitos VCs mudam fisicamente o arquivo para mostrar onde estão os conflitos - Git, SVN e CVS usam marcadores do tipo >>>> <<<<. Em um VCS com confirmações e fusões no nível do 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 podem facilitar isso, caso o tipo de confirmação que você sugere seja permitido. Você pode esmagar tudo o que mescla confirmações antes de enviar, por exemplo. Isso acaba sendo o mesmo que um commit de mesclagem típico.

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 qual conjunto de alterações manter, a comparação da cópia do nó de consolidação com a cópia anterior fornecerá exatamente isso.
2. Se a mesclagem for muito grande, você poderá fazer confirmações periódicas. Esta é uma preocupação válida, mas você nunca deve chegar aqui em primeiro lugar. As ramificações devem estar constantemente realizando alterações upstream, para que isso nunca aconteça. Ferramentas como rebaseou escolher uma confirmação de cada vez também podem ajudá-lo aqui em algumas situações.
3. Se você cometeu um erro, seria muito mais fácil reverter (sem precisar refazer toda a mesclagem). Veja acima - seus conflitos não devem se tornar tão incontroláveis.

A única maneira de essa sugestão funcionar é se a ramificação fosse se toda a mesclagem fosse atômica - você poderia ver uma série de confirmações, mas elas seriam meramente etapas de uma confirmação de mesclagem maior que deveria ser tratada como um nó na árvore de confirmação . Não acho que nenhum VCS atual tenha suporte para esse tipo de fluxo de trabalho e não acho necessário.

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

O Mercurial não permite que você cometa arquivos não resolvidos, apenas desencoraja . O mesmo negócio com empurrar antes de fazer alterações que você não possui.

Tudo o que você precisa fazer no Mercurial é, depois de ter 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 solicitar a ferramenta de mesclagem. --all cuidará de selecionar todos os arquivos marcados com conflitos.

Se você deseja empurrar sem puxar (e, consequentemente, ter que mesclar as mudanças de outras pessoas), faça como um Jedi :

hg push --force

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

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

Quando mesclo no git, imediatamente confirmo todas as alterações (incluindo os conflitos de mesclagem). Em meus próximos commits, resolvo os conflitos de mesclagem por meio de um editor de texto. Depois que os conflitos são resolvidos, eu pressiono, se desejar.

Honestamente, eu não entendo por que os outros não fazem dessa maneira, ou o git não a aplica.

• O "commit de mesclagem" agora é um histórico limpo do que exatamente precisa ser mesclado.
• Os seguintes commit (s) mostram exatamente o que você fez para resolver os conflitos de mesclagem.
• Quando você pressiona, os conflitos são resolvidos e a construção é ininterrupta na ponta do ramo.
• A qualquer momento, se você estragar a resolução de conflitos, pode simplesmente reverter para um dos commit "pós-mesclagem" e tentar novamente.

Uma grande desvantagem do fluxo de trabalho padrão de resolução de conflitos antes da confirmação é que as alterações da sua cópia local podem se infiltrar. As adições estão ocultas da revisão do código pela enorme diferença de mesclagem, para que você não note que comprometeu acidentalmente uma API chave 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 da sua resolução de mesclagem em um diff de confirmação que se parece exatamente com um diff de confirmação padrão.

Eu acho melhor empurrar pequenas mudanças e empurrar com frequência, quando é possível (e claro que nem sempre é), e não cometer código que não seja compilado ou esteja meio completo (todos cometemos erros, mas não faça de propósito). Eu também venho do git, e uma das melhores coisas que acho é o fato de que você pode ter uma cópia viável do repositório na área de trabalho ... que você pode modificar para o conteúdo do seu coração. Quando suas grandes alterações forem concluídas, envie-as para fora.

Fazer um monte de código aberto com o git, a maior frustração para mim, foi colocar o código meio pronto no repositório e tentar fazer uma compilação, mas não consegui, porque o cara fez metade do trabalho e disse: "Estou ocupado agora , Vou terminar daqui a uma semana ". Então, acabaria tendo que descartá-lo (o que incomodaria o cara) ou tomar um tempo para terminar e integrá-lo completamente.

Eu acho que, da minha perspectiva, mantenha as coisas da meia bunda localmente, envie as coisas boas por cima do fio.

Não seja escravo de suas ferramentas.

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

Você não deve, no entanto, empurrar o código corrompido a montante.

Porque, fundamentalmente, é uma péssima idéia - ele o levará a um repositório em péssimo estado (e é precipitado supor que você vá a qualquer lugar, embora se possa argumentar que você sempre deve ter pelo menos uma cópia).

Percebo que, no caso de uma mesclagem grande / complexa, convém 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 existem alternativas - você tem a opção de mesclar antes da cabeça - o que pode lhe dar a capacidade de se adaptar às mudanças sem mesclagens épicas (ou pelo menos com mesclagens maiores e mais fáceis de compreender).

Este é o caso em que considero a recuperação do git particularmente útil (sujeita às advertências usuais sobre rebasing), porque você está repetindo suas alterações no estado atual e corrige conflitos em partes menores.