Mejores prácticas para el control de versiones con múltiples proyectos

Tengo varios proyectos con una gran base de códigos superpuestos. Recién comenzamos a usar SVN, así que estoy tratando de descubrir cómo debería usarlo.

El problema es que cuando estoy terminando una tarea en un proyecto, empiezo una tarea en otro, con cierta superposition. A menudo también hay un gran desarrollo impulsado por interrupciones. Por lo tanto, mi código nunca está realmente en un estado completamente estable que me haga sentir cómodo al registrarme.

El resultado es que no estamos realmente usando el sistema de VC, lo cual es MUY malo, todos lo sabemos … ¿entonces, sugerencias?

Echa un vistazo a una twig personal del código y fusiona los cambios. Al less tendrá algún control de versión para sus propios cambios, en caso de que necesite retroceder. Una vez que se sienta cómodo con el estado en el que se encuentra su sucursal, vuelva a fusionar esa twig en el tronco.

También puede verificar una sucursal para cada tarea, en lugar de una para cada individuo. También puede fusionar los cambios en su sucursal desde el enlace troncal si alguien cambia el enlace troncal y desea que su sucursal refleje los cambios.

Esta es una forma común de usar SVN, aunque hay otros flujos de trabajo. He trabajado en proyectos en los que tenía miedo de comprometerme (rompería la construcción posiblemente) porque no utilizamos la ramificación de manera efectiva.

La ramificación es realmente poderosa para ayudar a su flujo de trabajo, utilícela hasta que se sienta cómodo con la idea de fusionarse.

Editar: 'Verificación de una twig' se refiere a la creación de una bifurcación en su carpeta de sucursales y luego a la salida de esa bifurcación. La estructura del repository svn estándar consta de las carpetas troncales, tags y twigs en la raíz.

Por lo tanto, mi código nunca está realmente en un estado completamente estable que me haga sentir cómodo al registrarme.

Porqué es eso ?
Si su twig es apropiada para su trabajo (con una buena convención de nombres, por ejemplo), todos sabrán que HEAD no siempre es estable.
En este tipo de twig de "trabajo", simplemente coloque una label en el path para indicar algunos "puntos de código estables" (que luego pueden ser consultados por cualquier probador que se deployment).
Cualquier otra versión en esa twig de trabajo solo está hecha para registrar cambios, aunque el estado actual no sea estable.

Luego, luego se fusiona todo en una twig que se supone que representa un estado estable.

En TFS, puede crear 'Conjuntos de estantería' (no estoy seguro de cómo se llamarían en otros proveedores de control de origen). Cuando archiva un código, lo está guardando en su repository, pero no lo está registrando.

La razón por la que esto es importante es que si trabajas en el error XXXX y arreglas la mitad del código, pero no es estable y no se puede 'check-in-able', pero te asignan a NewFeature YYYY, NO DEBES continuar trabajando con la misma base de código Debería 'Estancar' su código Bug XXXX, luego devolver su código base local al último código registrado e implementar NewFeature YYYY.

De esta forma mantendrás tus loggings atómicos. No tiene que preocuparse por perder su trabajo, porque todavía está en manos del repository (por lo tanto, si su computadora estalla en llamas, no es necesario que rompa a llorar), y no está mezclando sus soluciones para XXXX. con su nuevo código para YYYY. Luego, una vez que se te pida que vuelvas a XXXX (suponiendo que hayas registrado YYYY), puedes deshacerte de tu "juego de estanterías" y volver directamente a donde lo dejaste.

Acepte que el código en SVN no está en un estado completamente estable y consérvelo de todos modos (y reserve time para la estabilización y la refactorización cada X días / semanas para que el código no se degrade demasiado).

O fuerce a su equipo a trabajar de una manera más estructurada con un desarrollo mínimo basado en interrupciones para que pueda verificar el buen código.

La primera opción no es ideal (pero es mejor que no tener control de origen), la segunda es probablemente imposible; no hay una tercera opción.

Si no tiene time para get el código en un estado estable, definitivamente no tiene time de ramificarse y fusionarse todo el time.

En los sistemas de control de fuente distribuida como GIT, se compromete con su repository local. Solo cuando insertas tu código, está 'comprometido' con el repository remoto.

De esta manera, es mucho más fácil "seguro" su trabajo en el medio.

    Intereting Posts