Un buen ejemplo de alguien que se ajusta a esa descripción podría ser un gerente de proyecto.

Mi jefe me preguntó el otro día: "¿Qué es esto de Github y por qué es importante?" Tiene algunos proyectos patentados, por lo que necesitaría un alojamiento privado y me encontré luchando por explicar más allá de lo habitual: los VCS hacen que la colaboración sea trivial, proporcionan un historial y una "copia de seguridad" de todos sus datos y le permiten registrar cambios atómicos en una base de código . En mi opinión, estaba pensando, "es casi como si tuviera que usar un DRVS para comprender realmente lo beneficioso que es".

Terminé apuntándolo a BitBucket porque te dan repositorios privados ilimitados (incluso tuve que explicar qué era un repositorio).

¿Alguien tiene realmente buenos ejemplos concretos de cómo un VCS les salvó el culo o les hizo la vida más fácil, etc., básicamente, cómo venderían un DVSC a alguien que no esté familiarizado con la programación, pero que no sea un programador de profesión?

El control de versiones es excelente para (al menos) tres cuatro cosas: copia de seguridad, compartir código entre desarrolladores, encontrar + corregir errores y rastrear el progreso.

1. Copia de seguridad . Si nada más, es una copia de seguridad con esteroides. Tiene todo el historial de desarrollo, cada confirmación es una instantánea de todo su código con una identificación (número de revisión), una descripción, marca de tiempo, información del usuario. Y es simple comparar archivos entre revisiones. Por lo menos, es más rápido que una simple copia de seguridad (solo se envían y almacenan los cambios de archivo) y contiene metadatos mucho más útiles. ¿Por qué reinventar esto?

2. Compartir código entre desarrolladores . Si tiene al menos dos desarrolladores trabajando en el mismo producto simultáneamente, no veo otra forma de compartir cambios de código de manera confiable y consistente y fusionarlos. ¿Enviar cremalleras por correo?

3. Encontrar y corregir errores . Cuando sus clientes informan un error para una versión específica del producto, puede obtener rápidamente la instantánea de origen real para reproducirla y corregirla. Es difícil reproducir errores si su fuente es diferente de la del cliente. ¿Les pides que envíen el ejecutable para que puedas desmontarlo? Además, si tiene problemas para identificar la causa de un error, puede usar VCS para determinar la revisión exacta donde se introdujo.

4. Seguimiento de progreso . Cuando compromete su trabajo en instantáneas, le permite a usted (y a su gerente) realizar un seguimiento del progreso en las implementaciones de funciones y el estado de los errores abiertos. Los sistemas de VC también se integran fácilmente con sistemas de seguimiento y sistemas de integración continua . Es casi imposible mantener un nivel de calidad para cualquier otra cosa que no sea un proyecto de pasatiempo, a menos que tenga un VCS.

Una vez que todos estén de acuerdo que ningún desarrollo de software debe siempre ser hecho fuera de un VCS (yo no lo perdería incluso para un proyecto de pasatiempo), entonces se puede hablar de características de un (un poco más complicado) DVCS (la parte siguiente descaradamente copiados de Wikipedia ):

• Cada usuario tiene su propia copia local del repositorio (y efectivamente, una copia de respaldo)
• Permite a los usuarios trabajar productivamente incluso cuando no están conectados a una red
• Hace que la mayoría de las operaciones sean mucho más rápidas ya que no hay red involucrada
• Permite la participación en proyectos sin requerir permisos de las autoridades del proyecto.
• Permite el trabajo privado, por lo que los usuarios pueden usar su sistema de control de revisiones incluso para borradores iniciales que no desean publicar
• Evita confiar en una sola máquina física como un único punto de falla

"¿Alguna vez has encontrado útil el botón 'deshacer'? Oh, ¿entonces estás de acuerdo en que deberíamos usar un control de versión?"

Cuando comencé a usar el control de versiones, la característica principal que me interesaba era la capacidad de "deshacer" mis errores y volver a una versión anterior. Todos pueden apreciar un botón de deshacer. El control de versiones concedido puede hacer mucho más.

Comience con lo básico:

