Normalmente eu faço check-in sempre que adiciono algo novo, mas tento separar coisas em commits discretos.
Isso significa que, se eu adicionar uma nova dependência, faço as alterações até que elas sejam compiladas ou sejam grandes o suficiente para perder tempo para executá-las novamente, do zero. Se eu tenho uma tarefa maior, eu tento me comprometer várias vezes, quando faz sentido (uma vez por função, toda vez que eu faço compilar e executar com sucesso, etc).
Eu também me comprometo quando quero um ponto de backup (ou seja, "se o que eu tentar agora não funcionar ou se tornar muito complicado, quero voltar ao código como está agora" ou quando alguém me pedir para sair o que estou fazendo e consertar alguma questão urgente).
Se você usa um sistema de controle centralizado de código-fonte, não pode cometer arbitrariamente pontos de backup, porque um commit que não compila / trabalha afeta todos em sua equipe.
Normalmente, quando eu começo a adicionar código clichê (por exemplo, adicionar uma nova aplicação web em um site django), eu faço todas as operações que eu faço.
Se eu seguir um tutorial para gerar / escrever código, eu uso nomes de etapa no tutorial para mensagens de confirmação. Desta forma, posso diferenciar revisões e ver o que um passo tutorial fez, em qualquer momento posterior.
Let's say, for example, I have a project which consists of a single code file. It will take about 10 lines of boilerplate code, and 100 lines to get the project working with extremely basic functionality (1 or 2 features).
Isso depende da dificuldade de adicionar as coisas:
-
se fosse trivial adicionar o código da placa do boiler, eu adicionaria e commitaria logo antes de iniciar o outro código (assim, se eu cometer um erro ou introduzir um bug estranho mais tarde, posso simplesmente reverter para o código clichê e começar de novo).
-
Se o código fosse não-trivial, eu me comprometia toda vez que adicionava algo novo (em qualquer lugar entre cada duas linhas de código alteradas, para uma centena ou mais).