Use un Sistema de control de versiones distribuido como git y use su máquina de carpetas compartidas para almacenar el repositorio de referencia. Este es el por qué:
Cada clon es una copia de seguridad
Si el disco duro del servidor falla, todos tienen una copia, lista para ser implementada en una nueva unidad o servidor. Como su empresa no se toma en serio el control de versiones, supongo que puede ser más o menos lo mismo con las copias de seguridad.
Referencia común
Tener un repositorio principal con una rama maestra permite conocer la versión que tiene la última palabra. Esto resuelve el "Usted ha probado sus cambios con la versión de Franck, pero ¿también tenía la de John? ¿Y cómo los fusionó?".
Entregar más cómodamente
¿El cliente quiere una versión alfa hoy? Bueno, puedes probar si el maestro es lo suficientemente estable y enviarlo. Si no es así y no tiene tiempo para arreglarlo, simplemente retroceda en el tiempo y obtenga una versión anterior pero más estable. No puede hacer eso si solo tiene la última versión.
Retrocede en el tiempo y corrige tus errores
Su fusión manual tuvo problemas que solo vio después de unos días, pero ¿ya ha sobrescrito el contenido de sus carpetas compartidas? Sin un VSC no tiene historial, por lo que no puede volver fácilmente a un punto en el que pueda verificar los errores que cometió y corregirlos. El código no es como una imagen, es como una película: evoluciona con el tiempo. Puedes extraer una imagen de una película. No se puede extraer una película de una imagen.
Localiza errores más fácilmente
Apareció un error pero realmente no lo notó en el momento en que se introdujo, por lo que no pudo solucionarlo mientras el código estaba "activo". Ahora no sabe realmente qué cambio lo introdujo, por lo que podría provenir de varias ubicaciones diferentes en el código. Tomará horas solo encontrar dónde buscar. Con git, podría haber desarrollado una prueba para decir si el error ocurre en una versión específica y usarlo git bissectpara encontrar la confirmación exacta que introdujo el error. En lugar de buscar miles de líneas de código, ahora sabe que está ubicado en ese cambio de 10 líneas, y puede mantener la prueba en su conjunto de pruebas para asegurarse de que el error no se vuelva a introducir.
Cada desarrollador es responsable de su propio trabajo.
Si eres el líder del equipo y no tienes VCS, lo más probable es que tengas que hacer el trabajo sucio, las fusiones. Si lo hace por su cuenta, probablemente no sepa todo acerca de todos los cambios y puede introducir errores. Por el contrario, si siempre le pide a las personas que escribieron el código que se reúnan con usted cada vez que haya un código para fusionar, entonces es hora de que no lo usen para producir un nuevo código.
Con un VCS, en un flujo de trabajo simple, el desarrollador solo tiene que ocuparse de su trabajo y una fuente externa de cambios: la rama maestra. Puede haber 1 o 100 personas comprometiéndose en la rama maestra, eso es lo mismo. Para poder impulsar sus cambios, tendrá que adaptarlos a los últimos cambios realizados por otros. Puede parecer que lleva más tiempo insertar el código, pero eso se debe a que también está haciendo la fusión, lo que de todos modos habría llevado tiempo.
La diferencia es que la fusión la realiza la persona que realizó los cambios, que conoce mejor ese código porque lo ha escrito.
¿Quién escribió ese código?
Hay ese error aquí, pero ¿quién ha escrito esa línea de código en particular? Es difícil de recordar, especialmente si el proyecto dura varios meses. git blamete habría dicho quién y cuándo se escribió esa línea, para que puedas preguntarle a la persona correcta, y no hay un "No recuerdo haber escrito eso".
El proyecto se está haciendo más grande.
El cliente quiere más funciones y usted es un equipo demasiado pequeño, necesitará otro desarrollador. ¿Cómo gestiona la mayor complejidad de fusión sin un VSC?
Cambios urgentes
El cliente llamó y solicitó una corrección crítica de errores para la producción, pero actualmente estaba trabajando en una nueva función. Solo git stashpara dejar de lado sus cambios, o comprometerlos en una nueva sucursal e impulsar los cambios y estará listo para comenzar a trabajar en la solución urgente, sin temor a perder su trabajo pendiente.
Funcionó hace 10 minutos
Estás haciendo algunos cambios localmente y algo que funcionó hace 10 minutos dejó de funcionar. Sin un VCS, puede mirar el código o, en el mejor de los casos, hacer una copia de la versión de referencia y ver qué cambia. Oh, espera, la referencia cambió desde que empecé a trabajar, así que ya no puedo diferir. Y no pensé en mantener una copia prístina del código en el que basé mis cambios.
Con un VCS, simplemente hace algo como de git diffinmediato, y cambia su versión en comparación con la versión correcta del código en el que se basa.
Tengo que mantener mis registros de depuración
¿Entonces eres un mal tipo y no usas el registro? ¿Tuviste que rociar printfs en toda tu base de código hasta que encontraste todas esas piezas de ese desagradable error? Ahora encontró uno, lo arregló, pero desea mantener su código de depuración cuidadosamente diseñado para solucionar los problemas restantes.
Sin un VCS, debe copiar los archivos, expurgar el código de depuración (que puede agregar algunos errores de edición), empujar eso y volver a colocar los archivos respaldados. Ah, pero parece que de todos modos entró un código de depuración.
Con git, solo debes git add --patchseleccionar las pocas líneas de código que deseas incluir en tu commit, y solo puedes hacerlo . Luego reanuda su trabajo y aún tiene su código de depuración. No tuvo que tocar el código, por lo que no hubo errores de copia / pegado.
La gran bola de barro
Sin un VCS, las personas trabajan de su lado y le dan un montón de cambios, a veces no relacionados. Cuando hay demasiado código para verificar, es difícil encontrar un error.
Un VCS le permitirá hacer pequeños cambios incrementales y le dará un registro de cambios. El registro de cambios es esencial: las personas deben decir por qué están haciendo el cambio, no cuál es el cambio ( qué pregunta ya es respondida por el cambio de código en sí). Esto significa que cuando está inspeccionando algún código de una nueva característica, por ejemplo, no tendrá que leer muchos cambios mixtos no relacionados, como correcciones de errores no relacionadas. Esto ayuda a centrarse en el código que le importa.
Si te doy 100 papas 1 por 1, y una está podrida, la encontrarás de inmediato. Ahora, si arrojo 100 papas frente a ti y te pido que encuentres la podrida, esa no es la misma tarea.
Sangría
Espero que tenga una buena política de estilo de codificación, de lo contrario, los cambios de sangría lo volverán loco si se fusiona a mano. Claro, puede ignorar los espacios en blanco en los cambios (pero no en los idiomas cuando la sangría cuenta, como Python). Pero luego obtendrá un código de aspecto extraño difícil de leer.
Eres el lider del proyecto
Si eres el líder, esto significa que tendrás la culpa si las cosas no funcionan. Si no puede sentirse cómodo con la situación porque su jefe todavía no puede entender que valga la pena usar la herramienta adecuada para el trabajo correcto, entonces, al menos, me negaría a convertirme en el líder de un fracaso predecible.