Eu sou um graduado recente (como de ontem) em ciências da computação. Eu sou um grande fã de controle de versão desde que fiquei bravo com uma tarefa em que estava trabalhando e comecei do zero, eliminando algumas horas de trabalho realmente bom. Opa!
Desde então, eu usei o Bazaar e o Git (e o SVN quando tive que fazer para uma aula de Engenharia de Software), embora principalmente o Git para fazer o controle de versão em todos os meus projetos. Geralmente eu sou bem fiel sobre quantas vezes eu me comprometo, mas de vez em quando eu vou por um tempo (várias funções, etc.) antes de escrever um novo commit.
Então, minha pergunta para você é: com que frequência você deve fazer commits? Tenho certeza de que não existe uma regra rígida e rápida, mas que diretriz você (tente seguir)?
Sempre que eu tiver algo que funcione (ou seja, não quebre nada para ninguém), farei um check-in. Eu escrevo a maioria das minhas coisas primeiro, então isso significa que toda vez que eu fizer um novo teste, eu faço check-in.
Na prática, isso significa algumas vezes por hora. Pelo menos um par de vezes a cada hora, com 5 sendo um pouco.
Você não deve se comprometer com base em uma base de tempo, mas em uma base de recurso. Sempre que você adicionar um novo recurso que valha a pena ser enviado, confirme. Você adicionou um método de trabalho? Commit. Você corrigiu um erro de digitação? Commit. Você corrigiu um recuo errado de arquivo? Commit. Não há nada errado em cometer pequenas alterações, assim que o commit for relevante.
O que está errado é comprometer um grande número de mudanças, sem relações entre si. Isso torna muito difícil detectar a fonte de confirmação de uma determinada regressão.
Às vezes, faço vinte commits em uma hora e, às vezes, faço commit uma vez por dia, dependendo da quantidade de código que foi modificada.
Fazer pequenos commits permite que você use ferramentas muito poderosas como o git-bisect.
Não esqueça a regra n ° 1 do commiter: nunca quebre o tronco. Se você precisar fazer vários commits que provavelmente quebrarão o tronco, crie um branch.
Depende um pouco do que é o ambiente de desenvolvimento.
Se você é o único que contribui para uma base de código, um commit adiado não será tão crucial. No entanto, se você estiver em uma equipe de vários desenvolvedores, e todos pensarem "ah, bem, vou esperar com o commit um pouco" então você vai acabar lidando com muitos conflitos e perdendo muito tempo. / p>
A regra geral (para ambos os cenários) seria: Confirmar com a maior frequência possível. Se você acha que "ainda não está pronto" (porque ele vai quebrar a compilação ou simplesmente ainda não está pronto), crie uma ramificação e se comprometa com essa ramificação, mas certifique-se de confirmar.
Pelo menos uma vez por dia, geralmente três ou quatro, como costumo cometer a qualquer momento, faço uma pausa. Eu trabalho sozinho, então não tenho que me preocupar em mexer com outra pessoa, e sempre posso reverter um arquivo se achar que segui o caminho errado.
Eu tive uma experiência ruim uma vez quando não estava fazendo commits regularmente e meu disco rígido falhou e perdi algumas horas de trabalho. Como meu repositório está em outra máquina e é feito backup regularmente, não há motivo para eu ter perdido nada.
Graças aos branches e como eles são facilmente gerenciados, eu me comprometo com muita frequência. Eu diria que, sempre que você adicionar algo que você acha importante e que pode adicionar algo mais tarde, você deve se comprometer.
Além disso, muitas vezes eu me encontro fazendo algumas refatorações e adicionando novos testes antes do novo código, então para este caso eu me comprometo toda vez que eu executo o teste, vejo ele falhar, fazê-lo passar novamente e refatorar.
Além disso, após qualquer correção de bug, não importa o quão pequena ou insignificante possa parecer.
Eu às vezes desço o "comprometer-se assim que compila" a estrada também.
No DVCS, eu me comprometo basicamente sempre que estou começando uma mudança que seria realmente irritante se eu não pudesse desfazer, sempre que eu precisar compartilhar com os outros, ou a qualquer momento seria realmente útil ver o que eu mudei desde nesse ponto. Isso varia de várias vezes por hora a algumas vezes por dia. Além disso, muito raramente eu faço commit quando minha compilação não é pelo menos compilada e executada sem segfaults imediatos, embora isso possa ser útil também se você quiser isolar e compartilhar apenas a correção para esse bug em particular.
Note que com o controle de versão centralizado, que é muito provável que você seja obrigado a usar no trabalho, você geralmente não se compromete até ter certeza de que não receberá uma tempestade de e-mails irados por fazer isso. Dependendo de quão independentes são as alterações que você está realizando e do quanto sua empresa assina o dogma de integração contínua, isso se dá mais de uma vez ao dia, talvez uma vez por mês, em um grande recurso novo.
Essa diferença de frequência é uma das principais razões pelas quais eu uso o git no topo do VCS centralizado oficial da minha empresa.
Se você estiver trabalhando em um ambiente de equipe com um servidor de compilação, só desejará se comprometer quando tiver algo criado. É muito chato para o resto do time:)
Assisti recentemente a essa apresentação Joel On Software - FogBugz / Kiln e acho que ela se relaciona bem com sua pergunta.
Enquanto em algum controle de versão 'commit' é sinônimo de 'publish' (ou 'cause dor a outros') em VCS distribuídos, eles são freqüentemente separados.
Então quando commitar pode depender do VCS que você usa.
Confirmar automaticamente após cada compilação bem-sucedida.
Suponho que, se você quiser reverter para uma versão anterior e lembrar-se da hora aproximada do relógio de parede do ponto para o qual deseja reverter, basta consultar essa revisão.
É claro que se você usar o TDD, haverá soluções integradas melhores.
Toda noite, quando vou para casa, tenho um script que passa automaticamente por todos os meus branches e faço um commit (note que todos os desenvolvedores não recebem essas mudanças. É apenas meu ramo pessoal). Desta forma, não tenho que pensar nisso.
Também tenho um script que executará automaticamente uma atualização pela manhã. Eu uso este para que, se eu trabalhar do meu laptop à noite, minhas alterações estejam automaticamente lá de manhã.
Quanto a reverter as alterações que eu faço durante o dia, meu editor tem um histórico de todas as alterações e é muito mais rápido do que fazer um commit em cada save / compile.
Eu trabalho sozinho. Meu ambiente de desenvolvimento é meu notebook. O ambiente de commit é um servidor na web.
Se o cliente usar o servidor da web para acompanhar o progresso. Então, quase todo dia eu faço um upload junto com um e-mail dizendo o que há de novo.
Se o ambiente de confirmação for um ambiente de produção, preciso ter mais cuidado com todas as alterações que estão sendo testadas antes de qualquer confirmação. Mas ainda assim, muitas vezes parece melhor, como ninguém tem dúvidas sobre se o novo recurso já está planejado ou feito; eles recebem o que pedem o mais rápido possível.