fundo

Eu usei o VCS (principalmente git) no passado para gerenciar muitos projetos existentes e funciona muito bem. Normalmente, em um projeto existente, eu verificava cada alteração feita no código que otimiza ou altera a funcionalidade geral (você entende o que quero dizer, em etapas adequadas, nem todas as linhas que eu altero).

Problema

Uma coisa em que não tenho tanta prática é criar novos projetos. Estou iniciando um novo projeto que provavelmente crescerá bastante, mas estou descobrindo que há muito o que fazer e muitas mudanças nos primeiros dias / horas / semanas / período acima até que o produto esteja realmente funcionando da forma mais básica.

Existe algum ponto em eu verificar cada etapa do processo como faria com um projeto existente? Não estou quebrando o projeto com as alterações que faço, pois ele ainda não está funcionando. No momento, simplesmente utilizo o VCS como backup no final de cada dia, quando saio do computador.

Meus primeiros commits foram coisas como "Estrutura básica de diretórios no local" e "Tabelas de banco de dados criadas". Como devo usar um VCS ao iniciar um novo projeto?

Comece Simples

git init

Check-in mais cedo, check-in frequentemente

Faça o que você normalmente faz em qualquer projeto: "faça check-in" para cada conjunto de alterações relacionadas a uma tarefa ou grupo de ações específico. Se você usar um rastreador de problemas, confirme as alterações relacionadas a uma tarefa toda vez que ela estiver em um estado estável (consulte esta pergunta sobre SO com que frequência deve ser confirmada ). Pode não estar em um estado de conclusão, apenas estável, no qual o software não está sendo executado ou o site não está sendo processado. Como Jeff Atwood diz em seu post:

Se o código não estiver verificado no controle de origem, ele não existe. [...]

Não estou propondo que os desenvolvedores verifiquem código quebrado - mas também argumento que há uma grande diferença entre código quebrado e código incompleto.

Confirme frequentemente, aperfeiçoe mais tarde, publique uma vez

Se o produto não estiver nem perto de um estado viável, continue verificando as mudanças como achar melhor, usando o bom senso e o bom senso para agrupá-las. Você não precisa confirmar cada alteração de linha de um arquivo, uma por uma, mas confirmar tudo como uma grande parte tornará mais difícil a reversão, se necessário.

No final, seu VCS está aqui para ajudá-lo . Então ajude o seu VCS para ajudá-lo!

Não pense demais

Seus primeiros commits foram bons. Não pense demais. O mais importante é que eles façam check-in. Se você observar todos os projetos de código aberto existentes on-line que começaram do zero e não de uma base de código existente, eles têm como primeira revisão algo parecido com:

criou a estrutura de diretórios (yay!)

Faça disso um hábito

No final de cada dia, tente gerar um log do que você fez com base em seus logs de confirmação. Se os resultados obtidos git shortloge git logNÃO parecerem satisfatórios e úteis , ainda assim você fez um esforço significativo no projeto durante o dia e verificou essas alterações, provavelmente não fez o que estava certo .

• git shortlogdeve ler como uma ampla visão geral do que você fez.
• git logdeve ler como a história e a história do seu projeto.

O que você está fazendo é a abordagem correta.

Você está usando o controle de origem desde o primeiro dia - isso garantirá que você tenha tudo o que precisa no controle de origem e não há nenhum ponto em que possa dizer:

Eu deveria estar usando o controle de origem, mas levará muito tempo para verificar todas essas coisas pela primeira vez.

Esse é um grande obstáculo para as pessoas que chegam atrasadas ao controle de origem, pois acham que é "muito difícil" de usar. Ao começar cedo e confirmar as alterações, você reduziu esse obstáculo a um pequeno passo e qualquer pessoa que se juntar a você no projeto poderá começar a trabalhar imediatamente.