Você deve se comprometer assim que tiver uma "unidade" sensata completa.

O que é uma unidade? Depende do que você está fazendo; Se você estiver criando um projeto do Visual Studio, por exemplo, confirme a solução logo após sua criação, mesmo que ela não tenha nada nela.

A partir daí, continue comprometendo-se com a maior frequência possível, mas ainda confirme apenas "unidades" completas (por exemplo, classes, configurações, etc.); fazer isso tornará sua vida mais fácil se algo der errado (você poderá reverter um pequeno conjunto de alterações) e reduzirá a probabilidade de conflitos.

No que me diz respeito, o repositório de controle de código-fonte faz parte da configuração básica do projeto, portanto, eu me comprometo após gerar o projeto vazio.

ontem

... em alternativa, se você não puder viajar no tempo ...
(talvez seu carro não consiga chegar a 88 mph, ou seu capacitor de fluxo acabou de ser quebrado)

Agora

Novos projetos devem ser comprometidos no local, não é loucura, e sistemas DVCS contemporâneos acabaram de remover todas as possíveis desculpas para evitar commits : git init . ; git add * ; git commit -m initial-commit agora, antes que seja tarde demais, já que pode já ser.

Uma pergunta mais sensata e argumentável poderia ter sido: "Quando devo fundir meu compromisso com um controle de origem compartilhado em uma equipe gerenciada repositório em um projeto estabelecido ? " (note que os adjetivos, os adjetivos são importantes) E tenho a impressão de que a maioria das outras respostas está realmente tentando responder a isso.

Seu ramo pessoal deve ser comprometido com como louco , pelo menos uma vez por dia , antes de dormir. Você pode simplesmente acordar na manhã seguinte e descobrir que não tem ideia do que diabos você estava fazendo na noite anterior. O VCS deve cobrir você contra isso, e ter a oportunidade de reverter para uma subversão muito recente de uma sub-versão que compila bem, corre sem problemas e / ou passa em testes pode ser sua melhor opção.

Eu diria que se comprometa o mais rápido possível. O principal objetivo do controle de origem é permitir que você volte caso algo dê errado, e isso ressoa com a prática "comprometer-se cedo e com frequência".

Pessoalmente, meu primeiro commit normalmente contém apenas o arquivo .gitignore (ou equivalente) com alguns filtros que eu sei que serão necessários, como *. py [co] para Código Python. A configuração básica do projeto e / ou o primeiro protótipo mais simples é o que geralmente segue.

O primeiro commit pode ser um arquivo README com apenas um resumo de linha do projeto ou informações suficientes sobre o primeiro marco do projeto. Os tópicos gerais também podem incluir:

• Introdução
• Descrição do projeto
• Estrutura do projeto
• Convenções de codificação
• Instruções sobre como:
  • compilação
  • teste
  • implantar
• Problemas conhecidos e soluções alternativas
• lista de tarefas
• Termos de uso

A prática de atualizar o README antes de fazer alterações em um projeto também é chamada de Desenvolvimento orientado por Readme e permite que você pense nas mudanças antes de investir tempo para fazer essas alterações.

Qualquer pessoa que queira contribuir ou usar este software começará com o README.

Se você fez um trabalho que não gostaria de perder, ele deve estar no sistema de controle de origem.

Isso certamente se aplica a sistemas distribuídos como o Git. Se você está usando um sistema centralizado, e a única maneira de verificar algo é torná-lo visível para todos , você pode querer adiar - ou você pode considerando configurar seu próprio repositório git local e enviar para o sistema centralizado quando estiver pronto.

Minha regra básica é fazer o check-in depois que meu arquivo de solução (ou outra parte do script de construção) estiver pronto, mesmo que contenha alguns arquivos vazios. É uma boa prática quando mais de uma pessoa está trabalhando no projeto. Esse arquivo tende a ter os piores problemas de mesclagem inicialmente, pois as pessoas estão adicionando coisas ao projeto, portanto, as necessidades são cometidas cedo e frequentemente.

