git para projetos pessoais (one-man). Exagero?

Eu conheço e uso dois sistemas de controle de versão: Subversion e git. O Subversion, a partir de agora, é usado para projetos pessoais em que eu sou o único desenvolvedor e o git é usado para projetos de código aberto e projetos em que acredito que outros também trabalharão no projeto. Isso se deve principalmente aos incríveis recursos de bifurcação e fusão do git, onde todos podem trabalhar em seu próprio ramo; muito conveniente.

Agora, eu uso o Subversion para projetos pessoais, pois acho que o git faz pouco sentido lá. Parece ser um pouco exagerado. Tudo bem para mim se estiver centralizado (no meu servidor doméstico, geralmente) quando eu for o único desenvolvedor; Eu faço backups regulares de qualquer maneira. Eu não preciso da capacidade de criar meu próprio ramo, o ramo principal é o meu ramo. Sim, o SVN possui um suporte simples para ramificação, mas um suporte muito mais poderoso para ele não faz sentido, eu acho. A fusão pode ser uma dor, ou pelo menos da minha pouca experiência.

Existe alguma boa razão para eu usar o git em projetos pessoais, ou é simplesmente um exagero?

Não é um exagero. A principal razão pela qual comecei a usar o Git e o Mercurial over Subversion para projetos pessoais é que iniciar um repositório é muito mais fácil.

Quer começar um novo projeto?

> git init

BAM! Não há necessidade de configurar um servidor de repositório nem fazer check-in de uma estrutura de pastas para suportar ramificações e tags em um repositório do subversion.

Compartilhar seu projeto posteriormente é apenas uma questão de: git push(além de ter um repositório remoto). Tente fazer isso rapidamente com o subversion!

Eu diria que o uso do Subversion para projetos pessoais locais é um exagero, enquanto o Git não é decididamente. O Git ocupará menos espaço (devido ao ineficiente conceito de "revisões" do SVN versus os instantâneos de objeto do Git), requer menos configuração (em git initcomparação a uma dúzia de svnadmincomandos e configuração de permissões e assim por diante), é mais fácil de fazer backup ( git clone --bare[ou git push originse você usa o Github ou similar] e pronto) e possui ferramentas melhores para gerenciar seu código (a ramificação é gratuita e a mesclagem é mais fácil e limpa). Só porque ninguém mais tem um clone do seu repositório não significa que os benefícios de qualquer DVCS sejam "um exagero".

Além disso, eu diria que o suporte de ramificação do Git é menos complexo que o do SVN, com maiores recompensas.

Pensar que você nunca ramificará seu próprio código é um pouco míope. Eu ramifiquei meu próprio código várias vezes, principalmente quando estava experimentando uma nova abordagem sobre a qual ainda não estava totalmente convencido. Você acabará desejando o recurso.

Isso vem de um usuário antigo do Subversion. A consolidação de uma ferramenta pode realmente ajudar a tornar sua vida mais fácil.

O excesso de habilidade é reservado para quando houver danos colaterais causados ​​pela "solução". Usar uma arma para matar uma mosca significa que os danos causados ​​pela bala vão para outro lugar. É um exagero. Usar algo mais poderoso do que o necessário que não causa um problema não é um exagero e pode ser uma coisa boa se ajudar a otimizar seu processo de desenvolvimento. Não causa danos e permite que você apenas precise atualizar um conjunto de software em vez de dois. Então, por que se preocupar com dois sistemas em vez de um?

Eu uso o Git para meus projetos individuais e adoro isso. Eu estava usando o Subversion anteriormente e ainda estou vendo uma desvantagem no uso do Git. É mais poderoso, mas não de uma maneira que torne as coisas simples mais complicadas. Tornar coisas simples desnecessariamente complicadas / caras / lentas / etc. IMHO é uma condição necessária para chamar algo de exagero. Além disso, no Github, eu bifurquei os projetos individuais de outras pessoas para adicionar um recurso que eu queria e depois enviei solicitações pull. Eu acharia muito legal se alguém interessado nos meus projetos fizesse a mesma coisa.

Eu nunca usei o controle de origem em projetos pessoais antes do DVCS, por isso é um pouco estranho imaginar alguém tendo a visão oposta. Algumas das minhas razões são:

