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

1. Copia de seguridad . Si nada más, es copia de seguridad en los esteroides. Usted tiene el historial completo de desarrollo, cada confirmación es una instantánea de su código completo 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. Si nada más, es más rápido que una copia de seguridad simple (solo los cambios de archivos se envían y almacenan), 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 ninguna otra forma de compartir cambios de código de manera confiable y consistente y fusionarlos. ¿Enviando zip por correo?

3. Buscar 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 la fuente 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 desarmarlo? Además, si tiene problemas para identificar la causa de un error, puede usar VCS para identificar la revisión exacta donde se introdujo.

4. Seguimiento del progreso . Cuando confirma su trabajo en instantáneas, le permite a usted (y su administrador) realizar un seguimiento del progreso de las implementaciones de características y el estado de los errores abiertos. Los sistemas de VC también se integran fácilmente con los 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 hobby, a menos que tenga un VCS.

Una vez que todos hayan acordado que ningún desarrollo de software debería nunca hacerse fuera de un VCS (no me lo perdería ni por un proyecto de pasatiempo), entonces puede hablar sobre las características de un (un poco más) complicado) DVCS (la siguiente parte se copió descaradamente de Wikipedia ):

• Cada usuario tiene su propia copia local del repositorio (y, efectivamente, una copia de respaldo)
• Permite a los usuarios trabajar de manera productiva incluso cuando no está conectado 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 los primeros borradores que no desean publicar
• Evita depender de una sola máquina física como punto único de falla

"¿Alguna vez has encontrado útil el botón 'deshacer'? Oh, ¿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 posibilidad de "deshacer" mis errores y volver a una versión anterior. Todo el mundo puede apreciar un botón de deshacer. El control de versión 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 forma relativamente segura, sería de gran valor (y he estado en un equipo donde el trabajo de los días anteriores se ha sobrescrito con un poco de copia descuidada).

En segundo lugar, proporciona una pista de auditoría, un historial, puede volver atrás y ver quién cambió qué y cuándo, y puede retroceder y recuperar el código que eliminó porque ya no era necesario o apropiado cuando resulta que lo hará. Se necesita después de todo.

En tercer lugar, le proporciona 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 por el bien de esta discusión, está lo suficientemente cerca). Si tiene una copia de seguridad del repositorio, debería tener los activos de la empresa protegidos.

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

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

VCSs

Simplemente explica el concepto de copias de seguridad . Las copias de seguridad le permiten ver en qué ha estado trabajando en un momento dado. Explique cómo antes los programadores de VCS solían copiar sus proyectos completos de manera compulsiva, generalmente para guardar cada lanzamiento bueno y estable que tenían, de modo que cuando las cosas iban mal tenían un buen punto de referencia de cuándo funcionaban las cosas, compárelas con lo último y vean dónde ellos o alguien más lo hicieron mal y lo arreglaron más fácilmente solo mirando 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 dan la capacidad de ver solo las diferencias entre las copias de seguridad.

DVCSs

En cuanto al control de versiones distribuido, explique cómo el control de versiones típico solía usar 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 arruinó el proyecto para todos, así que con el control de versiones distribuido, todos pueden trabajar en su propia copia de seguridad en su máquina sin 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 adelante cuando terminen.

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 enciende, todavía quedan otras copias de seguridad completas (al menos una para cada desarrollador).

En resumen : DVCS le permite trabajar en su propia copia de seguridad sin que todos tengan que estar abarrotados en un solo servidor y se preocupen por otros cambios después de Tu has terminado con tus cosas. Además, no pasa nada si la máquina del repositorio principal se enciende .

Trabajo principalmente con ingenieros (no desarrolladores, pero sí 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 ...

Es un buen punto de venta, y fue la razón principal por la que usé un VCS para todo mi trabajo, y también las otras ventajas: tener un historial, un repositorio que se puede 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 involucran la colaboración con otros ingenieros).

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

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

Si actualmente no está usando 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 voy a entrar en ellos aquí.

Lo que debe hacer es explicarle a su gerente de proyecto que el equipo está gastando X número de horas cada semana para resolver manualmente los problemas que GIT podría resolver automáticamente, o en, digamos, 0.1 * X número de horas de desarrollador.

No se acerque a él por las razones por las que GIT hará que su vida sea más fácil o la de sus colegas desarrolladores, acérquese desde la perspectiva de que GIT enviará el software más rápido y más barato.

Me gusta la descripción de @ Buttons840 de esto como un botón de deshacer para el código base. También podría ayudar a 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 le diga a los demás que no toquen los archivos X, Y y Z durante las próximas horas, lo cual es útil para hacer las cosas.

También he encontrado que la información de la versión de grano fino 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 los archivos con problemas potenciales y regenerarlos o hacer que otro código compense el error.

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

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

lo que lleva 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 garantizar que el entorno de producción coincida con el control de versiones.

Esto hace que sea fácil detectar si un problema se debió a una mala compilación (prod. no coincide con el control de versión), o un error de diseño o codificación (prod no coincide con el control de versión).

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

También si libera software, la siguiente función 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 se haya solucionado ahora, 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, compilarlo y enviarle una versión revisada. Todo esto sin molestar el desarrollo actual, sin tener que enviarle una versión con características no finalizadas / inestables o errores adicionales introducidos debido al nuevo desarrollo sin terminar.

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

Por disciplina fuerte, probablemente puedas manejar esto sin un VCS para un equipo muy pequeño, pero usar uno te ahorrará tiempo y dinero al final. Lo más probable es que también te ayude a mantener a tus clientes.

Si su empresa tiene más de dos personas, es probable que 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 ir en viaje de negocios, etc. O el documento se envía por correo electrónico después de cada cambio.

Si tiene un archivo de este tipo, las modificaciones de algunas personas se han perdido en el pasado o se perderán en el futuro. O la gente cree que ha perdido los cambios, pero no puede demostrarlo. 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 software / bibliotecas 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) La gente está más dispuesta a enviar una solución de errores a través de una solicitud de extracción, lo que resulta en una solución de errores más rápida para problemas urgentes.