Eu nunca tenho certeza de quando um projeto está longe o suficiente para confirmar primeiro o controle de origem. Costumo adiar a confirmação até que o projeto esteja "completo da estrutura" e comprometo principalmente os recursos a partir de então. (Eu não fiz nenhum projeto pessoal grande o suficiente para ter uma estrutura principal muito grande para isso.) Sinto que essa não é uma prática recomendada, embora não tenha certeza do que poderia dar errado.

Digamos, por exemplo, que eu tenho um projeto que consiste em um único arquivo de código. Serão necessários cerca de 10 linhas de código padrão e 100 linhas para que o projeto funcione com funcionalidades extremamente básicas (1 ou 2 recursos). Devo primeiro fazer o check-in:

1. O arquivo vazio?
2. O código padrão?
3. Os primeiros recursos?
4. Em algum outro momento?

Além disso, quais são os motivos para fazer o check-in em um ponto específico?

Você deve se comprometer assim que tiver uma "unidade" sensata concluída.

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 a criação, mesmo que ela não tenha nada.

A partir daí, continue comprometendo o mais rápido possível, mas ainda assim comprometa apenas as "unidades" concluídas (por exemplo, classes, configurações etc.); isso facilitará sua vida se algo der errado (você pode reverter um pequeno conjunto de mudanças) e reduzirá a probabilidade de conflitos.

No que me diz respeito, seu repositório de controle de origem faz parte da configuração básica do projeto, portanto, confirmo logo após a geração do meu projeto vazio.

Ontem

... em alternativa, se você não puder viajar no tempo ...
(talvez o seu carro não consiga chegar a 88 km / h, ou o seu capacitor de fluxo tenha acabado de funcionar)

Agora

Novos projetos devem ser comprometidos no local sangrento, é uma loucura, e os sistemas DVCS contemporâneos acabaram de remover todas as desculpas possíveis para evitar comprometimentos : git init . ; git add * ; git commit -m initial-commitagora, antes que seja tarde demais, como já deveria estar.

Uma pergunta mais sensata e discutível poderia ter sido: "Quando devo mesclar meus commits a um controle de fonte compartilhada em um repositório gerenciado por equipe em um projeto estabelecido ?" (observe os adjetivos, os adjetivos são importantes) E sinto que a maioria das outras respostas está realmente tentando responder a isso.

Seu ramo pessoal deve se comprometer a gostar de louco , pelo menos uma vez por dia , antes de dormir. Você pode acordar na manhã seguinte e descobrir que não tem idéia do que diabos estava fazendo na noite anterior. O VCS deve protegê-lo contra isso, e ter a oportunidade de reverter para uma sub-versão-de-uma-sub-versão muito recente que compila bem, executa sem problemas e / ou passa nos testes pode ser sua melhor opção.

Eu diria que cometer o mais rápido possível. O principal objetivo do controle de origem é permitir que você volte no caso de algo dar errado, e isso ressoa com a prática "confirmar cedo e frequentemente".

Pessoalmente, meu primeiro commit normalmente contém apenas o arquivo .gitignore (ou equivalente) com poucos 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 se segue.

A primeira confirmação 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:
  • Construir
  • teste
  • implantar
• Problemas conhecidos e soluções alternativas
• lista de afazeres
• Termos de uso

A prática de atualizar o README antes de fazer alterações em um projeto também é chamada de Desenvolvimento Dirigido por Leia-me e permite que você pense nas alterações antes de investir tempo em 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 seu sistema de controle de origem.

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

Minha regra geral é fazer check-in assim que meu arquivo de solução (ou outra parte do script de construção) for concluído, mesmo que contenha alguns arquivos vazios. É uma boa prática para quando mais de uma pessoa estiver trabalhando no projeto. Esse arquivo tende a ter os piores problemas de mesclagem inicialmente, à medida que as pessoas adicionam itens ao projeto, por isso precisam ser comprometidas desde o início e com frequência.

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

Não tenho certeza se foi mencionado.

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

Nada mais frustrante do que o código de pagamento quebrado.

Outro ponto de vista mais relacionado ao teste de software (abordagem TDD) seria confirmado assim que você apresentasse novos casos de teste 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 frequentemente.