En primer lugar, un VCS protege a los desarrolladores de sí mismos y de los demás: si no tiene otro propósito que permitir que dos o más desarrolladores trabajen en la misma base de código de manera relativamente segura, sería de gran valor (y he estado en un equipo donde el anterior días de trabajo ha sido sobrescrito por un poco de copia descuidada).

En segundo lugar, proporciona una pista de auditoría, un historial, puede regresar y ver quién cambió qué y cuándo y puede regresar y recuperar el código que eliminó porque ya no era necesario o apropiado cuando resulta que será necesario después todos.

En tercer lugar, le da un punto de referencia: la fuente definitiva es el código comprometido (en el mundo real es un poco más complicado, especialmente con DVCS, pero en aras de esta discusión está lo suficientemente cerca). Si tiene una copia de seguridad adecuada del repositorio, debe proteger los activos de la empresa.

Esas tres cosas deberían ser "eso" para vender VCS, si un gerente no puede ver el valor suficiente en el tiempo anterior para encontrar otro gerente.

Una vez que haya vendido VCS (que, después de todo, solo son útiles para los equipos de desarrollo donde el número de desarrolladores es mayor que cero), entonces la pregunta de por qué DVCS pasó, por ejemplo, SVN o TFS y la pregunta adicional de si trabajar en casa o para usar un servicio alojado como Kiln o Bitbucket o Github (que es privado si paga) es bastante más profundo y más dependiente del contexto.

VCS

Simplemente explique el concepto de copias de seguridad . Las copias de seguridad le permiten ver en qué había estado trabajando en un momento dado. Diga cómo antes los programadores de VCS solían copiar compulsivamente sus proyectos completos, generalmente para guardar cada versión buena y estable que tenían, de modo que cuando las cosas salían mal tenían un buen punto de referencia de cuándo funcionaban las cosas, compárelas con las últimas novedades y vea dónde ellos o alguien más se equivocaron y lo arreglaron más fácilmente con solo mirar las diferencias en lugar de las dos copias de seguridad completas del proyecto.

En resumen : los VCS le permiten guardar copias de seguridad de su trabajo y le permiten ver solo las diferencias entre las copias de seguridad.

DVCS

En cuanto al control de versiones distribuido, explique cómo el control de versiones típico solía necesitar un servidor y una conexión a Internet y que todos se cansaron de eso porque era más lento y todos trabajaban en una sola copia de seguridad, si uno lo estropeaba, el proyecto se arruinaba para todos, Por lo tanto, con el control de versión distribuido, todos pueden trabajar en su propia copia de seguridad en su máquina sin una conexión a Internet, y todos están contentos porque nadie se mete con su copia de seguridad mientras trabajan y pueden preocuparse por compartir su trabajo más tarde cuando hayan terminado.

Otra buena es que, a diferencia de un VCS centralizado donde solo hay una copia de seguridad, si la máquina con la copia de seguridad se incendia, todavía hay otras copias de seguridad completas (al menos una para cada desarrollador).

En resumen : los DVCS le permiten trabajar en su propia copia de seguridad sin que todos tengan que estar metidos en un solo servidor molestando entre sí, y le permiten preocuparse por los cambios de los demás una vez que haya terminado con sus cosas. Además, no sucede nada si la máquina del repositorio principal se incendia .

Trabajo principalmente con ingenieros (no desarrolladores per se, pero escriben código)

El punto principal, cuando les explico sobre el control de versiones, es la posibilidad de deshacer y administrar su código / documentación / lo que sea y simplificar la colaboración con otros desarrolladores / escritores / etc.

Ese es un buen punto de venta, y fue la razón principal por la que usé un VCS para todo mi trabajo, también las otras ventajas: tener un historial, un repositorio que se pueda respaldar fácilmente ...

A la mayoría de ellos les gusta la idea y la encuentran bastante útil, adoptándola para sus proyectos (especialmente si implican la colaboración con otros ingenieros).

Cuando intentas convencer a alguien de algo, siempre debes tratar de hacerlo desde su punto de vista.

Su gerente de proyecto tiene un objetivo simple: completar proyectos a tiempo y dentro del presupuesto.

Si actualmente no está utilizando el control de versiones, su equipo de desarrollo está resolviendo los problemas que el control de versiones resuelve a mano. Todos esos problemas han sido bien enumerados por otras respuestas, por lo que no los abordaré aquí.

