¿Cuándo es un compromiso de control de versión demasiado grande? [cerrado]

  

Para mí, tengo problemas para intentar hacer "pequeños compromisos", ya que olvido o creo algo que crea algo más que crea algo más.

Eso es un problema. Parece que necesitas aprender para dividir tu trabajo en partes más pequeñas y manejables.

El problema con las grandes confirmaciones son:

• En un proyecto de varias personas, existe una mayor probabilidad de que sus confirmaciones causen conflictos para que otros desarrolladores lo resuelvan.
• Es más difícil describir con precisión lo que se ha hecho en los mensajes de registro.
• Es más difícil rastrear el orden en que se realizaron los cambios y, por lo tanto, comprender la causa de los problemas.
• Aumenta la probabilidad de perder mucho trabajo no comprometido.

A veces, las grandes confirmaciones son inevitables; p.ej. Si tienes que cambiar una API importante. Pero ese no es normalmente el caso. Y si se encuentra en esta situación, probablemente sea una buena idea crear una sucursal y hacer su trabajo allí ... con muchos compromisos pequeños ... y reintegrarse cuando haya terminado.

(Otro caso es cuando haces una importación inicial, pero eso NO es problemático desde la perspectiva de los problemas mencionados anteriormente).

El principio de responsabilidad única.

Cada confirmación de control de fuente debe servir solo para un propósito. Si tiene que poner la palabra "y" o "también" en su resumen, debe dividirlo.

Es muy común terminar con muchos cambios independientes o no relacionados en su copia de trabajo. Esto se conoce como el "problema de la copia de trabajo enmarañada", y en realidad es muy difícil de evitar incluso para los desarrolladores disciplinados. Sin embargo, Git y Mercurial te ofrecen herramientas para resolverlo: git add -p o selección de trozos y colas mercuriales en TortoiseHg respectivamente.

Imagine que el cliente pidió que se hiciera un cambio en particular, por ejemplo, para agregar una regla de que algo u otro no se puede hacer dentro de los dos días posteriores a la fecha "cualquiera que sea". Luego, después de haber hecho el cambio, cambian de opinión. Usted querrá revertir su compromiso. Si todo se complica con algunas cosas acerca de cambiar el orden de los informes no relacionados, tu vida es una miseria.

Un elemento de trabajo, un conjunto de cambios. Una solicitud del cliente, un conjunto de cambios. Una cosa sobre la que podrías cambiar de opinión, un conjunto de cambios. A veces eso significa que es una sola línea de código. A veces son diez archivos diferentes, incluido el esquema de base de datos. Esta bien.

Las confirmaciones grandes se producen cuando hay toneladas de cambios que no todos van en el mismo grupo. Si cambio la lógica del controlador, entonces el modelo de conexión de la base de datos, entonces algunos misc. Scripts, no debería estar empaquetando todo en un solo commit.

La prevención es hacer compromisos de acuerdo con lo que estás completando. En el ejemplo anterior, yo cometería después de la lógica del controlador, después del trabajo de la base de datos y después de los scripts. No deje de comprometerse simplemente porque usted sabe lo que cambió. Otras personas volverán a mirar tu "Cosas cambiadas" para enviar el mensaje de confirmación y se preguntarán qué estabas fumando.

Las importaciones iniciales son probablemente los mayores compromisos que deberías tener. ¿Configurando un sistema desde cero? Claro que tienen algunos grandes compromisos. Después de nivelarlo, es hora de mantener las cosas organizadas.

Si sabe de antemano que va a trabajar en una gran parte del código, le sugeriría que cree una rama para su función específica mientras que periódicamente extrae el código de la línea principal para asegurarse de que su código permanezca sincronizado. Cuando haya terminado de trabajar en la rama, vuelva a fusionar todos los cambios en la línea principal. De esta manera, otros miembros del equipo no se sorprenderán o molestarán cuando vean un gran compromiso. Además, hay muchas menos posibilidades de romper cosas. Sigue practicando para dividir las cosas en compromisos más pequeños. Con el tiempo se convertirá en una segunda naturaleza.

Este ejemplo muestra una confirmación que es demasiado grande.

Como regla general, describa el cambio en una oración o una línea de texto. (De acuerdo con esta regla, el compromiso debe dividirse en 10-15 más pequeños). Si no puede comentar adecuadamente un compromiso en una línea, ya es demasiado grande.

Para practicar confirmaciones más pequeñas, tome notas en su bloc de notas (o en el Bloc de notas) de lo que ya ha cambiado o agregado. Confirme antes de que se convierta en una lista larga o antes de realizar un cambio de código no relacionado con lo que ya tiene en el bloc de notas.

Lo que realmente importa no es el tamaño del compromiso, es el alcance del cambio lo que debe determinar cómo están organizados sus compromisos.

Puede, por ejemplo, cambiar cada instancia de __macro1 a __macro2 en una base de código grande, que cambia 200 archivos. 200 compromisos no serían sanos en ese caso.

