Às vezes, quando verificamos o histórico de confirmação de um software, podemos ver que existem alguns commit realmente GRANDES - eles podem alterar 10 ou 20 arquivos com centenas de linhas de código-fonte alteradas (delta). Lembro-me de que existe um termo comumente usado para esse commit GRANDE, mas não consigo lembrar exatamente o que é esse termo. Alguém pode me ajudar? Qual é o termo que os programadores geralmente usam para se referir a esse commit BIG e gigante?

BTW, está cometendo muitas mudanças todos juntos uma boa prática?

ATUALIZAÇÃO: obrigado pela discussão inspiradora! Mas acho que "código bomba" é o termo que estou procurando.

(1) Ben Collins-Sussman : "..." bombas de código ", isto é, o que você faz quando alguém aparece em um projeto de código aberto com um novo recurso gigantesco que levou meses para ser escrito? Quem tem tempo para revisar milhares de linhas de código? ... "

(2) Dan Fabulich : "A bomba de código, ou: o novato com grandes idéias ... Uma bomba de código é um patch tão grande que ninguém pode revisá-lo".

(3) Google Summer of Code: Diretrizes : "Confirme cedo, confirme com frequência ... Por favor, não trabalhe o dia inteiro e empurre tudo em uma única bomba de código . Em vez disso, todo commit deve ser independente de apenas uma tarefa que deve ser resumido na mensagem de log ".

(4) Jeff Atwood : "bombas-código ... Regra # 30: não fique escuro . ...

Nós provavelmente chamamos isso de um commit ruim . :)

Má prática

E sim, isso geralmente seria considerado uma má prática , pois tem os efeitos negativos de:

• tornando-se difícil de avaliar ,
• tornando-se difícil de entender facilmente e rapidamente a confirmação da intenção original ,
• tornando-se difícil de ver como ele impactou o código para explicitamente correção ou resolver um problema ,
• tornando-se difícil saber se a comprometer seu tamanho é devido ao ruído de outras mudanças, possivelmente, não relacionados AT não (por exemplo, pequenas limpezas ou outras tarefas).

Casos Aceitáveis

No entanto, você pode ter casos em que grandes confirmações são perfeitamente aceitáveis . Por exemplo:

• ao mesclar filiais ,
• ao adicionar novas fontes de outra base de código sem versão,
• ao substituir um grande recurso no local (embora você deva fazer isso em uma ramificação, com confirmações menores abordando diferentes partes da mudança e depois mesclando tudo de volta, para que você possa ter uma janela melhor do desenvolvimento incremental do recurso e os problemas que podem ter sido encontrados ao longo do caminho),
• ao refatorar uma API que afeta muitas classes de descendentes e consumidores.

Portanto, sempre que possível, prefira os tipos de confirmações de "ataque cirúrgico" (e vincule-os a IDs de tarefas no rastreador de problemas!). Se você tiver um motivo válido, vá em frente.

Além disso, na verdade eu não sei e acho que nunca ouvi um nome especial para um grande commit. Um monstro-commit? Um comprometimento gordo?

Atualização: A resposta de David Cary vincula-se a atores de TI notáveis ​​usando o termo "bomba de código" (o mais importante é Collins-Sussman, criador original do Subversion ). Assim (embora até agora eu não possa dizer que ouvi, muitas vezes).

BTW, está cometendo muitas mudanças todos juntos uma boa prática?

Bem, não é uma boa prática manter as alterações por um longo tempo, implementar uma variedade de recursos e correções de bugs e depois enviá-las, que é uma das maneiras pelas quais uma grande confirmação pode acontecer.

Outra maneira de isso acontecer é se uma refatoração alterar a assinatura de uma função amplamente usada e, em seguida, todas elas tiverem que ser alteradas. Isso não é necessariamente ruim, e eu não gostaria que os desenvolvedores se abstivessem de limpar o código por medo de ultrapassar algum limite.

Portanto, há mais do que apenas olhar para o número de arquivos tocados em uma confirmação.

O termo que ouvi é "chunky check-ins" . E eu não sou fã deles. Eu gosto de commits menores que garantem que nada mais seja quebrado na etapa razoável de um projeto. O grande commit geralmente está repleto de problemas que repercutem por algum tempo quando isso acontece.

Eu chamo de "commit típico do SVN" ou "amanhã é dia do release"

Por mais que eu goste do SVN, sou desabilitado pelo fato de não poder fazer confirmações locais.

EDIT: eles geralmente têm as palavras "stuff" e "beer" na mensagem de confirmação.

EDITAR NOVAMENTE: É necessário evitar o máximo de alterações, embora não necessariamente uma prática ruim. Acho mais fácil revisar uma revisão / confirmação curta e concisa. (emparelhado com uma mensagem de confirmação bem escrita, veja um exemplo ruim na minha edição anterior)

Um "pedaço de código quente e fumegante". :-)

• confirmação inicial - o projeto que não estava sob controle de revisão lançado no SVN
• refatoração - o arquiteto tem uma idéia brilhante sobre a alteração de nomes de classe de / para a Convenção de Nomenclatura Smurf ou alterou a raiz da hierarquia de pacotes
• formato do código - o arquiteto decidiu alterar o recuo do código de 4 para 3 espaços ou alterar as terminações de linha do Unix para o Windows (ou reverter)
• Confirmação de sexta-feira - Joe está sempre comprometendo sua semana inteira de trabalho às sextas-feiras às 16:30
• uuups commit - Ted excluiu por engano o diretório raiz, confirmou isso e agora ele bombeia novamente toda a hierarquia de arquivos no SVN

Geralmente, muitas pessoas tendem a realizar grandes commit usando VCS centralizado, especialmente o servidor impõe uma boa política de commit. Esse é o commit deve passar em todos os testes e os testes demoram mais tempo (mais que alguns segundos). Portanto, os desenvolvedores não querem esperar tanto tempo para confirmar várias vezes e dividir as alterações em vários pequenos commit.

E os desenvolvedores que são ecológicos para o VCS podem esquecer de dividir as alterações em vários pequenos commits. Eles só lembram de confirmar quando lançam o programa para a equipe de controle de qualidade. Pior ainda, para evitar que outros vejam o código de buggy, eles não confirmam antes de passar no teste de controle de qualidade. Por fim, eles não perceberam que haviam confirmado binários de saída, arquivos temporários e saída do vinculador, que realmente produzem "grande" confirmação.