Um bom exemplo de alguém que se encaixa nessa descrição pode ser um gerente de projeto.

Outro dia fui perguntado pelo meu chefe: "O que é essa coisa no Github e por que é importante?" Ele tem alguns projetos proprietários e, portanto, precisaria de hospedagem privada, e eu me esforcei para explicar além do habitual: os VCSs tornam a colaboração trivial, fornecem um histórico e "backup" de todos os seus dados e permitem que você registre alterações atômicas em uma base de código . Na minha cabeça, eu pensava: "é quase como se você tivesse que usar um DRVS para realmente entender como é benéfico".

Acabei apontando-o para o BitBucket porque eles oferecem repositórios privados ilimitados (eu até precisei explicar o que era um repositório).

Alguém tem bons exemplos concretos de como um VCS salvou a bunda ou facilitou a vida, etc - basicamente, como você venderia um DVSC para alguém que não está familiarizado com a programação, mas que não é programador por profissão?

O controle de versão é ótimo para (pelo menos) três coisas: backup, compartilhamento de código entre desenvolvedores, localização + correção de bugs e rastreamento de progresso.

1. Backup . Se nada mais, é backup em esteróides. Você tem todo o histórico de desenvolvimento, cada confirmação é uma captura instantânea de todo o código com um ID (número de revisão), uma descrição, registro de data e hora e informações do usuário. E é simples comparar arquivos entre revisões. Se nada mais for, é mais rápido que um backup simples (apenas as alterações de arquivos são enviadas e armazenadas) e contém metadados muito mais úteis. Por que reinventar isso?

2. Compartilhando código entre desenvolvedores . Se você tiver pelo menos dois desenvolvedores trabalhando no mesmo produto simultaneamente, não vejo outra maneira de compartilhar de maneira confiável e consistente as alterações de código e mesclá-las. Enviando zips por correio?

3. Localizando e corrigindo erros . Quando seus clientes relatam um bug para uma versão específica do produto, você pode obter rapidamente o instantâneo de origem real para reproduzi-lo e corrigi-lo. É difícil reproduzir bugs se a sua fonte for diferente da do cliente. Você pede que eles enviem o executável para que você possa desmontá-lo? Além disso, se você tiver problemas para identificar a causa de um bug, poderá usar o VCS para identificar a revisão exata em que foi introduzido.

4. Rastreamento de progresso . Quando você confirma seu trabalho em snapshots, ele permite que você (e seu gerente) acompanhem o progresso nas implementações de recursos e o status de bugs abertos. Os sistemas de VC também são facilmente integrados aos sistemas de rastreamento e sistemas de integração contínua . É quase impossível manter um nível de qualidade para qualquer outra coisa que não seja um projeto de hobby, a menos que você tenha um VCS.

Depois de ter todos concordaram que não há desenvolvimento de software deve sempre ser feito fora de um VCS (eu não perderia isso mesmo para um projeto hobby), então você pode discutir características de um (um pouco mais complicado) DVCS (a parte seguinte descaradamente copiados de Wikipedia ):

• Cada usuário possui sua própria cópia local do repositório (e efetivamente uma cópia de backup)
• Permite que os usuários trabalhem produtivamente, mesmo quando não estão conectados a uma rede
• Torna a maioria das operações muito mais rápidas, pois não há rede envolvida
• Permite a participação em projetos sem exigir permissões das autoridades do projeto
• Permite trabalho privado, para que os usuários possam usar seu sistema de controle de revisão, mesmo para rascunhos que não desejam publicar
• Evita confiar em uma única máquina física como um único ponto de falha

"Você já achou o botão 'desfazer' útil? Ah, então você concorda que devemos usar um controle de versão?"

Quando comecei a usar o controle de versão, o principal recurso que me interessava era a capacidade de 'desfazer' meus erros e voltar à versão anterior. Todos podem apreciar um botão de desfazer. O controle de versão concedido pode fazer muito mais.

Comece com o básico:

Em primeiro lugar, um VCS protege os desenvolvedores de si e um do outro - se não tivesse outro objetivo além de permitir que dois ou mais desenvolvedores trabalhassem na mesma base de código com relativa segurança, seria de grande valor (e eu já participei de uma equipe na qual o anterior dias de trabalho foram substituídos por um pouco de cópia descuidada).