Lo que quieres terminar es poder extraer el repositorio en cualquier revisión individual y tener el trabajo de compilación. ¿Cambió de libfoo a libbar ? Espero que el cambio incluya la actualización de sus scripts de compilación y Makefiles también (o lo que sea aplicable).

A veces, es posible que deba realizar una serie de cambios experimentales que logren una cosa, en cuyo caso, debe determinar qué ámbito es más importante para usted si necesita revertir más adelante. ¿Depende uno del otro? Comprométalos todos a la vez en una sola revisión. De lo contrario, en ese caso, sugeriría un compromiso por cambio. Deberías estar haciendo algo así en otra rama, o en otro repo de todos modos.

Mientras que sí, tiene el poder de revertir un solo archivo a una revisión previa (lo que hace que un archivo sea más extenso), al hacerlo se arruinan herramientas como la bisección más adelante y se contamina el historial. .

Si te detienes y piensas "Ok, pasan las pruebas, creo que esto funciona ... pero si va mal, ¿puedo hacerlo fácilmente?" .. terminarás haciendo compromisos sensatos.

En mi campo (modelado de física), descubrí un error en la salida de hoy que no estaba en el repositorio hace 6 meses. Cuando esto suceda, haré una búsqueda binaria en las revisiones:

1. Ejecutar modelo desde hace 3 meses
2. Si el error aún está en la salida, ejecute el modelo desde hace 4.5 meses
3. ... repita hasta que encuentre el compromiso que cede en resultados incorrectos

Cuando el error se introdujo en una comisión monstruosa, tengo que sentarme con un peine de dientes finos para encontrar el origen del problema. Si la confirmación tocó un pequeño número de archivos, es menos doloroso rastrear la (s) línea (s) de código que introdujo el problema.

Recomendaría dividir su problema en una serie de tareas más pequeñas (lo ideal sería poner cada tarea en un rastreador de errores). Haga un compromiso al completar cada tarea (y cierre ese error / característica en su rastreador de errores).

Lo que hay que entender aquí es que "Grande" en este contexto tiene que ver con el número de cambios distintos, no con el tamaño físico de la confirmación (aunque generalmente los dos van de la mano).

No es tan una cuestión de "no cometer grandes compromisos" como hacer hacer pequeños compromisos: el ser ideal para realizar pequeños cambios independientes.

Desde el registro de cambios queda claro que tienes una serie de cosas que podrían haberse cometido por separado (y con seguridad) y, por lo tanto, es bastante evidente que es demasiado grande.

La razón por la que esto puede ser un problema es que su último compromiso es su punto de referencia para los cambios que está realizando actualmente y, por ejemplo, si obtiene el primer bit correcto y luego el siguiente bit incorrecto, habrá no es una manera fácil de hacer que su trabajo vuelva al punto en el que comenzó a cometer errores (BTDTGTTS).

Por supuesto, a veces los cambios solo son grandes, refactorización a gran escala, y como lo sugieren otros, aquí es donde debe ramificarse, de esa manera, aunque sus confirmaciones individuales pueden romper las cosas, se separan del tronco principal de desarrollo para que no se No es un problema y puede continuar comprometiéndose temprano y con frecuencia.

Una cosa más: si aparece algo en medio de tu trabajo que requiere una atención más inmediata, debes cambiarlo por separado (idealmente en un conjunto de carpetas completamente distinto) y enviarlo por separado.

El verdadero desafío en todo esto no es la mecánica, es la mentalidad: que un compromiso no es solo una copia de respaldo que se realiza de vez en cuando, sino que cada compromiso es una piedra en el camino y que no hay nada. está mal con un montón de pequeñas confirmaciones y el hecho de que mezclar diferentes cosas en una mafia de comillas es tan malo como una munición de partes de la funcionalidad vagamente relacionadas en un montón de código.

Como mínimo, prepárese para comprometerse cada vez que piense: "Me gusta mi progreso hasta ahora, y no quiero perderlo si los cambios que estoy a punto de hacer son un desastre". Luego tiene la opción de aprovechar el VCS para eliminar cualquier callejón sin salida que haya intentado o el código especial de depuración que agregó para localizar un problema. (por ejemplo, con git reset --hard o rm -rf *; svn update )

No hay una regla estricta y rápida, no hay una línea divisoria más allá de la cual tu compromiso es demasiado grande.

Hay es , sin embargo, existe una pauta de que las confirmaciones más pequeñas son mejores, dentro de lo razonable (es decir, cometer cada línea es probablemente excesivo).

Tengo en cuenta este tipo de pautas:

• Un solo compromiso debe incluir cambios para una sola corrección de errores
• Un solo compromiso no debe incluir más de medio día de trabajo
• Un solo compromiso no debería romper la compilación

Por supuesto, esto es lo que tengo en cuenta: YMMV. Diferentes desarrolladores favorecen diferentes niveles de granularidad.

Cuanto más pequeño sea el compromiso, más fácil será encontrar exactamente de dónde proviene una posible regresión.