Mesmo que você seja o único que está trabalhando no projeto e tenha apenas um arquivo, é mais fácil seguir o mesmo fluxo de trabalho e economizar o pensamento para o problema em questão.

Não certeza se foi mencionado.

Mas certifique-se de que o que você comete executa / compila! Portanto, não há erros de sintaxe, etc.

Nada mais frustrante do que o código de check-out quebrado.

Outro ponto de vista mais relacionado ao teste de software (abordagem de TDD) seria confirmar assim que você tiver novos casos de testes em verde. Isso significa que você tem uma nova "unidade" de código concluída.

Pouco antes de você fazer algo bobo.

Para aqueles de nós sem poderes mágicos, isso significa pouco e freqüentemente.

Se você está trabalhando sozinho, faça isso toda vez que você pegar uma bebida, ou o que for.

Se você está trabalhando em uma equipe, provavelmente precisa ter certeza de que a coisa é compilada, de modo que, se outra pessoa chegar, ela não receberá erros. Mas além disso, tanto quanto você puder.

Cerca de 2 a 3 horas no projeto.

Apenas brincando. Não há uma boa resposta que se encaixe em todas as situações. Primeiro de tudo, se você tiver um sistema de controle de versão distribuído (como o git ou o Mercurial), o comprometimento com o repositório local não preservará seus dados em caso de falha catastrófica. Mas um repo remoto privado pode custar-lhe dinheiro, por ex. no github. Você preservará o histórico de commit, mas na minha experiência você não precisará disso até que seu projeto esteja um pouco avançado.

Além disso, você provavelmente não quer muita rotatividade no começo, especialmente se estiver movendo arquivos. Cometer mudanças será um fardo se for apenas um pequeno. Você pode até decidir jogar a coisa fora. Mas se você perder as alterações que não são triviais para replicar, você não conseguirá fazer uma cópia de backup, e os sistemas de controle de versão criarão sistemas de backup extremamente valiosos.

Algumas pessoas hoje em dia usam o DropBox ou algo parecido para armazenar seu código. Pode ser um bom compromisso no início de um projeto, uma vez que é preciso esforço zero para configurar. No entanto, é um hábito bárbaro no desenvolvimento sério de software, especialmente se várias pessoas estiverem tocando o código ao mesmo tempo.

Por isso, tenho a tendência de configurar o controle de versão sempre que tenho algo valioso, ou seja, não é trivial replicar. O valor é subjetivo (e depende das capacidades de cada um), então você terá que fazer o seu próprio julgamento. Nesse ponto, eu armazeno um segundo repo em um disco externo, ou no github, se for um projeto público ou minha conta de pagamento vai mantê-lo.

Muitas pessoas já responderam "imediatamente" e eu concordo 100%. Também gosto da sugestão de Xion para começar com os padrões de ignorar do VCS (ou seja, .gitignore ou equivalente).

Eu acho que é muito bem acordado que não há desvantagens para os primeiros commits. Eu gostaria de adicionar upsides:

• Você tem menos chances de cometer coisas que você decidiu descartar, mas ainda está por aí. Quando inicio um novo desenvolvimento, codifico e discordo rapidamente, e quando eu me comprometo mais tarde, quando já existe um monte de arquivos, eu tenho comprometido acidentalmente o material apenas para deletá-lo no próximo commit. Isso, ao contrário de pequenos, ou mesmo vazios, é um verdadeiro ruído na história.
• Se você é um tipo sistemático e tem os primeiros passos típicos em seus projetos, tê-los como pontos de comprometimento pode ser instrutivo para você ou para outros, e pode até proporcionar uma oportunidade de se ramificar em um certo ponto e criar um reutilizável esboço do projeto. Eu trabalhei em projetos baseados em Maven onde isso era útil (porque ao configurar um projeto Maven, alguns pequenos primeiros passos já podem definir uma base substancial, e enquanto esses passos não são muito para fazer , eles podem exigir bastante pensamento para garantir a reutilização).