• Fácil de configurar e desmontar. Por exemplo, um colega me deu um quebra-cabeça de programação na semana passada que eu resolvi em várias pequenas etapas. Fiz um repositório Git que durou 45 minutos para manter meu trabalho e depois ele se foi. Não sei como é fácil algo assim na subversão, mas nunca ouvi falar de alguém fazendo isso.
• Desconectado. Para mim, poder trabalhar offline é muito mais um benefício para um projeto de hobby do que um para o trabalho. Não preciso abrir um buraco no firewall doméstico ou hospedar um projeto publicamente. Posso colocar temporariamente um repositório em um pen drive ou laptop e ainda assim manter tudo sincronizado.
• Tudo colocado. Reunir o repo e a árvore de trabalho facilita o acompanhamento de pequenos projetos durante coisas como atualizações do sistema operacional.
• Recursos poderosos. Claro, eu não preciso da energia o tempo todo, mas está lá quando eu preciso, e não consome nenhum recurso quando não preciso.

Disseram-me que git-bisecté realmente bom encontrar o commit exato que introduziu um determinado comportamento, navegando em commits, dependendo da sua entrada.

Você terá que fazer isso algum dia por coisas que simplesmente não consegue entender o que aconteceu.

EDIT: Além disso, a capacidade de ramificação é muito importante quando você precisa fazer correções de bug em versões antigas que os clientes usam. Você deve ser capaz de gerenciar "apenas conserte essa pequena coisa, mas eu não quero a versão mais recente, porque não quero testá-la novamente agora".

Depende de quão sério você deseja obter sobre a versão do seu próprio código. Se o que você está construindo é, por exemplo, uma biblioteca simples que só terá a versão atual (ou enquanto isso for verdade), eu pessoalmente usaria apenas uma opção de backup básica como o Dropbox. Se você perder todo o seu código, poderá recuperá-lo da Web e o Dropbox terá um backup de versão de 30 dias se você realmente fizer algo estúpido.

No entanto, se você, por exemplo, precisar manter os ramos Produção e Desenvolvimento, o git é absolutamente uma ótima ferramenta - e muito mais rápido que o svn. Mas lembre-se do risco de falha do disco rígido, se você armazenar apenas os dados localmente.

Eu sempre, sempre, sempre utilizava um sistema de controle de versão para qualquer tipo de projeto de desenvolvimento. Grande ou pequeno realmente não importa. Seja jogando em casa com algum tipo de nova tecnologia, escrevendo um pouco de ajuda para facilitar minha vida ou desenvolvendo-me profissionalmente em uma equipe grande e distribuída - eu sempre desejaria um sistema de controle de versão para me apoiar.

Claro, na maioria das vezes, para pequenos projetos pessoais, você não usará a maioria dos recursos, mas configurar um repositório git (ou mesmo um repositório local do Subversion) não é grande coisa, então vá em frente! E antes que você perceba, você vai querer saber "caramba, qual foi o conteúdo do arquivo X na última sexta-feira?". Sem controle de versão - boa sorte ;-)

Então, realmente não importa se você usa git ou SVN - pessoalmente, estou começando a migrar mais e mais coisas do SVN para o git, mas o principal é usar o controle de versão - mesmo para as pequenas coisas.

Somente porque ninguém o mencionou: para projetos pessoais, o darcs é realmente bom e menos envolvido do que o git para fazer um controle direto da versão. Não é tão rápido para projetos maiores, mas o Subversion também não!

Pode ser uma poderosa mudança de paradigma mental para entender que o que fazemos é experimentação. Ter uma ferramenta barata / fácil para dar suporte a isso aumenta sua capacidade de avançar, em parte porque aumenta sua capacidade de desistir de qualquer experimento quando o resultado é ruim.

Muitos desenvolvedores dizem: Bem, eu apenas faço cópias do meu código. Mas essas cópias se tornam difíceis de gerenciar e acabam sendo desorganizadas. Você tem várias cópias e não consegue lembrar qual cópia para quê e, em seguida, tente descobrir quando é seguro excluí-las.

Tudo isso se torna ainda mais valioso quando o experimento envolve alterações coordenadas em vários arquivos. E quando se trata de um projeto solo, o uso do Git se torna ainda mais simples.

Em vez de me perguntar se devo usá-lo em um projeto solo, agora penso que pena não ter descoberto isso antes.