¿Con qué frecuencia enviar cambios al control de código fuente? [cerrado]

Cuando dice que le preocupa que sus "commits afecten a todo el repositorio" - - - ¿se refiere al hecho de que el número de revisiones de todo el repositorio aumenta? No se cuantos bits usa Subversion para almacenarlo, pero estoy bastante seguro de que no se van a quedar sin números de revisión! Muchas confirmaciones no son un problema. Puedes comprometerte diez veces más que el chico de al lado y no aumentarás tu huella de carbono en absoluto.

Una sola función o método debe ser nombrado por lo que hace, y si el nombre es demasiado largo, está haciendo demasiado. Trato de aplicar la misma regla a los check-ins: el comentario check-in debe describir exactamente lo que el cambio logra, y si el comentario es demasiado largo, probablemente estoy cambiando demasiado a la vez.

Me gusta este pequeño artículo de Jeff Atwood: Check In Early, Check In Often

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

Si está haciendo cambios importantes y está preocupado por afectar a otros que trabajan en el código, puede crear una nueva rama y luego fusionarla de nuevo en el tronco después de que se completen los cambios.

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

No confirme código que en realidad no funciona. No utilice su repositorio como una solución de copia de seguridad.

En su lugar, realice una copia de seguridad local de su código incompleto de forma automatizada. Time Machine se encarga de mí, y hay un montón de programas gratuitos para otras plataformas.

Si su comentario de control de versiones es más largo que una o dos oraciones, probablemente no esté cometiendo con la suficiente frecuencia.

Sigo el mantra de código abierto (parafraseado)-commit temprano, commit a menudo.

Básicamente siempre que creo que he añadido funcionalidad útil (por pequeña que sea) sin introducir problemas para otros miembros del equipo.

Esta estrategia de commit-often es particularmente útil en entornos de integración continua, ya que permite realizar pruebas de integración en comparación con otros esfuerzos de desarrollo, lo que permite la detección temprana de problemas.

La regla general, que uso, es el check-in cuando el grupo de archivos que se están registrando puede ser cubierto por un solo comentario de check-in.

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

Es especialmente cierto cuando sus cambios afectan a un archivo de configuración (como un archivo de contexto spring o un archivo de configuración struts) que tiene un alcance de aplicación amplio. Si realiza varios "grupos" de cambios antes de registrarse, su impacto se superpone en el archivo de configuración, causando 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. Commit cuando tienes algo que commit, no lo hagas si no lo haces.

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

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

Idealmente, nunca debe salir de su oficina con cambios no comprometidos 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 de nuevo 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úrate de no romper sus compilaciones enviando código que no se compile. Sin embargo, tener código que no compila no es una excusa para evitar la confirmación. Usa ramas en su lugar. [...]

Su patrón actual tiene sentido. Tenga en cuenta cómo utiliza este control de código fuente: ¿qué pasa si tiene que revertir, o si desea hacer una diferencia? Los fragmentos que describe parecen exactamente el diferencial correcto en esos casos: el diff le mostrará exactamente qué ha cambiado en la implementación del bug #(especificado en el registro de registro), o exactamente cuál era el nuevo código para implementar una característica. La reversión, del mismo modo, 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 está sucediendo en los commits pequeños que en los grandes. Si estás preocupado por demasiadas confirmaciones, puedes considerar crear una rama y fusionarla de nuevo en el tronco cuando toda la característica haya terminado.

Aquí hay una entrada de blog relacionada: Terror de codificación: Check In Temprano, Check In a Menudo

Como otros han dicho, intente confirmar un fragmento lógico que esté lo suficientemente "completo" como para que no se interponga en el camino de otros desarrolladores (por ejemplo, compila y pasa pruebas automatizadas).

Cada equipo de desarrollo / empresa debe definir lo que es "lo suficientemente completo" para cada sucursal. Por ejemplo, puede tener ramas de características que solo requieren el código para compilar, un tronco que también requiere código para pasar pruebas automatizadas y etiquetas que indican que algo ha pasado 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 pienses.

