Maneira fácil de envolver não programadores (ou seja, designers) no controle de versão?

Quais são algumas das principais maneiras de envolver sua equipe no uso do controle de versão durante o desenvolvimento, desenvolvimento web ou outro?

Recuso-me a trabalhar sem ele, o que significa que qualquer pessoa envolvida no projeto também deve usá-lo. É apenas uma boa prática.

GUIs como o Tower ajudaram, mas o conceito dele é recebido com raiva ('não é o meu trabalho!', Meio que atitude), timidez ou simplesmente não o usa (usando FTP em vez disso, contornando o controle de versão para dizer, desenvolvedor ou implantação) )

Edit: Eu deveria ter esclarecido um pouco que não me refiro apenas a imagens / PSDs.

Trabalho em uma equipe de desenvolvedores e designers e todos usamos o controle de versão. Para os designers, é uma merda.

O compartilhamento / backup de arquivo sempre é igual ao Controle de Versão

Quando voce diz:

Recuso-me a trabalhar sem ele, o que significa que qualquer pessoa envolvida no projeto também deve usá-lo. É apenas uma boa prática.

Você precisa estar ciente das armadilhas do uso do controle de versão com dados binários:

• Substituição : Se dois designers estiverem trabalhando no mesmo arquivo, o segundo a confirmar substituirá as alterações da primeira como a versão atual. A única maneira de evitar isso é o bloqueio ou a comunicação constante sobre quem está fazendo o que com qual arquivo, os quais podem prejudicar o fluxo de trabalho de sua equipe.
• Mesclagem : a mesclagem assistida por ferramenta é inexistente em dados binários. A fusão manual é dolorosa e propensa a grandes quantidades de erros.

• Inchaço do repositório: Os sistemas de VC armazenam apenas linhas alteradas para arquivos de texto. Isso não é possível com dados binários, pois o arquivo inteiro terá uma aparência diferente do sistema do VC. Isso significa que, enquanto 20 versões de um arquivo de texto de 10 KB podem ocupar apenas 20 KB, 20 versões de um arquivo de 1 MB provavelmente levarão mais perto de 20 MB. Uma equipe de design de tamanho moderado pode gerar facilmente muitas revisões em dezenas de arquivos binários. Seu departamento de TI poderá em breve odiá-lo pelos requisitos de armazenamento e, possivelmente, até mais memória / CPU que seu servidor de VC terá.

  Você e outros desenvolvedores também podem odiar em breve quanto tempo demoram os checkouts ou atualizações, a menos que você configure uma organização de repositório muito boa para evitar os arquivos binários.

• Benefício reduzido : Seus designers raramente, se alguma vez, retornam às versões anteriores de arquivos binários, porque 1) não é uma maneira fácil de verificar o conteúdo de uma versão anterior 2) não é uma maneira fácil de mesclá-lo de qualquer maneira e, o mais importante, 3) eles não funcionam dessa maneira - eles são usados ​​para criar versões alternativas de alguns gráficos que ainda podem ser úteis nos próprios arquivos de produção.

Para o seu código, você absolutamente deve usar o VC e tem razão em exigi-lo.

Mas você precisa verificar a suposição de que isso significa que todos também devem usá-lo, e também se é uma boa prática para designers (embora o backup seja). Você deve armazenar os recursos gráficos finais exigidos pelo seu site / aplicativo no seu VC, mas, para arquivos de produção, pode não ser a solução certa.

Recuso-me a trabalhar sem ele, o que significa que qualquer pessoa envolvida no projeto também deve usá-lo. É apenas uma boa prática.

Essa é uma ótima atitude, lá em cima com 'não é o meu trabalho!' :-)

A melhor maneira de obter adesão é usar algo como o TortoiseGit ou o TortoiseSVN para integrar o controle de versão ao Explorer (assumindo o Windows). Leva tempo para obter benefícios reais se você não estiver acostumado ao paradigma de controle de versão. Tartaruga, pelo menos, facilita o trabalho com VCS com o mouse. Basta um simples "clique direito -> check-in".

Por esse motivo, tenho procurado implementar um controle de versão transparente no TortoiseGit em todos os arquivos fechados. Se você fornecer a alguém um ramo no qual trabalhar e cada gravação / fechamento se tornar uma operação de confirmação, em algum momento você, como desenvolvedor, poderá mesclar o seu ramo sem se preocupar com a consistência de todo o repositório, e eles poderão continuar com o negócios de fazer o que fazem sem ter que saber sobre o controle de versão.

Eu tenho esse mesmo problema com um enorme conjunto de documentos de auditoria que não consigo levar as pessoas ao controle de versão; portanto, temos 50 versões do mesmo documento flutuando que são sutilmente diferentes.

A maneira de abordar esta questão é configurar um sistema de compilação (como Hudson ), que usa o sistema de controle de versão para recuperar as fontes de compilação e torná-lo uma regra de projeto que apenas artefactos que são um entregues pelo sistema de compilação está indo para a equipe de teste e eventualmente implantado no site do cliente.

Deixe bem claro que, no que diz respeito ao processo do projeto, qualquer coisa que não venha da compilação é privada apenas para os desenvolvedores; contanto que o trabalho de alguém não seja aceito na compilação, é possível que não exista.

Ilustre as vantagens:

• Mostre a eles como eles podem economizar tempo, permitindo que todos compartilhem trabalho e acessem um local central.
• Mostre a eles como isso permite que os designers trabalhem em diferentes partes do projeto ao mesmo tempo e os mesclem novamente.
• Mostre a eles como eles podem marcar e criar uma versão mais antiga de um aplicativo para teste ou solução de problemas.
• Mostre a eles como eles podem mexer com um design para experimentação e, em seguida, atualize o projeto e não mantenha as alterações, se não quiserem.
• Mostre-lhes como eles podem ver o que aconteceu ao longo do tempo.

"Não é meu trabalho" sobre controle de versão é uma atitude sensata de um não programador.

Crie um sistema de controle de versão tão simples e invisível quanto o Dropbox para sincronização ou o Time Machine para backup.

Deveria funcionar. Sem check-out, sem confirmação. Basta colocar os arquivos na pasta do projeto.

Estou usando o tortoiseHG / mercurial com a nova senhora do site, sem problemas por lá. Não fazer check-out torna tudo muito simples e pressiona a pessoa que realmente precisa garantir que os arquivos sejam sincronizados. Nem parece "mais uma coisa a fazer", é apenas "ok, vou fazer uma demonstração no site, então preciso pedir a Peter para ressincronizar as alterações". e isso não é problema.

Eu não tinha experiência com mercurial antes, usamos o VSS e eu nunca desejaria isso a ninguém pelo controle de origem do site. Eu tentei uma vez e não culpo ninguém por não querer usá-lo.

Eu diria que o uso de clones de tartaruga * é mais simples. Ou integre o controle de versão, no IDE ou o que for.