¿Con qué frecuencia cometer cambios en el control de fuente? [cerrado]

¿Con qué frecuencia debo enviar cambios al control de código fuente? ¿Después de cada pequeña característica, o solo para grandes características?

Estoy trabajando en un proyecto y tengo una característica a largo plazo para implementar. Actualmente, me comprometo después de cada parte del trabajo, es decir, cada subcaracterística implementada y corregida. Incluso me comprometo después de haber agregado una nueva porción de pruebas para alguna característica después de descubrir un error.

Sin embargo, estoy preocupado por este patrón. En un día productivo de trabajo, podría hacer 10 commits. Dado que estoy usando Subversion, estas confirmaciones afectan a todo el repositorio, por lo que me pregunto si realmente es una buena práctica hacer tantas.

Cada vez que completo un "pensamiento completo" del código que compila y ejecuta, me registro. Esto generalmente termina entre 15 y 60 minutos. A veces puede ser más largo, pero siempre trato de registrarme si tengo muchos cambios de código que no quisiera reescribir en caso de falla. Por lo general, también me aseguro de que mi código se compila y me registro al final del día de trabajo antes de irme a casa.

No me preocuparía hacer "demasiados" commits / check-ins. Realmente apesta cuando tienes que reescribir algo, y es bueno poder retroceder en pequeños incrementos por si acaso.

Cuando dice que le preocupa que sus "confirmaciones afecten a todo el repositorio", ¿se refiere al hecho de que aumenta el número de revisión de todo el repositorio? No sé cuántos bits usa Subversion para almacenarlo, ¡pero estoy bastante seguro de que no se quedarán sin números de revisión! Muchas confirmaciones no son un problema. Puede cometer diez veces más que el vecino y no aumentará su huella de carbono.

Se debe nombrar una sola función o método por lo que hace, y si el nombre es demasiado largo, está haciendo demasiado. Intento aplicar la misma regla a los registros: el comentario del registro debe describir exactamente lo que logra el cambio, y si el comentario es demasiado largo, probablemente esté cambiando demasiado de una vez.

Me gusta este pequeño artículo de Jeff Atwood: check in temprano, check in a menudo

Personalmente, confirmo cada grupo lógico de código que está terminado / estable / compila e intento no abandonar el día sin comprometer lo que hice ese día.

Si está realizando cambios importantes y le preocupa afectar a otros que trabajan en el código, puede crear una nueva rama y luego fusionarla nuevamente en el tronco una vez que se hayan completado los cambios.

Me comprometo cada vez que termino con una tarea. Eso generalmente toma 30 minutos a 1 hora.

Si su comentario de control de versión es más largo que una o dos oraciones, probablemente no se esté comprometiendo con la frecuencia suficiente.

Sigo el mantra de código abierto (parafraseado): me comprometo temprano, me comprometo a menudo.

Básicamente, cada vez que pienso que he agregado funcionalidades útiles (por pequeñas que sean) sin presentar problemas para otros miembros del equipo.

Esta estrategia de compromiso frecuente es particularmente útil en entornos de integración continua, ya que permite las pruebas de integración frente a otros esfuerzos de desarrollo, lo que permite la detección temprana de problemas.

No confirmes código que en realidad no funciona. No use su repositorio como una solución de respaldo.

En su lugar, haga una copia de seguridad de su código incompleto localmente de forma automatizada. Time Machine se ocupa de mí y hay muchos programas gratuitos para otras plataformas.

La regla general que uso es el registro cuando el grupo de archivos que se está registrando puede ser cubierto por un solo comentario de registro.

Esto es generalmente para asegurar que los registros sean atómicos y que los comentarios puedan ser fácilmente digeridos por otros desarrolladores.

Es especialmente cierto cuando sus cambios afectan un archivo de configuración (como un archivo de contexto de primavera o un archivo de configuración de struts) que tiene un amplio alcance de aplicación. Si realiza varios 'grupos' de cambios antes de registrarse, su impacto se superpone en el archivo de configuración, lo que hace que los 2 grupos se fusionen entre sí.

No creo que debas preocuparte tanto por la frecuencia. Lo importante aquí es qué, cuándo y por qué. Decir que tienes que comprometerte cada 3 horas o cada 24 horas realmente no tiene sentido. Comprometerse cuando tenga algo que comprometer, no lo haga si no lo tiene.

Aquí hay un extracto de mis mejores prácticas recomendadas para el control de versiones :