(siempre y cuando lo que se registra es seguro)

Depende de su sistema de código fuente y de lo que tenga en su lugar. Si estás usando Git, entonces confirma cada vez que termines un paso. Uso SVN y me gusta comprometer cuando termino una característica 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 verifique el código que no se compilará; use una rama o repositorio personal si su preocupación es tener una "copia de seguridad" del código o sus cambios; verifique cuando las unidades lógicas estén completas.

Otra cosa que añadiría es que dependiendo de su entorno, la tarifa de check-in puede variar con el tiempo. Por ejemplo, al principio de un proyecto, registrarse después de completar cada pieza funcional de un componente tiene sentido tanto para la seguridad como para tener una historial de revisiones (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-integración o mitad-arreglo no ayuda a nadie.

En cuanto a la comprobación 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 necesita ser revertido. La mayoría de las veces parece que en esa situación el desarrollador solucionó tres errores en un área y desenrolló 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 es típicamente cada par de horas.

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

Nuestra política de la compañía es que necesitamos tener una revisión del código antes de que podamos verificar 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. Posibles Soluciones:

1. Más trabajo por check in; menos checkins == menos revisiones.
2. Cambie la política de registro de empresa. Si acabo de hacer un poco de refactorización y las pruebas unitarias funcionan en verde, ¿tal vez pueda relajar la regla?
3. Deje de lado el cambio hasta que alguien pueda realizar la revisión y continuar trabajando. Esto puede ser problemático si al revisor no le gusta tu código y tienes que rediseñarlo. Hacer malabares con las diferentes etapas de una tarea al 'dejar de lado' los cambios pueden convertirse en sucio.

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

Bueno, podrías tener tu propia rama a la que puedes enviar commits tantas veces como quieras, y cuando hayas terminado con tu característica, podrías fusionarla con el tronco principal.

En la frecuencia de las confirmaciones, pienso de esta manera, cuánto dolor sería para mí si mi disco duro se estrelló y no había cometido algo - el quantum de este algo para mí es de aproximadamente 2 horas de trabajo.

Por supuesto, nunca confirmo algo que no compile.

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. Yo no;t cometer código no compila o de otra manera en un estado que no me iba a sentir bien acerca de cómo volver en caso de fallo

Debe equilibrar el compromiso entre la seguridad y la recuperabilidad por un lado y la facilidad de gestión del cambio para todo el proyecto por el otro.

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

Usamos 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 uno tiempo que guardaste tus archivos abiertos. Como tal, el repositorio personal era básicamente un búfer de deshacer grande y de largo alcance.

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

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

Sin embargo, he tenido resultados aceptables al crear ramas de desarrollo "personales" en un repositorio de subversion - comprobando la rama regularmente y luego fusionándola en el tronco al completarla.

Si estás trabajando en una rama que no será liberada, un commit siempre es seguro.

Sin embargo, si lo está compartiendo con otros desarrolladores, es probable que cometer código que no funciona sea un poco molesto (especialmente si está en un lugar importante). Normalmente solo confirmo código que está efectivamente "funcionando" - no es que haya sido completamente probado, sino que he comprobado que realmente compila y no falla inmediatamente.

Si está utilizando un rastreador de errores integrado, puede ser es útil hacer confirmaciones separadas si has corregido dos errores, para que el registro de confirmaciones pueda ir en contra de 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 ponerlo (a menos que su sistema permita que un commit se asocie con varios errores)

Todavía creo en la frase 'commit often, commit early'. Prefiero VCS descentralizado como Mercurial y no hay problema para cometer varias cosas y empujarlo hacia arriba más tarde.

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

Siempre que termines algún código que funcione y no arruine a nadie más si lo recibe en una actualización.

Y por favor asegúrese de comentar correctamente.