O histórico de versões é realmente sagrado ou é melhor refazer a versão?

Sempre concordei com o mantra ¹ do Mercurial , no entanto, agora que o Mercurial vem com a extensão rebase e é uma prática popular no git, estou me perguntando se poderia realmente ser considerado uma "má prática", ou pelo menos ruim o suficiente para evitar o uso. De qualquer forma, estou ciente de que rebasar é perigoso depois de empurrar.

OTOH, vejo o ponto de tentar empacotar 5 confirmações em uma única para torná-la mais interessante (especialmente em um ramo de produção); no entanto, pessoalmente acho que seria melhor poder ver confirmações parciais em um recurso em que alguns a experimentação é feita, mesmo que não seja tão bacana, mas ver algo como "Tentei fazer do jeito X, mas não é tão ótimo quanto Y, afinal, fazer Z tomando Y como base" IMHO teria um bom valor para aqueles que estudam a base de código e siga a linha de pensamento dos desenvolvedores.

Meu ponto de vista muito opinativo (como no idiota, visceral, tendencioso) é que os programadores gostam de rebase para esconder erros ... e eu não acho que isso seja bom para o projeto.

Então, minha pergunta é: você realmente achou valioso ter tais "commits orgânicos" (ou seja, história intacta) na prática? Ou, inversamente, você prefere ter compromissos bem organizados e desconsiderar o processo de experimentação dos programadores ?; o que você escolher, por que isso funciona para você? (ter outros membros da equipe para manter o histórico ou, alternativamente, refazê-lo).

¹ por análise do Google DVCS , no Mercurial "History is Sacred".

A história é sagrada, o presente não é. Você pode dividir sua "árvore" do DVCS em duas partes:

• O passado / histórico que contém uma visão precisa de como você atingiu o estado atual do código. Esta parte da história cresce com o tempo

• O presente em que parte você está trabalhando atualmente para fazer seu código evoluir. Essa dica na maior parte da história tem sempre o mesmo tamanho.

Todo código que você lançou ou usou de alguma forma faz parte do passado . O passado é sagrado, porque você precisa reproduzir uma configuração ou entender o que introduziu uma regressão. Você nunca deve reescrever o passado . No git, você nunca reescreve nada quando está no master: master é a parte do passado da história. No Mercurial, você tem esse conceito de fase pública que monitora a parte passada da sua "árvore" e reforça sua imutabilidade.

A parte atual do código é o conjunto de alterações em que você está trabalhando no momento. O ramo do recurso que você está tentando tornar utilizável, sem erros e adequadamente refatorado. É perfeitamente bom reescrevê- lo; é até uma boa ideia, porque torna a parte do passado mais bonita, simples e utilizável. Mercurial rastreie isso na fase de rascunho .

Então, sim, redefina se isso melhora seu histórico. O Mercurial impedirá que você atire no próprio pé se você estiver rebaseando coisas que não deveria.

Nem todos os erros são do tipo que você precisa ocultar - por exemplo, uma vez acidentalmente cometi um arquivo binário no meu repositório. A adulteração do histórico só é ruim quando a falha não está exclusivamente no próprio histórico, como arquivos confirmados que não deveriam ser.

A revisão de código é muito mais fácil quando há uma grande mudança coesa em oposição a muitas pequenas e dependentes.

Quando trabalho em um novo recurso, gosto de fazer muitas pequenas alterações em minha ramificação. Quando estou pronto para enviar o patch, recolho esses pequenos commits em um grande commit que representa todo o novo código necessário para esse recurso. É aqui que a rebase é útil.

Por outro lado, rebase não é aconselhável se os commits não tiverem nada a ver um com o outro. Várias adições de recursos devem ser confirmações separadas (e, idealmente, vêm de ramificações separadas).

Sua pergunta descreve o histórico como um conjunto de alterações ordenadas do código e pergunta se o orgânico compromete ou não a indicação de futuros leitores para o processo de desenvolvimento. No entanto, como engenheiro de liberação / integração, não costumo pensar na história como código. Estou mais envolvido com a história que minha história conta, o conhecimento institucional que ela retém e se ela me permite ou não depurar problemas rapidamente.

Eu não acho que os fluxos de trabalho orgânicos façam isso bem, até o meu. As qualidades que eu valorizo ​​no DVCS ao codificar - filiais baratas, confirmações rápidas, salva no controle remoto cedo e frequentemente - não são o que eu valorizo ​​como gerente de integração da minha empresa . I edição git rebase, git merge, git diff, e git applymuito mais freqüência nesse papel do que git addou git commit. Ferramentas como rebaseme permitem transformar o código que recebi de algo que funciona em algo que pode ser mantido.

Confirmações ilógicas ou vagas não são úteis, mas são pecaminosamente fáceis de escrever organicamente, quando a principal preocupação é fazer o código funcionar, não distribuí-lo para outras pessoas. Compromete-se Case 15: Fixed a problemou Refactored <cranky legacy feature>faz minha auto-manutenção se encolher, mesmo quando eu os autor. Nenhum, no entanto, induz a raiva do blecaute como confirmações "incrementais". Considere este ramo de tópico que um desenvolvedor me entregou outro dia:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Essas coisas são más. É como o DVCS projetado para o Dr. Faustus. Eu darei a você controle de fonte rápido e fácil. Você me dá a alma do seu mantenedor de código. Todos os compromissos preguiçosos são atos egoístas. Muitos de nós os escrevemos, mas também devemos ao nosso futuro uma história lógica, replicável e depurável. Não podemos fazer isso sem uma maneira de fazê-lo rebase.

Quanto às experiências fracassadas, por que não descrevê-las em nossas mensagens de confirmação (recém-intocadas)? Daqui a um ano eu não preciso de um trecho pela metade. Eu só quero um registro da tentativa abortada, e talvez uma breve explicação, se me achar tolo o suficiente para tentar novamente. Existem muitos fluxos de trabalho bem-sucedidos no mundo, mas estou lutando para pensar em qualquer motivo para conscientemente comprometer o código quebrado em uma base de código de produção.

Nada deve ser sagrado, mas verifique se você tem boas razões para o que está fazendo. O rebaseamento é extremamente poderoso quando usado adequadamente, mas, como em qualquer ferramenta poderosa, pode ser confuso e causar problemas se usado de forma descuidada.

Pessoalmente, acho muito útil refazer uma ramificação de recurso local contra o tronco (ou ramificação de desenvolvimento principal) antes de executar os testes finais e mesclar o recurso na ramificação principal. Dessa forma, eu consigo lidar com quaisquer conflitos de mesclagem etc. antes de realmente me fundir.

IMHO, experimentos geralmente pertencem a prateleiras ou filiais temporárias, não linhas de base. Se você seguir isso, não deverá haver um problema, pois todos os commit serão logicamente válidos e agregarão algum valor.