[...] Si está realizando muchos cambios en un proyecto al mismo tiempo, divídalos en partes lógicas y comprométalas en varias sesiones. Esto hace que sea mucho más fácil rastrear el historial de cambios individuales, lo que le ahorrará mucho tiempo al tratar de encontrar y corregir errores más adelante. Por ejemplo, si está implementando la función A, B y C y está arreglando los errores 1, 2 y 3, eso debería resultar en un total de al menos seis confirmaciones, una para cada función y una para cada error. Si está trabajando en una función importante o está realizando una refactorización extensa, considere dividir su trabajo en partes aún más pequeñas y realice una confirmación después de completar cada parte. Además, al implementar cambios independientes en múltiples módulos lógicos, confirme los cambios en cada módulo por separado, incluso si son parte de un cambio mayor.

Idealmente, nunca debe salir de su oficina con cambios no confirmados en su disco duro. Si está trabajando en proyectos donde los cambios afectarán a otras personas, considere usar una rama para implementar sus cambios y fusionarlos nuevamente en el tronco cuando haya terminado. Al confirmar cambios en bibliotecas o proyectos de los que dependen otros proyectos, y por lo tanto, otras personas, asegúrese de no romper sus compilaciones mediante la confirmación de código que no se compilará. Sin embargo, tener un código que no se compila no es una excusa para evitar cometer. Use ramas en su lugar. [...]

Tu patrón actual tiene sentido. Tenga en cuenta cómo usa este control de fuente: ¿qué pasa si tiene que retroceder o si desea hacer una diferencia? Los fragmentos que describe parecen exactamente el diferencial correcto en esos casos: el diff le mostrará exactamente qué cambió al implementar el número de error (especificado en el registro de registro), o exactamente cuál era el nuevo código para implementar una característica. La reversión, de manera similar, solo tocará una cosa a la vez.

También me gusta comprometerme después de terminar una parte del trabajo, que a menudo es varias veces al día. Creo que es más fácil ver lo que sucede en las pequeñas confirmaciones que en las grandes. Si le preocupan demasiadas confirmaciones, puede considerar crear una rama y fusionarla nuevamente con el tronco cuando termine toda la función.

Aquí hay una publicación de blog relacionada: Coding Horror: Check In Early, Check In A menudo

Como han dicho otros, intente cometer un fragmento lógico que sea "lo suficientemente completo" para que no se interponga en la forma de otros desarrolladores (por ejemplo, crea y pasa las pruebas automatizadas).

Cada equipo / empresa de desarrollo debe definir qué es "lo suficientemente completo" para cada sucursal. Por ejemplo, puede tener ramas de características que requieren que el código solo se cree, un Troncal que también requiere que el código pase las pruebas automatizadas y etiquetas que indiquen que algo pasó las pruebas de control de calidad ... o algo así.

No estoy diciendo que este sea un buen patrón a seguir; Solo estoy señalando que cómo se hace "hecho" depende de las políticas de su equipo / empresa.

En el momento en que lo piensas.

(siempre y cuando lo que registre sea seguro)

Depende de su sistema de código fuente y de qué más tiene instalado. Si está utilizando Git, entonces comprométase cada vez que termine un paso. Uso SVN y me gusta comprometerme cuando termino una función completa, por lo tanto, cada una a cinco horas. Si estuviera usando CVS, haría lo mismo.

Estoy de acuerdo con varias de las respuestas: no marque el código que no se compilará; use una sucursal o repositorio personal si su preocupación es tener una "copia de seguridad" del código o sus cambios; registrarse cuando las unidades lógicas estén completas.

Otra cosa que agregaría es que, dependiendo de su entorno, la tasa de registro puede variar con el tiempo. Por ejemplo, al principio de un proyecto, el registro después de que cada pieza funcional de un componente esté completa tiene sentido tanto para la seguridad como para tener un historial de revisión (estoy pensando en casos en los que los bits anteriores se refactorizan a medida que se desarrollan los posteriores). Más adelante en el proyecto, por otro lado, la funcionalidad completamente completa se vuelve más importante, especialmente durante el desarrollo / prueba de integración. Una mitad de integración o mitad de arreglo no ayuda a nadie.

En cuanto a registrarse después de cada corrección de errores: a menos que la corrección sea trivial, ¡absolutamente! Nada es más doloroso que encontrar que un registro contenía tres correcciones y una de ellas debe revertirse. En la mayoría de los casos, parece que en esa situación, el desarrollador corrigió tres errores en un área y desenrolla qué cambio va a qué corrección de errores es una pesadilla.

