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

Question

Tengo varios proyectos con una base de código superpuesta muy grande. 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 otra, con cierta superposición. 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 sea cómodo registrarme.

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

Answer 1

Echa un vistazo a una rama personal del código e incorpórate a los cambios. Al menos 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 rama en el tronco.

También puede consultar una rama 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, úsela hasta que se sienta cómodo con la idea de fusionarse.

Editar: 'Verificación de una rama' 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 repositorio svn estándar consta de las carpetas troncales, etiquetas y ramas en la raíz.

Answer 2

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

La razón por la que esto es importante es porque si está trabajando en el error XXXX, y repara la mitad del código, pero no es estable y no '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á sus registros atómicos. No tiene que preocuparse por perder su trabajo, porque todavía está en manos del repositorio (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 le pida que regrese a XXXX (suponiendo que haya registrado YYYY), puede desmantelar su 'estante' y volver directamente a donde lo dejó.

Answer 3

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

O obligue 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 fuente), la segunda es probablemente imposible, no hay una tercera opción.

Si no tiene tiempo para obtener el código en un estado estable, definitivamente no tiene tiempo para bifurcarse y fusionarse todo el tiempo.

Answer 4

Por lo tanto, mi código no es realmente en un estado completamente estable que me siento cómodo llegue al hotel.

¿Por qué?
Si su rama es apropiada para su trabajo (con una buena convención de nomenclatura por ejemplo), todos sabrán que HEAD no siempre es estable.
En este tipo de rama de "trabajo", simplemente ponga una etiqueta en el camino para indicar algunos "puntos de código estables" (que luego pueden ser consultados por cualquier probador que se despliegue).
Cualquier otra versión en esa rama de trabajo solo está hecha para registrar cambios, aunque el estado actual no sea estable.

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

Answer 5

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

De esta manera, es mucho más fácil "asegurar" su trabajo mientras tanto.