¿Es una forma fácil de involucrar a los no programadores (es decir, los diseñadores) en el uso del control de versiones?

13

¿Cuáles son algunas formas clave de involucrar a su equipo en el uso del control de versiones durante el desarrollo, el desarrollo web u otros?

Me niego a trabajar sin él, lo que significa que cualquier persona involucrada en el proyecto también debe usarlo. Es solo una buena práctica.

Las interfaces gráficas de usuario como Tower han ayudado, pero el concepto se enfrentó con enojo (actitud de 'no es mi trabajo'), timidez o simplemente no lo usó (utilizando FTP en su lugar, eludiendo el control de versiones para, por ejemplo, desarrollo o implementación )

Editar: debería haber aclarado un poco que no solo me refiero a imágenes / PSD.

version-control teamwork

— Kevin
fuente

11

Haga que sea FÁCIL de usar ...

1

Me parece que Git es bastante fácil una vez que pasas unos días con él, y tienes un consenso sobre cómo debería ser el desarrollo ... todavía ha sido un obstáculo más grande para otros.

— Kevin

2

Algo para recordar es que el control de versiones y la copia de seguridad a veces se combinan (aunque son muy diferentes) y para un diseñador con datos binarios; La copia de seguridad ya puede ser la norma y, por lo tanto, es necesario comprender lo que está ganando.

— Aaron McIver

1

@Kevin: Lo que es fácil, obvio e intuitivo para un programador no es necesariamente algo por el estilo para otras personas, incluso para otras personas inteligentes y creativas.

— David Thornley

1

Comprometerse con un diseñador y luego involucrarla en privado en el control de versiones. :)

11

Trabajo en un equipo de desarrolladores y diseñadores y todos usamos el control de versiones. Para los diseñadores, apesta.

Compartir archivos / copia de seguridad siempre es igual al Control de versiones

Cuando tu dices:

Me niego a trabajar sin él, lo que significa que cualquier persona involucrada en el proyecto también debe usarlo. Es solo una buena práctica.

Debe tener en cuenta las dificultades del uso del control de versiones con datos binarios:

Sobrescritura : si dos diseñadores están trabajando en el mismo archivo, el segundo para confirmar sobrescribirá los primeros cambios como la versión actual. La única forma de evitar esto es bloquear o mantener una comunicación constante sobre quién está haciendo qué y qué archivo, lo que puede dificultar el flujo de trabajo de su equipo.
Fusión : la fusión asistida por herramientas no existe en los datos binarios. La fusión manual es dolorosa y propensa a grandes cantidades de errores.
Hinchazón del repositorio: los sistemas VC almacenan solo líneas cambiadas para archivos de texto. Esto no es posible con datos binarios, ya que todo el archivo se verá diferente al sistema VC. Esto significa que si bien 20 versiones de archivo de texto de 10 KB solo pueden ocupar 20 KB, 20 versiones de un archivo de 1 MB probablemente tomarán más cerca de 20 MB. Un equipo de diseño de tamaño moderado puede generar fácilmente muchas revisiones en docenas de archivos binarios. Su departamento de TI pronto puede odiarlo por los requisitos de almacenamiento y posiblemente incluso por una mayor memoria / CPU que tendrá su servidor VC.

Usted y otros desarrolladores también pronto odiarán la duración de las actualizaciones o los pagos, a menos que haya configurado una organización de repositorio muy buena para evitar los archivos binarios.
Beneficio reducido : sus diseñadores rara vez volverán a las versiones anteriores de los archivos binarios, si es que alguna vez lo hacen, porque 1) no hay una manera fácil de verificar el contenido de una versión anterior 2) no hay una manera fácil de fusionarlo, y lo más importante, 3) No funciona de esa manera: se utilizan para crear versiones alternativas de algunos gráficos que aún pueden ser útiles en los archivos de producción.

Para su código, debería estar usando VC y tiene razón al exigirlo.

Pero debe verificar la suposición de que eso significa que todos también deben estar usándolo, así como si es incluso una buena práctica para los diseñadores (aunque lo es el respaldo). Debe almacenar los activos gráficos finales requeridos por su sitio web / aplicación en su VC, pero para los archivos de producción, puede que no sea la solución correcta.

— Nicole
fuente

Con respecto a la "hinchazón del repositorio": puede intentar solucionarlo con los formatos de archivo correctos. La documentación almacenada en un formato de lenguaje de marcado de documentos y los gráficos almacenados en un formato de lenguaje de marcado de gráficos en lugar de los formatos binarios equivalentes pueden ayudar mucho. Por supuesto, la viabilidad de esto depende del proyecto en cuestión y de la disposición y competencia de las personas involucradas. ;)

— Baelnorn

55

La sobrescritura no ocurre en VCS que valga la pena. Lo que sucede es que tienes dos versiones del mismo archivo. Sí, el HEAD del repositorio tendrá el último guardado; pero el trabajo del otro diseñador no se pierde como si estuviera en un disco duro compartido. Creo que es una distinción importante.

— Berin Loritsch

2

@Berin: Eso es cierto, pero uno de los beneficios del VCS moderno es que dos personas pueden trabajar en lo mismo al mismo tiempo y gran parte del trabajo de reconciliación es automático. Sin embargo, con un archivo binario donde no hay un proceso de fusión significativo, eso no es posible. Además, el jefe del repositorio es el que la gente considerará "real".