Se você estiver trabalhando sozinho, faça-o sempre que tomar uma bebida ou o que for.

Se você estiver trabalhando em equipe, provavelmente precisará certificar-se de que a coisa seja compilada, para que, se alguém receber as últimas notícias, elas não receberão um monte de erros. Mas fora isso, tanto quanto você puder.

Cerca de 2 a 3 horas no projeto.

Apenas brincando. Não existe uma boa resposta que sirva para todas as situações. Primeiro de tudo, se você tiver um sistema de controle de versão distribuído (como git ou Mercurial), o compromisso com o seu repositório local não preservará seus dados em caso de falha catastrófica. Mas um repositório remoto privado pode custar-lhe dinheiro, por exemplo, no github. Você preservará o histórico de consolidação, 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 deseja muita rotatividade no início, especialmente se estiver movendo arquivos. A confirmação de alterações será um fardo, mesmo que pequeno. Você pode até decidir jogar a coisa fora. Mas se você perder alterações que não são triviais para replicar, sentirá falta de fazer uma cópia de backup e os sistemas de controle de versão criarão sistemas de backup extremamente valiosos.

Atualmente, algumas pessoas usam o DropBox ou similar para armazenar seu código. Pode ser um bom compromisso no início de um projeto, uma vez que é preciso zero esforço para ser configurado. No entanto, é um hábito bárbaro no desenvolvimento sério de software, especialmente se várias pessoas estão tocando o código ao mesmo tempo.

Portanto, costumo configurar o controle de versão sempre que tenho algo valioso, ou seja, não é trivial para replicar. O valor é subjetivo (e depende das capacidades de cada um), portanto você terá que fazer seu próprio julgamento. Nesse ponto, armazeno um segundo repositório em um disco externo ou no github, se for um projeto público ou se minha conta pagadora o manterá.

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

Eu acho que está praticamente de acordo que não há desvantagens nos commits iniciais. Eu gostaria de adicionar vantagens:

• É menos provável que você cometa coisas que escolheu descartar, mas isso ainda permanece por aí. Quando inicio um novo desenvolvimento, codificarei e discarei rapidamente o material, e quando confirmei mais tarde, quando já houver vários arquivos, confirmei acidentalmente o material apenas para excluí-lo no próximo commit. Isso, em oposição a pequenas, ou mesmo vazias, confirma, é um verdadeiro ruído na história.
• Se você é do tipo sistemático e tem os primeiros passos típicos em seus projetos, tê-los como pontos de confirmação pode ser instrutivo para você ou para outras pessoas, e pode até fornecer uma oportunidade de ramificar em um determinado momento e criar um esboço reutilizável do projeto. Trabalhei em projetos baseados no Maven, onde isso foi útil (porque na criação de um projeto do Maven, alguns pequenos primeiros passos já podem definir uma base bastante substancial e, embora esses passos não sejam muito a serem feitos , podem ser necessários pensamentos suficientes para justificar reutilização).

Pode depender de qual VCS você está usando.

Com o Git, eu confirmo um diretório vazio (ou com um arquivo LEIA-ME quase vazio). O ponto é que eu posso voltar e redefinir minha ramificação para esse estado vazio, se eu quiser começar completamente de novo enquanto ainda estou no início do processo de desenvolvimento (antes de avançar o processo). Eu comprometia meus arquivos "gerados" (por exemplo, solução do visual studio). Então, quando eu estiver realmente codificando, começarei a comprometer cada unidade como faria normalmente.

Com o SVN, você está avançando a montante com cada commit, para realmente não se dar ao luxo de recomeçar como no Git. Nesse caso, pode não ser benéfico confirmar com antecedência, se você acha que fará uma grande reforma no início do processo. Isso depende da pessoa que está codificando.

Quando inicio um novo projeto, geralmente começo confirmando isso antes que qualquer código seja adicionado. Uma regra geral que sempre segui é: se o seu PC travasse e limpasse todos os seus dados, qual código você preferiria que não fosse necessário gravar na memória. Dez anos atrás, antes do TDD e das melhores práticas de programação, eu estava bastante otimista sobre o que conseguia me lembrar. Agora, eu tendem a ser mais cautelosos. Como muitos outros pôsteres disseram comprometer-se cedo e comprometer-se frequentemente. Você não está perdendo nada fazendo isso.