Em segundo lugar, fornece uma trilha de auditoria - um histórico - você pode voltar e ver quem mudou o quê e quando e pode voltar e recuperar o código excluído porque não era mais necessário ou apropriado quando se verifica que será necessário após tudo.

Em terceiro lugar, fornece um ponto de referência - a fonte definitiva é o código comprometido (no mundo real, é um pouco mais complicado, especialmente com o DVCS, mas, para fins desta discussão, é próximo). Se você tiver feito o backup do repositório corretamente, deverá ter os ativos da empresa protegidos.

Essas três coisas devem ser "a melhor" para a venda de VCS - se um gerente não puder ver valor suficiente no tempo acima para encontrar outro gerente.

Depois de vender o VCS (que, afinal de contas, é útil apenas para as equipes de desenvolvimento em que o número de desenvolvedores é maior que zero), a questão do motivo pelo qual o DVCS sobre, digamos, SVN ou TFS e a questão adicional de trabalhar ou não internamente ou usar um serviço hospedado como Kiln ou Bitbucket ou Github (que é privado se você pagar) é um pouco mais profundo e depende mais do contexto.

VCSs

Apenas explique o conceito de backups . Os backups permitem que você veja no que estava trabalhando em um determinado momento. Diga como antes os programadores do VCS costumavam copiar seus projetos inteiros compulsivamente, geralmente para salvar cada versão boa e estável que tinham; portanto, quando as coisas corriam mal, eles tinham um bom ponto de referência de quando as coisas funcionavam, compare-as com as coisas mais recentes e veja onde eles ou outra pessoa estragaram tudo e corrigiram isso mais facilmente , apenas observando as diferenças em vez dos dois backups completos do projeto.

Em resumo : os VCS permitem salvar backups do seu trabalho e permitem ver apenas as diferenças entre os backups.

DVCSs

Quanto ao controle de versão distribuído, explique como o controle de versão típico costumava precisar de um servidor e uma conexão à Internet e que todo mundo se cansava disso porque era mais lento e todos trabalhavam em um único backup, se alguém estragasse tudo, o projeto seria para todos, portanto, com o controle de versão distribuído, todos podem trabalhar em seu próprio backup em sua máquina sem uma conexão à Internet, e todos ficam felizes porque ninguém mexe com o backup enquanto trabalham e podem se preocupar em compartilhar seu trabalho mais tarde, quando terminar.

Outra coisa boa é que, diferentemente de um VCS centralizado, onde há apenas um backup, se a máquina com o backup pegar fogo, ainda existem outros backups completos a serem executados (pelo menos um para cada desenvolvedor).

Em resumo : os DVCSs permitem que você trabalhe em seu próprio backup, sem que todos tenham que ficar amontoados em um único servidor, incomodando-se e preocupando-se com as mudanças de outros depois de terminar suas coisas. Além disso, nada acontece se a máquina principal do repositório pegar fogo .

Eu trabalho principalmente com engenheiros (não desenvolvedores em si, mas eles escrevem código)

O ponto principal, quando eu explico a eles sobre o controle de versão, é a possibilidade de desfazer e gerenciar seu código / documentação / qualquer que seja e simplificar a colaboração com outros desenvolvedores / escritores / etc ...

Esse é um bom ponto de venda - e foi o principal motivo para eu usar um VCS em todo o meu trabalho, além das outras vantagens: ter uma história, um repositório que pode ser facilmente copiado ...

A maioria gosta da idéia e a considera bastante útil, adotando-a em seus projetos (principalmente se envolverem colaboração com outros engenheiros).

Ao tentar convencer alguém de qualquer coisa, você sempre precisa tentar chegar do ponto de vista deles.

Seu gerente de projeto tem um objetivo simples - concluir os projetos dentro do prazo e do orçamento.

Se você não está usando o controle de versão no momento, sua equipe de desenvolvimento está resolvendo os problemas que o controle de versão resolve manualmente. Todos esses problemas foram bem enumerados por outras respostas, por isso não os abordarei aqui.