— jprete

1

Como el ciclo de vida del código fuente y la documentación de diseño difiere, asegúrese de utilizar repositorios separados para ellos. No estoy de acuerdo en que los repositorios apestan para los diseñadores; La mayor parte del tiempo se dedica a pensar y modelar, sin hacer muchos cambios pequeños en los documentos. También establecemos una regla para no permitir la fusión automática (en todos los archivos almacenados en los repositorios) y, por lo tanto, tenemos un bloqueo obligatorio de archivos para las ediciones. Combinado con una buena comunicación en equipo, esto evita muchos de los inconvenientes que mencionas.

— rsp

1

Estás bastante equivocado, por ejemplo: sobrescribir : esto no es un problema de control de versiones, por el contrario, te ayuda a detectarlo. Los sistemas de VC almacenan solo líneas cambiadas para archivos de texto. - Falso para git.

— maaartinus

4

Me niego a trabajar sin él, lo que significa que cualquier persona involucrada en el proyecto también debe usarlo. Es solo una buena práctica.

Esa es una GRAN actitud, ¡a la altura de 'no es mi trabajo!' :-)

La mejor manera de obtener la aceptación es usar algo como TortoiseGit o TortoiseSVN para integrar el control de versiones en Explorer (suponiendo que Windows). Lleva tiempo ver un beneficio real si no está acostumbrado al paradigma de control de versiones. Tortoise al menos facilita el trabajo con VCS con el mouse. Un simple "clic derecho -> Registro" es todo lo que se necesita.

Por esta razón, he estado buscando implementar un control de versión transparente en TortoiseGit en cada archivo cerrado. Si le das a alguien una rama para trabajar, y luego cada escritura / cierre se convierte en una operación de compromiso, entonces en algún momento tú, como desarrollador, puedes fusionar su rama sin preocuparse por la consistencia de todo el repositorio, y pueden continuar con el negocio de hacer lo que hacen sin tener que saber sobre el control de versiones.

Tengo el mismo problema con un gran conjunto de documentos de auditoría que no puedo hacer que las personas controlen la versión, por lo que tenemos 50 versiones del mismo documento flotando que son sutilmente diferentes.

— Chris K
fuente

4

La forma de abordar esto es configurar un sistema de compilación (como Hudson ) que utiliza el sistema de control de versiones para recuperar las fuentes de compilación y convertirlo en una regla de proyecto que solo los artefactos que entrega el sistema de compilación van al equipo de prueba y finalmente implementado en el sitio del cliente.

Deje muy claro que, en lo que respecta al proceso del proyecto, todo lo que no provenga de la compilación es privado solo para los desarrolladores; mientras el trabajo de alguien no sea aceptado en la compilación, bien podría no existir.

— rsp
fuente

2

Ilustra las ventajas:

Muéstreles cómo pueden ahorrar tiempo al permitir que todos compartan trabajo y acceso a una ubicación central.
Muéstreles cómo les permite a los diseñadores trabajar en diferentes partes del proyecto al mismo tiempo y fusionarlas nuevamente.
Muéstreles cómo pueden etiquetar y crear una versión anterior de una aplicación para probar o solucionar problemas.
Muéstreles cómo pueden jugar con un diseño para experimentar y luego actualizar el proyecto y no guardar los cambios si no lo desean.
Muéstreles cómo pueden ver lo que ha sucedido con el tiempo.

— jzd
fuente

1

-1 Se trataba de involucrar a no programadores; la lista aparece orientada a un programador. Si modifica su respuesta, ciertamente eliminaré el voto

— negativo

1

Creo que te perdiste la parte "para no programadores". Todas las tareas que mencionó son tareas de programador.

— Erik Funkenbusch

Lo siento, acabo de leer la pregunta, no el título. Editaré la respuesta.

— jzd

1 Eliminado ...

— Aaron McIver

1

"No es mi trabajo" sobre el control de versiones es una actitud sensata de un no programador.

Cree un sistema de control de versiones tan simple e invisible como Dropbox para la sincronización o Time Machine para la copia de seguridad.

Simplemente debería funcionar. Sin pago, sin compromiso. Simplemente ponga los archivos en la carpeta del proyecto.

— Mouviciel
fuente

1

He estado usando tortoiseHG / mercurial con la nueva dama del sitio web, sin problemas. No tener que pagar es muy simple y ejerce toda la presión sobre la persona que realmente debe asegurarse de que los archivos estén sincronizados. Ni siquiera parece "una cosa más que hacer", es solo, "ok, voy a hacer una demostración del sitio web, así que tengo que pedirle a Peter que vuelva a sincronizar los cambios". Y eso no es problema.

No tenía experiencia con mercurial antes, usamos VSS y nunca hubiera deseado eso en nadie para el control de la fuente del sitio web. Lo intenté una vez y no culparía a nadie por no querer usarlo en ese momento.

— Peter Turner
fuente

0

Yo diría que el uso de los clones de tortuga *, es lo más simple que se pone. O integre el control de versiones, en el IDE o lo que sea.

— Coyote21
fuente