También me gusta registrarme regularmente. Eso es cada vez que he completado un paso hacia mi objetivo.

Esto suele ser cada dos horas .

Mi dificultad es encontrar a alguien dispuesto y capaz de realizar tantas revisiones de código .

La política de nuestra compañía es que necesitamos una revisión del código antes de que podamos registrar cualquier cosa, lo cual tiene sentido, pero no siempre hay alguien en el departamento que tenga tiempo para realizar una revisión del código de inmediato. Soluciones posibles:

1. Más trabajo por check in; menos registros == menos comentarios.
2. Cambiar la política de registro de la empresa. Si acabo de refactorizar y las pruebas unitarias se ejecutan en verde, ¿tal vez pueda relajar la regla?
3. Deje de lado el cambio hasta que alguien pueda realizar la revisión y seguir trabajando. Esto puede ser problemático si al revisor no le gusta su código y tiene que rediseñarlo. Hacer malabarismos con las diferentes etapas de una tarea al "dejar de lado" los cambios puede volverse desordenado.

Me gusta confirmar los cambios cada 30-60 minutos, siempre que se compile limpiamente y no haya regresiones en las pruebas unitarias.

Bueno, podría tener su propia rama a la que puede comprometerse tantas veces como lo desee, y cuando haya terminado con su función, podría fusionarla con el tronco principal.

Con respecto a la frecuencia de los commits, pienso de esta manera, cuánto dolor sería para mí si mi disco duro se estrellara y no hubiera cometido algo; la cantidad de este algo para mí es de aproximadamente 2 horas de trabajo.

Por supuesto, nunca cometo algo que no compila.

Al menos una vez al día.

No tengo un límite de tiempo específico por confirmación, tiendo a confirmar una vez que una prueba ha pasado y estoy contento con el código. No confirmaría un código que no se compila o está en un estado en el que no me sentiría bien si volviera en caso de falla

Debe equilibrar el compromiso entre seguridad y capacidad de recuperación, por un lado, y la facilidad de gestión de cambios para todo el proyecto, por otro.

El mejor esquema que he usado ha tenido dos respuestas a esa pregunta.

Utilizamos 2 repositorios completamente separados: uno era el repositorio de todo el proyecto y el otro era nuestro propio repositorio personal (estábamos usando rcs en ese momento).

Nos registramos en nuestro repositorio personal muy regularmente, casi cada vez que guardaba sus archivos abiertos. Como tal, el repositorio personal era básicamente un gran búfer de deshacer de largo alcance.

Una vez que teníamos un fragmento de código que se compilaba, se probaba bien y se aceptaba que estaba listo para el uso general, se registraba en el repositorio del proyecto.

Desafortunadamente, este sistema se basó en el uso de diferentes tecnologías VCS para ser viable. No he encontrado ningún método satisfactorio para lograr los mismos resultados al usar dos VCS del mismo tipo (por ejemplo, dos repositorios de subversión)

Sin embargo, he tenido resultados aceptables al crear ramas de desarrollo "personal" en un repositorio de subversión, verificando la rama regularmente y luego fusionándome en el tronco al finalizar.

Si está trabajando en una rama que no se lanzará, una confirmación siempre es segura.

Sin embargo, si lo está compartiendo con otros desarrolladores, la confirmación de código que no funciona puede ser un poco molesto (especialmente si está en un lugar importante). Normalmente, solo confirmo el código que efectivamente está "funcionando", no es que haya sido probado completamente, sino que he comprobado que realmente se compila y no falla inmediatamente.

Si está utilizando un rastreador de errores integrado, puede ser útil realizar confirmaciones por separado si ha solucionado dos errores, de modo que el registro de confirmación pueda ir contra los errores correctos. Pero, de nuevo, a veces un cambio de código corrige dos errores, por lo que solo tiene que elegir contra cuál (a menos que su sistema permita que una confirmación se asocie con varios errores)

Todavía creo en la frase "comprometerse a menudo, comprometerse temprano". Prefiero VCS descentralizado como Mercurial y no hay problema para cometer varias cosas y empujarlo más adelante.

Esta es realmente una pregunta común, pero la verdadera pregunta es: ¿Puede confirmar código inacabado?

Cada vez que termine algún código que funcione y no arruine a nadie más si lo obtienen en una actualización.

Y asegúrate de comentar correctamente.