Lo que debe hacer es explicarle a su gerente de proyecto que el equipo dedica Xvarias horas a la semana a resolver manualmente los problemas que GIT podría resolver automáticamente, o en, digamos, la 0.1 * Xcantidad de horas de desarrollador.

No lo aborde utilizando razones por las que GIT le facilitará la vida o la vida de sus compañeros desarrolladores, acéptelo desde la perspectiva de que GIT enviará software más rápido y más barato.

Me gusta la descripción de @ Buttons840 como un botón de deshacer para la base del código. También podría ser útil compararlo con una versión (menos frustrante) de Word o la función "Seguimiento de cambios" de InDesign. En mi experiencia, definitivamente reduce la necesidad de que una persona vaya y diga a otros que no toquen los archivos X, Y y Z durante las próximas horas, lo que es útil para hacer las cosas.

También he encontrado que la información de la versión detallada es increíblemente útil para corregir / solucionar errores. Guardo el número de versión SVN (a través de la propiedad $ Id) en casi todos los archivos de datos que genero. De esa manera, si (¿cuándo?) Se encuentra un error, es trivial identificar archivos con problemas potenciales y regenerarlos o hacer que otro código compense el error.

Si no utiliza el control de versiones, ¿cómo sabe cómo reconstruir su entorno de producción?

1 Diferentes personas (probadores, desarrolladores) buscarán la misma información en diferentes lugares

que conduce a DATOS DUPLICADOS que se desincronizan.
El control de versiones es la forma más fácil de eliminar datos duplicados.

2 Si utiliza el control de versiones, es fácil asegurarse de que el entorno de producción coincida con el control de versiones.

Esto facilita la detección de si un problema se debió a una mala construcción (el producto no coincide con el control de versión) o un error de diseño o codificación (el producto sí coincide con el control de versión).

El control de versiones facilita la asignación de un número de versión a cada entorno de prueba y, naturalmente, esperaría que la producción tenga un número de versión más bajo que la prueba o el desarrollo, y que la prueba tenga un número de versión más bajo que el desarrollo. Si este no fuera el caso, alguna parte del código no se ha probado correctamente.

Además, si libera software, la siguiente característica de un VCS es bastante esencial: suponga que su cliente encuentra un error. El desarrollo actual del software probablemente se encuentre en un estado muy diferente al de la versión que tiene el cliente. Tal vez el error ya está solucionado, tal vez no, pero en cualquier caso el software actual no está en un estado en el que pueda enviarlo al cliente.

Un VCS hace que sea trivial volver a la versión que se envió al cliente, corregir el error que estaba solicitando, construirlo y enviarle una versión revisada. Todo esto sin perturbar el desarrollo actual, sin tener que enviarle una versión con características inacabadas / inestables o errores adicionales introducidos debido al nuevo desarrollo inacabado.

Además, un VCS facilita la transferencia de esta solución a la nueva rama de desarrollo si el error todavía está presente allí.

Con una disciplina fuerte, probablemente pueda manejar esto sin un VCS para un equipo muy pequeño, pero usar uno le ahorrará tiempo y, al final, dinero. Lo más probable es que también lo ayude a mantener a sus clientes.

Si su empresa tiene más de dos personas, entonces probablemente tenga un documento de Word o un documento de Excel en algún lugar editado por varias personas. Y a veces esas personas hacen copias locales, para realizar un viaje de negocios, etc. O el documento se envía por correo electrónico después de cada cambio.

Si tiene un archivo así, las modificaciones de algunas personas se han perdido en el pasado o se perderán en el futuro. O la gente piensa que ha perdido los cambios, pero no puede probarlo. O les gustaría ver quién hizo qué cambio cuándo y por qué. Ese es exactamente el problema que resuelve un VCS.

Al elegir bibliotecas / software de código abierto, tener un repositorio DVCS es definitivamente una ventaja en los criterios de selección.

1) Podemos clonar todo el repositorio, no tenemos que preocuparnos por el proyecto o su sitio web está muerto.

2) Las personas están más dispuestas a enviar una corrección de errores a través de una solicitud de extracción, lo que resulta en una corrección de errores más rápida para problemas urgentes.