Estou trabalhando sozinho a maior parte do tempo, então devo confessar que estou ficando folgado, mas geralmente me comprometo antes de voltar para casa. Dessa forma, se eu não chegar amanhã, meus colegas poderão retomar de onde parei.

Atualmente, estou usando o Tortoise / SVN no trabalho.

Confirme o projeto vazio imediatamente. Continue cometendo várias vezes por hora que você gasta trabalhando no projeto. Confirme mesmo que o código não seja compilado. Eu marquei esses commits com "WIP" na massagem de commit para acompanhá-los.

Também tenho um script que confirma automaticamente todos os meus projetos a cada 10 minutos em um repositório de backup, caso eu esqueça de confirmar manualmente. Vamos chamá-lo de buffer de desfazer suportado na nuvem.

Faça check-in (aka. Push ) do projeto em um representante de equipe quando você precisar que sua equipe veja seu código. Provavelmente, antes que seu código esteja pronto para ser visto por sua equipe, se você for como eu.

Se você quer ser legal com sua equipe, esmague seus commits antes de enviá-los para o repo da equipe.

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

Enquanto trabalhamos na criação da estrutura (desde o início), muitas mudanças ocorrerão em cada módulo até que o módulo seja concluído ou finalizado. Então, eu sempre tenho 2 locais, um é nomeado como DINÂMICO e o outro é estático. Quando as mudanças estão acontecendo e a estrutura ainda não está finalizada, ela foi confirmada na localização DYANMIC e, uma vez concluída e finalizada, eu a movo para a localização estática. Então, eu tenho um controle de origem completo.

obrigado

Com qualquer aplicativo, você gasta algum tempo projetando os componentes. Você deve saber, com detalhes aproximados ou detalhados, seus espaços para nome, projetos, referências externas, bibliotecas de terceiros etc.

Se você estiver em uma equipe, sugiro seu líder, ou quem quer que seja escolhido, para criar o projeto base, definir as dependências e verificar esse esqueleto (base na qual seu projeto será construído).

Você também deseja garantir que suas tarefas, liberação, tronco, etc. sejam especificadas antes de fazer o check-in, para que seu processo seja sólido.

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

Normalmente, faço check-in sempre que adiciono algo novo, mas tento separar as coisas em confirmações discretas.

Isso significa que, se eu adicionar uma nova dependência, faço as alterações até que sejam compiladas ou grandes o suficiente para que você perca tempo para realizá-las novamente, do zero. Se eu tiver uma tarefa maior, tento confirmar várias vezes, quando faz sentido (uma vez por função, toda vez que eu a compilar e executar com êxito, etc.).

Também confirmo quando quero um ponto de backup (ou seja, "se o que eu tento agora não funcionar ou se tornar muito complicado, quero voltar ao código como está agora") ou quando alguém me pedir para largar o que sou e corrigir algum problema urgente).

Se você usar um sistema de controle de origem centralizado, não poderá confirmar arbitrariamente os pontos de backup, porque um commit que não é compilado / funciona afeta a todos da equipe.

Normalmente, quando começo a adicionar o código padrão (por exemplo, adicionar um novo webapp em um site do django), comprometo todas as operações que faço.

Se eu seguir um tutorial para gerar / escrever código, utilizarei nomes de etapas no tutorial para enviar mensagens. Dessa forma, posso diferenciar revisões e ver o que uma etapa do tutorial fez, a qualquer momento.

Digamos, por exemplo, que eu tenho um projeto que consiste em um único arquivo de código. Serão necessários cerca de 10 linhas de código padrão e 100 linhas para que o projeto funcione com funcionalidades extremamente básicas (1 ou 2 recursos).

Depende de quão difícil é adicionar as coisas:

• se fosse trivial adicionar o código da placa da caldeira, eu o adicionaria e confirmaria imediatamente antes de iniciar o outro código (desta forma, se eu cometer um erro ou introduzir um bug estranho mais tarde, eu posso simplesmente voltar ao código da placa da caldeira e começar novamente).

• Se o código não fosse trivial, eu confirmaria toda vez que adicionasse algo novo (em qualquer lugar entre cada duas linhas de código alteradas, para uma centena ou mais).