¿En qué momento se necesita el control de versión? [duplicar]

Como lo describe, ya tiene algún tipo de control de versión, aunque actualmente hay algunos problemas con él en comparación con un control de versión típico:

Un compromiso intencional en el control de versión indica que el desarrollador cree firmemente que el estado actual del sistema se construirá correctamente.

(Existen excepciones, como sugiere El comentario de Jacobm001 . De hecho, varios enfoques son posibles, y algunos equipos preferirían no tratar de hacer cada compromiso posible para construir. Uno es tener construcciones nocturnas, dado que durante el día, el sistema puede recibir varias confirmaciones que no se construyen.

Como no tiene confirmaciones, su sistema a menudo dará como resultado un estado que no se compila. Esto le impide configurar la integración continua .

Por cierto, un sistema de control de versiones distribuido tiene un beneficio: se pueden hacer confirmaciones locales tanto como sea necesario mientras se lleva el sistema a un estado donde no se puede compilar, y luego hacer una confirmación pública cuando el sistema es capaz de compilar .

1. El control de versiones le permite imponer algunas reglas en la confirmación . Por ejemplo, para los archivos de Python, se puede ejecutar PEP 8, lo que evita la confirmación si los archivos confirmados no son compatibles.

2. Culpa es extremadamente difícil de hacer con tu enfoque.

3. Explorando qué cambios se hicieron cuando y quién es difícil también. El control de versiones registros , la lista de archivos modificados y a diff es una excelente manera de encontrar exactamente lo que se hizo.

4. Cualquier combinación sería una molestia (o tal vez los desarrolladores ni siquiera verían que sus colegas estaban modificando los archivos antes de guardar los cambios). Usted declaró que:

     

   Es raro que dos programadores trabajen en el mismo proyecto

   Raro no significa nunca, por lo que las fusiones se producirían tarde o temprano.

5. Una copia de seguridad cada quince minutos significa que los desarrolladores pueden perder hasta quince minutos de trabajo . Esto siempre es problemático: es difícil recordar exactamente qué cambios se hicieron mientras tanto.

6. Con el control de código fuente puede tener mensajes de confirmación significativos. Con las copias de seguridad, todo lo que sabe es que fueron x minutos desde la última copia de seguridad.

Un control de versión real garantiza que siempre pueda volver al compromiso anterior; Esta es una gran ventaja. Revertir una copia de seguridad utilizando su sistema sería un poco más difícil que hacer una reversión de un clic , lo que puede hacer en la mayoría de los sistemas de control de versiones. Además, en su sistema, Ramificación es imposible.

Hay una mejor manera de hacer el control de versiones, y ciertamente deberías considerar cambiar la forma en que lo haces actualmente. Sobre todo porque, como Eric Lippert menciona a , su sistema actual es probablemente mucho más doloroso de mantener que cualquier sistema de control de versiones común. Tener un repositorio Git o Mercurial en una unidad de red es bastante fácil, por ejemplo.

Nota: Incluso si cambia a un sistema de control de versión común, debe tener una copia de seguridad diaria / semanal de los repositorios. Sin embargo, si está utilizando un sistema distribuido, es menos importante, ya que entonces cada copia de trabajo del desarrollador también es una copia de seguridad.

Mi opinión personal: el control de versiones es útil para cualquier cosa que me lleve más de medio día o que implique mucho ensayo y error, o ambos, por supuesto. Si involucra a dos o más personas que no usan el mismo teclado y monitor todo el tiempo, es esencial.

El costo de usar un sistema de versionamiento formal, más allá de la curva de aprendizaje inicial, es insignificante. ¿Inicializando un repositorio? Dos segundos. ¿Agregando archivos? Un segundo. ¿Poder volver a lo que intenté esta mañana y discutir lo que descarté con mi colega? Vale la pena horas o días, fácilmente.

El control de versiones siempre fue necesario, incluso antes de que piratearan tu "pero, ¡hacemos copias de seguridad muy a menudo!" kludge.

El control de versiones le permite publicar esos cambios en archivos que pertenecen a una función lógica como una unidad. Si necesita revisar "¿qué era necesario para clasificar sin distinción de mayúsculas y minúsculas en esa máscara?", Le indica todos los cambios relevantes y suprime los irrelevantes.

El buen control de versiones hace un seguimiento de los nombres de archivos, metadatos y de la procedencia de cada línea de código individual.

El control de versión te permite etiquetar todos los cambios con la razón por la que los hiciste.

El control de versiones no consiste en permitir que más de una persona trabaje en conjunto. Se trata de garantizar el registro histórico de su código base. Asegúrate de saber que no puedes perder nada, o incluso olvidar cuando lo hiciste y cómo, eres libre de refactorizar, inventar y crear sin miedo. Y no sabes qué es la intrepidez antes de haberlo experimentado.

El control de versiones tiene un gran valor, incluso como desarrollador individual, y podría ser bastante más sencillo que el sistema de copia de seguridad / copia de archivos que tiene ahora.

• En este momento, tiene la capacidad de obtener una versión anterior del código, pero ¿cómo encuentra la versión que desea?
• Sólo la capacidad de hacer una diferencia entre revisiones será muy valiosa. La integración con las herramientas de desarrollo es otro beneficio que no está obteniendo de sus herramientas actuales.
• Otro beneficio importante es la capacidad de ramificarse y experimentar con nuevas características o diseños sin tener que preocuparse por romper algo.
• Como se mencionó en otras respuestas, la capacidad de cometer intencionalmente el código que desea compartir con otros es sustancialmente diferente a solo guardar todas las versiones del código en intervalos de 15 minutos. Sin duda, está ahorrando varias versiones de código que no funcionan y que usted u otras personas más tarde necesitarán revisar para encontrar la buena versión anterior que realmente necesita.

Es bastante sencillo poner en funcionamiento un sistema de control de versiones, Particularmente en un entorno tan sencillo como este. Así que la inversión requerida no es muy alta. Como mencioné, el sistema de respaldo que tiene ahora parece que podría ser innecesariamente complejo y potencialmente frágil. Debería beneficiarse de los años de inversión que la comunidad ha realizado en la creación de herramientas como SVN, Git o Mercurial para resolver exactamente el problema de mantener varias versiones del software y proporcionar una buena cantidad de capacidad adicional que es directamente útil para los desarrolladores.

Al configurar y utilizar el control de versión formal, desarrollará un conjunto valioso de habilidades que le serán útiles a lo largo de su carrera. Casi todos los entornos de desarrollo de software profesional utilizan un sistema de control de versiones. Conocer los entresijos de cómo configurar y utilizar un repositorio te ayudará a repetir una y otra vez.

No estoy familiarizado con Mercurial, pero por lo que entiendo, es un sistema de control de revisión completo. Si ya está familiarizado con él, podría valer la pena comenzar a experimentar con él como un VCS.

En un entorno profesional donde hay un código escrito siempre debes tener control de fuente.

Siempre existe el peligro de que un candidato entrevistado le pregunte qué usa para el control de versiones y rechace la posición debido a la falta de un sistema de control de versiones razonable.

También ... si resulta que puede contratar a un profesional, es posible que también les resulte mucho más difícil entender y utilizar su entorno de versiones actual.

Como han dicho otras personas, "ahora" siempre es un buen momento para comenzar a usar el control de versiones. Hay tantos beneficios en el uso de un buen sistema de control de versiones que es casi una obviedad.

Mencionas que usas Mercurial. Al igual que otros vcs distribuidos, siempre puede inicializar su propio repositorio (privado) y trabajar allí. ¿Por qué no intentar eso? Si comienza a trabajar para usted, podría funcionar para su equipo. DVCS se trata de construir desde cero.

El control de versiones realmente es una de las piezas más críticas de un equipo de desarrollo funcional. Aparte del punto de vista de que siempre se realiza una copia de seguridad de su código, está expuesto a funciones como los mensajes de confirmación que le ayudan a entender exactamente lo que la persona antes de usted (o usted mismo) hizo con un archivo en particular. También puede diferenciar archivos con versiones anteriores y crear etiquetas para versiones particulares. Las etiquetas son un ENORME beneficio porque básicamente puedes crear una instantánea de la versión x.x.x del código fuente de tu aplicación. Esto hace que rastrear errores antiguos sea mucho más fácil.

Comience a leer en diferentes plataformas y vea cuál se adapta mejor a sus necesidades. Utilizamos SVN porque había herramientas integradas en nuestro IDE para aprovechar SVN. Irónicamente, ni siquiera usamos estas herramientas ahora, solo usamos Tortoise SVN para registrar y retirar el código.

Para responder a su pregunta, se necesita el control de versión desde el momento en que escribe su primera línea de código.