Pode depender de qual VC você está usando.

Com o Git, eu confirmo um diretório vazio (ou com um arquivo README quase vazio). O ponto é que eu posso voltar e resetar minha ramificação para aquele estado vazio se eu quiser começar completamente de novo enquanto ainda estou adiantado no processo de desenvolvimento (antes de empurrar para cima). Em seguida, eu enviaria meus arquivos "gerados" (por exemplo, solução visual studio). Então, quando eu realmente estiver codificando, vou começar a confirmar cada unidade como faria normalmente.

Com o SVN, você está fazendo upstream com cada commit para que você realmente não tenha o luxo de começar de novo como você faz com o Git. Neste caso, pode não ser benéfico comprometer-se cedo, se você acha que estará fazendo uma grande reformulação no início do processo. Isso vai depender da pessoa que codifica.

Quando inicio um novo projeto, geralmente começo cometendo isso antes que qualquer código tenha sido adicionado. Uma regra geral que sempre segui é: se o seu PC travasse e limpasse todos os seus dados, qual código você preferiria não ter que escrever da memória. Há dez anos, antes do TDD e da melhor prática de programação, eu estava bastante otimista sobre o que eu conseguia lembrar. Agora, tenho a tendência de ser mais cauteloso. Como muitos outros pôsteres disseram, cometer cedo e cometer com frequência. Você não está perdendo nada fazendo isso.

Estou trabalhando sozinho a maior parte do tempo, então devo confessar que estou ficando relaxado, mas geralmente me comprometo antes de ir para casa. Dessa forma, se eu não fizer isso amanhã, meus colegas podem continuar de onde parei.

Atualmente estou usando o Tortoise / SVN no trabalho.

Confirme o projeto vazio imediatamente. Continue comprometendo várias vezes por hora que você gasta trabalhando no projeto. Commit mesmo se o código não compilar. Eu marquei tais commits com "WIP" na massagem do commit para rastreá-los.

Eu também tenho um script que automaticamente compromete todos os meus projetos a cada 10 minutos para um repositório de backup, apenas no caso de eu esquecer de confirmar manualmente. Vamos chamá-lo de meu buffer de desfazer suportado pela nuvem.

Faça check-in (também conhecido como push ) do projeto para um repositório de equipe quando precisar que sua equipe veja seu código. O que provavelmente é antes que seu código esteja pronto para ser visto por sua equipe, se você for como eu.

Se você quiser ser gentil com sua equipe, squash seus commits antes de empurrá-los para o repo da equipe.

Já passei por todos os artigos e acho que já temos muitas soluções boas, mas gostaria de compartilhar minha metodologia com você.

Ao trabalhar na criação de framework (do zero), muitas mudanças serão realizadas para cada módulo até que o módulo seja completado ou finalizado. Então eu sempre tenho dois locais, um é chamado de DINÂMICO e outro é ESTÁTICO. Quando as alterações estão acontecendo e a estrutura ainda não está finalizada, ela foi confirmada no local DYANMIC e, uma vez concluída e finalizada, eu a movo para o local ESTÁTICO. Então eu tenho um controle de fonte completo.

Obrigado

Com qualquer aplicativo, você gastará algum tempo projetando os componentes. Você deve saber, grosseiramente ou detalhadamente, seus espaços de nome, projetos, referências externas, bibliotecas de terceiros etc.

Se você estiver em uma equipe, eu sugeriria o seu lead, ou quem quer que seja escolhido, para criar o projeto base, obter o conjunto de dependências e verificar o esqueleto (base na qual seu projeto será construído).

Você também deseja garantir que sua tarefa, release, tronco, etc. ramifique-se antes de fazer o check-in, para que seu processo seja sólido.

Se você está trabalhando em uma nova "tarefa" para um projeto que já está em andamento e está no seu próprio ramo de tarefas, faça seus check-ins noturnos para preservar seu trabalho.

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).