Idealmente, una confirmación debería ser atómica , en el sentido del cambio coherente más pequeño en la base del código (relacionado con un error, una característica, etc.).

En cuanto a las sugerencias específicas para mantener el tamaño del compromiso pequeño, depende en gran medida de su VCS y de su configuración: debe poder realizar el compromiso local o trabajar en su propia sucursal en el servidor.

La clave es comprometerse con su rama "privada" cada vez que realiza un cambio atómico, y luego puede combinar su rama regularmente, por ejemplo, todas las semanas.

Al usar un DVD, su flujo de trabajo podría verse así:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

Usando un vcs centralizado:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

Probablemente has escuchado el dicho de que la perfección es cuando no puedes quitar nada más. Eso también debe describir su estándar para el tamaño de compromiso.

Depende de tu proyecto donde esté el tamaño "perfecto". Si está enviando a clientes externos, un buen tamaño podría ser el incremento más pequeño con el que se sentiría cómodo si no terminara el siguiente a tiempo. Si está creando aplicaciones internas, implementadas con frecuencia, el mejor tamaño podría ser el incremento más pequeño que no rompa nada (y lo acerca más a donde quiere estar).

Los modernos sistemas de control de versiones lo ayudan a crear buenos compromisos con bifurcaciones fáciles, rebasado interactivo, área de preparación, etc.

Los mensajes de confirmación deben ser de una sola línea (y para git max 60 chars). La cantidad de código que se confirma debe ser lo suficientemente pequeña para mantener el mensaje descriptivo dentro de ese límite.

Tiendo a comprometerme cada vez (incluso más ahora que hemos cambiado a git) Me han hecho una buena parte, ya que permite capturar el "por qué" las cosas se hicieron de esta manera.

A veces, has estado trabajando todo el día en varios cambios diferentes lógicamente diferentes, y olvidaste ingresar tu código en el medio. El uso de git citool puede ser muy útil para dividir su trabajo en partes del tamaño de un bocado al final del día, incluso si no fue tan cuidadoso durante el día mientras trabajaba.

git citool puede permitirle seleccionar qué fragmentos específicos de un archivo (o qué líneas específicas) cometer en un compromiso en particular, para que pueda dividir (no superpuestos) los cambios realizados en el mismo archivo en varios confirmaciones.

(Parece que usas Subversion. No conozco una herramienta que haga esto para Subversion, pero podrías utilizar el uso de git-svn , el adaptador de Subversion para git, que cambiará tu vida).

Cuanto mayor sea el compromiso, es más probable que rompas la compilación y el resto de tu equipo te pague. Intento realizar cambios dos veces al día. Justo antes del almuerzo y antes de irme a casa. Así que a las 12 pm y a las 4:30 pm trato de que todo funcione y esté listo para comprometerse. Encuentro que esta práctica me funciona.

Para responder a sus preguntas:

1) Para mí, el compromiso estándar se considera grande si está haciendo más de una cosa. En realidad, me refiero a corregir un error o agregar una función.

2) Prevenga tales compromisos convirtiéndolo en un hábito y una regla para cometer cada vez que termine algo.

3) En las primeras etapas de desarrollo, permito que los compromisos incluyan la primera creación de los archivos que se utilizarán más adelante.

Me gustaría tener en cuenta que al finalizar quiero decir que todos los errores que puedes identificar se han solucionado y que no se romperá la compilación al comprometerse.

Sí, esto genera una gran cantidad de confirmaciones, pero le permite revertir exactamente lo que rompió las cosas en lugar de tener que revertir una gran serie de cambios que se cometieron al mismo tiempo donde solo uno de los cambios está causando un problema .

También me gustaría señalar que las reglas cambian un poco para los sistemas de control de versiones distribuidas (DVCS) como Mercurial y Git. En el caso de que uses uno de esos, te comprometes siempre que hayas realizado un cambio, pero aún no lo hayas probado y luego ingresas al repositorio central cuando está funcionando. Esto es preferible, ya que le permite revisar más cambios en su código sin tener que preocuparse por romper la compilación.

En mi caso, estoy intentando enviar archivos de un servidor al sistema de repositorio (SVN). Este es el compromiso inicial y no quiero descargarlo porque es un proyecto muy grande (unos pocos GB) y quiero realizar el compromiso inicial desde el servidor de los clientes.

El problema es que el cliente está en un servidor compartido, el cliente svn muere (o cualquier otro software) si se ejecuta más de un minuto.

Una alternativa sería descargar el proyecto en mi computadora y hacer la confirmación inicial desde allí, pero me interesa saber si hay una opción en SVN para dividir la confirmación grande en algo más, similar a los métodos de transacción.

El desarrollador antes que yo nunca usó un sistema de control de versiones.

La compañía para la que trabajo obliga a una revisión del código de pares para cada confirmación. Por lo tanto, cualquier compromiso que haga que sea difícil para un par averiguar lo que está pasando y revisar en un tiempo razonable, es demasiado grande.