O que você precisa fazer é explicar ao gerente de projeto que a equipe está gastando Xvárias horas por semana resolvendo manualmente os problemas que o GIT poderia resolver automaticamente, ou, digamos, o 0.1 * Xnúmero de horas do desenvolvedor.

Não o aborde usando motivos pelos quais o GIT facilitará sua vida ou a vida de seus colegas desenvolvedores, aborde a perspectiva de que o GIT enviará o software mais rápido e mais barato.

Eu gosto da descrição do @ Buttons840 como um botão de desfazer da base de código. Também pode ser útil compará-lo a uma versão (menos frustrante) do Word ou do recurso "Controlar alterações" do InDesign. Na minha experiência, isso definitivamente reduz a necessidade de uma pessoa dizer a outras pessoas para não tocar nos arquivos X, Y e Z pelas próximas horas, o que é útil para fazer as coisas.

Também achei as informações detalhadas da versão incrivelmente úteis para corrigir / solucionar bugs. Eu escondo o número da versão do SVN (através da propriedade $ Id) em quase todos os arquivos de dados que eu gerar. Dessa forma, se (quando?) Um bug for encontrado, é trivial identificar arquivos com possíveis problemas e regenerá-los ou ter outro código para compensá-lo.

Se você não usa o controle de versão, como sabe como reconstruir seu ambiente de produção?

1 Pessoas diferentes (testadores, desenvolvedores) procurarão as mesmas informações em lugares diferentes

levando a DUPLICATE DATA que fica fora de sincronia.
O controle de versão é a maneira mais fácil de eliminar dados duplicados.

2 Se você usar o controle de versão, é fácil garantir que o ambiente de produção corresponda ao que está no controle de versão.

Isso facilita a detecção de um problema devido a uma compilação incorreta (o prod não corresponde ao controle de versão) ou a um erro de design ou codificação (o prod corresponde ao controle de versão).

O controle de versão facilita a atribuição de um número de release a cada ambiente de teste e você naturalmente espera que a produção tenha um número de release menor que teste ou desenvolvimento e teste para ter um número de release menor que o desenvolvimento. Se não fosse esse o caso, parte do código não foi testada corretamente.

Além disso, se você lançar um software, o seguinte recurso de um VCS é bastante essencial: Suponha que seu cliente encontre um erro. O desenvolvimento atual do software provavelmente está em um estado muito diferente da versão que o cliente possui. Talvez o bug esteja corrigido agora, talvez não, mas, de qualquer forma, o software atual não está em um estado em que você possa enviá-lo ao cliente.

Um VCS torna trivial voltar à versão que foi enviada ao cliente, corrigir o bug que ele estava solicitando, compilar e enviar a ele uma versão revisada. Tudo isso sem atrapalhar o desenvolvimento atual, sem ter que enviar a ele uma versão com recursos inacabados / instáveis ​​ou bugs adicionais introduzidos devido ao novo desenvolvimento inacabado.

Além disso, um VCS facilita a portabilidade dessa correção para o novo ramo de desenvolvimento, se o bug ainda estiver presente lá também.

Por forte disciplina, você provavelmente pode gerenciar isso sem um VCS para uma equipe muito pequena, mas o uso de uma economizará tempo e dinheiro. Muito provavelmente, também ajudará você a manter seus clientes.

Se sua empresa possui mais de duas pessoas, provavelmente você tem um documento do Word ou Excel localizado em algum lugar editado por várias pessoas. E, às vezes, essas pessoas fazem cópias locais, fazem viagens de negócios etc. Ou o documento é enviado por e-mail após cada alteração.

Se você tiver esse arquivo, as modificações de algumas pessoas foram perdidas no passado ou serão perdidas no futuro. Ou as pessoas pensam que perderam mudanças, mas não podem provar. Ou eles gostariam de ver quem fez o que mudou quando e por que. Esse é exatamente o problema que um VCS resolve.

Ao escolher software / bibliotecas de código aberto, ter o repositório DVCS é definitivamente uma vantagem nos critérios de seleção.

1) Podemos clonar todo o repositório, não precisa se preocupar com o projeto ou seu site está morto.

2) As pessoas estão mais dispostas a enviar correções de bugs via solicitação pull, resultando em uma correção de bugs mais rápida para problemas urgentes.