DVCS: frecuencia y cuándo realizar cambios

Question

Hay otro thread aquí en StackOverflow, que trata de con qué frecuencia se deben realizar cambios en el control de código fuente. Quiero poner eso en el contexto de usar un DVCS como git o mercurial.

1. ¿Con qué frecuencia y cuándo se compromete?

2. ¿Solo confirma los cambios cuando se construyen correctamente ?

3. ¿Con qué frecuencia y cuándo se realizan los cambios (o se presenta una solicitud de extracción o similar)?

4. ¿Cómo se puede desarrollar una función compleja/hacer una compleja refactorización que requiera muchos lugares para tocar? ¿Los "commits privados" no se compilarán bien? Cuando haya terminado, ¿los envía también al repositorio principal o agrupa todos los cambios en un solo conjunto de cambios antes de presionar?

Answer 1

Depende de la naturaleza de la rama ("línea de desarrollo") que se está trabajando.

La principal ventaja con esos DVCS (GIT o mercuriales) es la facilidad puede:

• rama
• fusión

Así:

1/¿Con qué frecuencia y cuando te comprometes?
2/¿Solo compromete cambios cuando se compilan correctamente?

Tanto tiempo como sea necesario en una rama privada (por ejemplo, si se compila).
La práctica de solo confirmar si las pruebas unitarias pasan es buena, pero solo debe aplicarse a una rama "oficial" (como en "podría ser publicada o 'empujada'"): en su sucursal privada, fusiona un gazillon veces si lo necesitas.
Lo único que hay que hacer es fusionar: interactivo para reorganizar los muchos commits en su sucursal privada, antes de reproducirlos en su rama de desarrollo principal, donde puede pasar algunas pruebas.

3/¿Con qué frecuencia y cuándo se realizan los cambios (o se presenta una solicitud de extracción o similar)?

La publicación es otra cuestión y debe hacerse con un historial "claro" (fusiones coherentes, que representan un contenido que compila y pasa algunas pruebas).
La rama que publica debe ser una donde el historial nunca se reescribe, siempre se actualiza.
El ritmo de las publicaciones depende de la naturaleza de la rama remota y de la población que tira de esa rama. Por ejemplo, si es para otro equipo, puede presionar con bastante frecuencia. Si es para un equipo de prueba de integración de todo el sistema, empujará mucho menos a menudo.

4/¿Cómo enfoca el desarrollo de una función compleja/haciendo una compleja refactorización que requiere muchos lugares para tocar? ¿Los "commits privados" no se compilarán bien?Cuando haya terminado, ¿los envía también al repositorio principal o agrupa todos los cambios en un solo conjunto de cambios antes de presionar?

Ver 1. y 2 .: aplicar el parche primero en su propia rama privada, luego reorganizar sus confirmaciones en una rama de parche oficial (publicada). Una única confirmación no siempre es la mejor opción si el parche implica varias "actividades" diferentes (o corrección de errores).

Answer 2

¿Con qué frecuencia y cuándo se compromete?

Con mucha frecuencia. Podría ser tanto como algunas veces en una hora, si los cambios que he hecho funcionan y constituyen un buen parche. O podría ser cada pocas horas, dependiendo de si gasto más tiempo depurando cosas o experimentando con cambios arriesgados.

¿Solo confirma los cambios cuando se compilan correctamente?

Sí, casi siempre. No puedo pensar en una razón para verificar el código que no se creó correctamente. Sin embargo, hay muchas razones por las que puede consultar el código que no ejecuta (en una sucursal).

¿Con qué frecuencia y cuándo se realizan los cambios (o se presenta una solicitud de extracción o similar)?

Normalmente solo cuando una característica está completa y lista para la prueba de integración. Eso significa que ha pasado las pruebas unitarias y otras pruebas relevantes, y el código/parche está lo suficientemente limpio como para considerarlo listo para su revisión.

¿Cómo se puede desarrollar una función compleja/hacer una compleja refactorización que requiera muchos lugares para tocar? ¿Los "commits privados" no se compilarán bien? Cuando haya terminado, ¿los envía también al repositorio principal o agrupa todos los cambios en un solo conjunto de cambios antes de presionar?

Crearía una rama con nombre para la característica (que tendría trazabilidad entre los documentos de diseño y el sistema de seguimiento de problemas). Los compromisos que no se compilan solo estarían realmente bien en una sucursal privada como un paso intermedio, pero seguirían siendo excepcionales. Actualmente no rebase y fusiono toda la rama de características en un solo conjunto de cambios, aunque es algo que estoy buscando hacer en el futuro. Los cambios solo se presionan cuando se pasan todas las pruebas apropiadas.

Answer 3

Comprometo mucho; al agregar funciones o incluso reformatear mis fuentes.

Uso git y hago la mayor parte de mi trabajo en ramas no compartidas. Y cuando he agregado suficientes pequeños cambios que cuentan como bloque, uso git rebase para recopilar los cambios relacionados más pequeños en trozos más grandes y comprometerlos con las ramas principales.

De esta manera, tengo todas las ventajas del código comprometido que puedo ir hacia adelante o hacia atrás, pero no tengo que cometer todos mis errores, y backtracks al historial principal.

Answer 4

que siguen este tipo de flow
alt text http://img121.imageshack.us/img121/3272/versioncontrolsysbestpr.png

(Here is the original image url)

supongo que esto lo dice prácticamente todo. Básicamente, haría un check-in después de implementar una historia de usuario/caso de uso en pleno funcionamiento (depende de su proceso de software). Lo más importante es que controle las cosas que funcionan en el sentido de que compilan. Nunca break the build!
Hacer una confirmación después de cada historia de usuario/caso de uso tiene la ventaja de que tiene un mejor seguimiento de las versiones pasadas y deshacer los cambios es mucho más fácil.

Answer 5

Realizo cambios a mi DVCS (mi propio tema o rama de tareas) muy, muy a menudo, de esta manera puedo usarlo no solo para "entregar cambios" sino también para ayudarme mientras trabajo: como "por qué esto estaba funcionando hace 5 minutos y ya no funciona? " Si te comprometes a menudo, solo puedes ejecutar un diff.

Además, una técnica que encontré muy, muy buena es usarla para "refactores de auto-documentos". Permíteme explicarte: si tienes que hacer un gran refactor en una rama temática y luego revisar el cambio como un todo (habiendo modificado un buen conjunto de archivos), probablemente te perderías. Pero, supongamos que revisa cada "paso intermedio" y lo documenta con un comentario, entonces está creando una especie de "película" de sus propios cambios que ayuda a describir lo que ha hecho. Enorme para los críticos.