Un modo semplice per coinvolgere i non programmatori (cioè i designer) nell'uso del controllo di versione?

Lavoro con un team di sviluppatori e designer e usiamo tutti il controllo della versione. Per i designer, fa schifo.

La condivisione / backup di file equivale sempre al controllo della versione

Quando dici:

I refuse to work without it, which means anyone involved in the project must also use it. It's just good practice.

Devi essere consapevole delle insidie nell'usare il controllo della versione con dati binari:

• Sovrascrittura : se due designer stanno lavorando sullo stesso file, il secondo da sovrascrivere sostituirà le prime modifiche come versione corrente. L'unico modo per impedirlo è il blocco o la comunicazione costante su chi sta facendo cosa su quale file, entrambi possono ostacolare il flusso di lavoro del proprio team.
• Unione : la fusione assistita dagli strumenti non esiste nei dati binari. La fusione manuale è dolorosa e soggetta a enormi quantità di errori.

• Gonfiamento del repository: i sistemi VC memorizzano solo le righe modificate per i file di testo. Questo non è possibile con i dati binari, poiché l'intero file apparirà diverso dal sistema VC. Ciò significa che mentre 20 versioni di file di testo da 10 KB possono occupare solo 20 KB, 20 versioni di un file da 1 MB probabilmente impiegheranno più vicino a 20 MB. Un team di progettazione di dimensioni moderate può facilmente generare molte revisioni su dozzine di file binari. Il tuo dipartimento IT potrebbe presto odiarti per i requisiti di archiviazione e forse anche per l'aumento di memoria / CPU del tuo server VC.

  Tu e altri sviluppatori potresti anche non gradire quanto a lungo potrebbero essere necessari i checkout o gli aggiornamenti, a meno che tu non abbia configurato un'ottima organizzazione di repository per evitare i file binari.

• Vantaggio ridotto : i tuoi progettisti raramente, se non mai, tornano alle versioni precedenti dei file binari, perché 1) non è un modo semplice per controllare i contenuti di una versione precedente 2) non è facile per fonderlo comunque, e soprattutto, 3) non funzionano in questo modo - sono usati per creare versioni alternative di alcuni elementi grafici che possono ancora essere utili nei file di produzione stessi.

Per il tuo codice, dovresti assolutamente utilizzare VC e hai ragione a richiederlo.

Ma devi controllare che questo significhi che tutti devono usarlo, e anche se è una buona pratica per i progettisti (anche se il backup è). Dovresti conservare le risorse grafiche finali richieste dal tuo sito web / applicazione nel tuo VC, ma per i file di produzione potrebbe non essere la soluzione giusta.

I refuse to work without it, which means anyone involved in the project must also use it. It's just good practice.

È un atteggiamento GRANDE, proprio lì con "non il mio lavoro!" :-)

Il modo migliore per ottenere il buy-in è usare qualcosa come TortoiseGit o TortoiseSVN per integrare il controllo della versione in Explorer (assumendo Windows). Ci vuole tempo per vedere un vantaggio reale se non si è abituati al paradigma del controllo della versione. La tartaruga, perlomeno, facilita il lavoro con VCS con il mouse. Un semplice "clic destro - > Checkin" è tutto ciò che serve.

Per questo motivo, ho cercato di implementare il controllo della versione trasparente in TortoiseGit su ogni file chiuso. Se offri a qualcuno un ramo su cui lavorare, e poi ogni scrittura / chiusura diventa un'operazione di commit, poi ad un certo punto tu come lo sviluppatore puoi unire il loro ramo senza preoccuparti della consistenza dell'intero repository, e possono andare avanti con il affari di fare quello che fanno senza dover sapere sul controllo della versione.

Ho lo stesso problema con un enorme set di documenti di controllo che non riesco a convincere le persone a controllare la versione, quindi abbiamo 50 versioni di questo stesso documento che galleggiano in modo tutto sottilmente diverso.

Il modo di avvicinarsi a questo è configurare un sistema di build (come Hudson ) che utilizza il sistema di controllo della versione per recuperare i sorgenti di compilazione e ne fa una regola di progetto che solo artefatti che sono consegnati dal sistema di build stanno andando al team di test e infine schierati sul sito del cliente.

Spiega chiaramente che per quanto riguarda il processo del progetto, tutto ciò che non proviene dalla build è privato solo per gli sviluppatori; finché il lavoro di qualcuno non viene accettato nella build, potrebbe anche non esistere.

Illustrare i vantaggi:

• Mostra loro come possono risparmiare tempo consentendo a tutti di condividere il lavoro e accedere a una posizione centrale.
• Mostra loro come consente ai designer di lavorare contemporaneamente su diverse parti del progetto e unirlo di nuovo.
• Mostra loro come possono taggare e creare versioni precedenti di un'applicazione per test o risoluzione dei problemi.
• Mostra loro come possono creare confusione con un progetto per la sperimentazione e quindi aggiornare il progetto e non conservare le modifiche se non lo desiderano.
• Mostra loro come possono vedere cosa è successo nel tempo.

"Non è il mio lavoro" sul controllo della versione è un atteggiamento sensato da un non programmatore.

Costruisci un sistema di controllo delle versioni semplice e invisibile come Dropbox per la sincronizzazione o Time Machine per il backup.

Dovrebbe funzionare. Nessun checkout, nessun commit. Basta mettere i file nella cartella del progetto.

Ho usato tortoiseHG / mercurial con la nuova signora del sito web, nessun problema lì. Non avere checkout rende la cosa molto semplice e mette tutta la pressione sulla persona che deve assicurarsi che i file siano sincronizzati. Non sembra nemmeno "un'altra cosa da fare", è solo, "ok ho intenzione di demo del sito web, quindi devo chiedere a Peter di risincronizzare le modifiche". e questo non è un problema.

Prima non avevo esperienza con Mercurial, usiamo VSS e non avrei mai voluto farlo a nessuno per il controllo del codice sorgente del sito web. L'ho provato una volta e non darei la colpa a nessuno per non volerlo usare poi.

Direi l'uso dei cloni di tartaruga *, è il più semplice che ottiene. O integrare il controllo della versione, nell'IDE o in qualsiasi modo.