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

He escuchado en varios lugares "No hacer grandes confirmaciones", pero nunca he entendido qué es una "gran" confirmación. ¿Es grande si trabajas en un montón de archivos aunque estén relacionados? ¿En cuántas partes de un proyecto debería estar trabajando al mismo tiempo?

Para mí, tengo problemas para tratar de hacer "pequeños compromisos" ya que olvido o creo algo que crea algo más que crea algo más. Luego terminas con cosas como esta:

Cola de salida personalizada

Larva del moscardón
-Nuevo campo msgQueue que no es más que un SingleThreadExecutor
-sendMsg bloquea hasta que se envía el mensaje y agrega esperar entre cuando se reciben los mensajes
expedido
-adminExist llamadas actualizadas (ver controlador)
-Cambio de calles para enviar mensaje

Controlador
-Nuevo campo msgWait denota el tiempo de espera entre mensajes
-Inicio de complementos de servicio movidos a reloadPlugins
-adminExists se movió del servidor debido a los administradores globales. Cheques en el canal,
servidor y nivel global

Administración
-Nuevos métodos getServer y getChannel que obtienen el objeto apropiado Admin
pertenece a

BotEvent
-toString () también muestra extra y extra1

Canal
-canal de canal renombrado a nombre
-Se corrigió el error tipográfico en el canal (int)

Servidor
-El administrador movido existe para el controlador

PluginExecutor
-Se agregaron pruebas menores, se eliminarán más tarde

Complementos JS
-Actualizado a cambios en el marco
-Reemplazado InstanceTracker.getController () con Controller.instance
-VLC talk ahora en archivo propio

Varias actualizaciones y cambios de proyectos de NB

---

Archivos afectados
Modificar /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modificar /trunk/Quackbot-Core/dist/README.TXT
Modificar /trunk/Quackbot-Core/nbproject/private/private.properties
Modifique /trunk/Quackbot-Core/nbproject/private/private.xml
Modificar /trunk/Quackbot-Core/src/Quackbot/Bot.java
Modifique /trunk/Quackbot-Core/src/Quackbot/Controller.java
Modificar /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Modificar /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Modifique /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Modificar /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Modificar /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Modificar /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modificar /trunk/Quackbot-GUI/dist/README.TXT
Modifique /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Modifique /trunk/Quackbot-GUI/nbproject/private/private.properties
Modifique /trunk/Quackbot-GUI/nbproject/private/private.xml
Modificar /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Modifique /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Eliminar /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Modificar /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Modificar /trunk/Quackbot-Impl/dist/README.TXT
Modificar /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Modificar /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modifique /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Modifique /trunk/Quackbot-Impl/lib/javarebel.stats
Añadir /trunk/Quackbot-Impl/lib/jrebel.info
Modificar /trunk/Quackbot-Impl/nbproject/private/private.properties
Modifique /trunk/Quackbot-Impl/nbproject/private/private.xml
Modifique /trunk/Quackbot-Impl/nbproject/project.properties
Modifique /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Agregar / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Modifique /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Modifique /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modifique /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Modifique /trunk/Quackbot-Impl/plugins/listeners/onJoin.js
Modifique /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modifique /trunk/Quackbot-Impl/plugins/testCase.js
Agregue /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Modificar /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Agregar / trunk / Quackbot-Impl / vlc_http
Añadir /trunk/Quackbot-Impl/vlc_http/current.html
Modifique /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modifique /trunk/Quackbot-Plugins/dist/README.TXT
Modifique /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modifique /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modifique /trunk/Quackbot-Plugins/nbproject/private/private.xml
Modifique /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Agregar / trunk / Quackbot-Plugins / vlc_http
Añadir /trunk/global-lib/jrebel.jar

Sí....

Entonces para preguntas:

• ¿Cuáles son algunos factores para cuando un commit se vuelve demasiado grande ( cosas no obvias )?
• ¿Cómo puedes evitar tales commits? Por favor dar detalles
• ¿Qué pasa cuando estás en etapas semi-tempranas de desarrollo cuando las cosas se mueven rápidamente? ¿Las grandes confirmaciones todavía están bien?

Para mí, tengo problemas para tratar de 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 necesita aprender a dividir su trabajo en fragmentos más pequeños y manejables.

El problema con las grandes confirmaciones son:

• En un proyecto de varias personas, una mayor probabilidad de que sus confirmaciones causen conflictos para que otros desarrolladores 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 hicieron 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; por ejemplo, si tiene 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 rama y hacer su trabajo allí ... con muchos pequeños compromisos ... y reintegrarse cuando haya terminado.

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

El principio de responsabilidad única.

Cada confirmación de control de fuente debe tener un solo 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 separados no relacionados o semi-relacionados en su copia de trabajo. Esto se llama el "problema de copia de trabajo enredado", y en realidad es muy difícil de evitar incluso para desarrolladores disciplinados. Sin embargo, Git y Mercurial le brindan herramientas para resolverlo: git add -p o chunk selection y Mercurial Queues en TortoiseHg respectivamente.

Imagine que el cliente solicita que se realice un cambio particular, por ejemplo, para agregar una regla de que algo u otro no se puede hacer dentro de los dos días de la fecha "lo que sea". Luego, después de haber realizado el cambio, cambian de opinión. Querrá revertir su compromiso. Si todo está mezclado con algunas cosas sobre cambiar el orden de los informes no relacionados, su 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 puede 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 la base de datos. Esta bien.

Las grandes confirmaciones son cuando tienes toneladas de cambios que realmente no van todos en el mismo cubo. Si cambio la lógica del controlador, entonces el modelo de conexión de la base de datos, luego algunos misceláneos. scripts, no debería agruparlo todo bajo una confirmación.

La prevención es hacer compromisos de acuerdo con lo que estás completando. En el ejemplo anterior, me comprometerí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 ponga de cometer simplemente porque usted sabe lo que ha cambiado. Otras personas volverán a mirar su mensaje de registro de confirmación "Cosas modificadas" y se preguntarán qué estaba fumando.

Las importaciones iniciales son probablemente los mayores compromisos que debería tener. ¿Configurar un sistema desde cero? Claro que tiene algunos grandes compromisos. Después de haberlo nivelado, es hora de mantener las cosas organizadas.

Si sabe que va a estar trabajando en una gran porción de código de antemano, sugeriría crear una rama para su función específica mientras retira periódicamente el código de la línea principal para asegurarse de que su código permanezca sincronizado. Cuando termine de trabajar en la rama, combine todos sus cambios en la línea principal. De esta manera, los demás miembros del equipo no se sorprenderán ni molestarán cuando vean un gran compromiso. Además, hay muchas menos posibilidades de romper cosas. Sigue practicando para dividir las cosas en pequeños compromisos. 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. (Según esta regla, la confirmación debe dividirse en 10-15 más pequeñas). Si no puede comentar adecuadamente una confirmación en una línea, entonces 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. Comprometerse antes de que se convierta en una lista larga o antes de hacer un cambio de código no relacionado con lo que ya tiene en el bloc de notas.

En mi campo (modelado de física), descubrí un error en la salida hoy que no estaba en el repositorio desde 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 sigue apareciendo, ejecute el modelo desde hace 4.5 meses.
3. ... repita hasta que encuentre el commit que produce un mal resultado

Cuando el error se introdujo en una confirmación monstruosa, tengo que sentarme con un peine de dientes finos para encontrar la fuente del problema. Si la confirmación tocó una pequeña cantidad de archivos, es menos doloroso rastrear las líneas de código que introdujeron el problema.

Recomendaría dividir su problema en una serie de tareas más pequeñas (idealmente, coloque cada tarea en un rastreador de errores). Realice una confirmación al completar cada tarea (y cierre ese error / función en su rastreador de errores).

Lo que realmente importa no es el tamaño del compromiso, es el alcance del cambio lo que debería determinar cómo se organizan sus compromisos.

Puede, por ejemplo, cambiar cada instancia de __macro1a __macro2en una base de código grande, que cambia 200 archivos. 200 compromisos no serían cuerdos en ese caso.

Lo que quiere terminar es poder extraer el repositorio en cualquier revisión individual y hacer que la compilación funcione. ¿Cambiaste de libfooa 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é alcance es más importante para usted si necesita revertirlo más tarde. ¿Depende uno del otro? Compártalos todos a la vez en una sola revisión. De lo contrario, en ese caso, sugeriría una confirmación por cambio. Deberías estar haciendo algo así en otra rama, o en otro repositorio de todos modos.

Si bien sí, tiene el poder de revertir un solo archivo a una revisión anterior (por lo tanto, respaldar un archivo de un compromiso mayor), hacerlo realmente arruina herramientas como la bisección más adelante y contamina el historial.

Si se detiene y piensa "Ok, las pruebas pasan, creo que esto funciona ... pero si sale mal, ¿puedo retroceder fácilmente?" .. terminarás haciendo compromisos razonables.

Lo que hay que entender aquí es que "Grande" en este contexto se trata del número de cambios distintos, no del tamaño físico de la confirmación (aunque generalmente los dos irán de la mano).

No es por lo que una cuestión de "no hacer grandes confirmaciones" como hacer hacer pequeños compromete - siendo el ideal para cometer pequeños cambios autónomo.

Del registro de cambios queda claro que tiene una serie de cosas que podrían haberse cometido por separado (y de forma segura) 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 última confirmación es su punto de referencia para los cambios que está realizando actualmente y si, por ejemplo, obtiene el primer bit correcto y luego el siguiente incorrecto, no es fácil para hacer retroceder su trabajo hasta el punto en que comenzó a cometer errores (BTDTGTTS).

Por supuesto, a veces los cambios son grandes, refactorización a gran escala, y como lo sugieren otros, aquí es donde debe ramificarse, de esa manera, aunque sus confirmaciones individuales podrían romper cosas que están separadas del tronco principal de desarrollo, por lo que no es un problema y puedes continuar comprometiéndote temprano y con frecuencia.

Una cosa más: si surge algo en medio de su trabajo que requiere más atención inmediata, debe cambiarlo por separado (idealmente en un conjunto de carpetas completamente distinto) y confirmarlo por separado.

El verdadero desafío en todo esto no es la mecánica, es la mentalidad: que un commit no es solo una copia de respaldo que haces de vez en cuando, sino que cada commit es una piedra de una pulgada en el camino y que no hay nada malo con muchos de pequeños commits y que mezclar diferentes cosas juntas en un commit de la mafia es tan malo juntar partes de funcionalidad vagamente relacionadas en un conjunto de código.

Por lo menos, entrenarse para comprometerse cada vez que piense: "Me gusta mi progreso hasta ahora, y no quiero perderlo si los cambios que estoy por hacer son un desastre". Luego tiene la opción de aprovechar el VCS para eliminar los callejones sin salida que intentó o el código de depuración especial que agregó para localizar un problema. (p. ej. con git reset --hardo rm -rf *; svn update)

No hay una regla dura y rápida, ni una línea divisoria más allá de la cual tu commit sea demasiado grande.

Sin embargo, existe una directriz de que las confirmaciones más pequeñas son mejores, dentro de lo razonable (es decir, la confirmación de cada línea es probablemente excesiva).

Tengo en cuenta este tipo de pautas:

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

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

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

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

En cuanto a los consejos específicos para mantener pequeño el tamaño de la confirmación, depende en gran medida de su VCS y de cómo esté configurado: debe poder confirmar localmente 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 fusionar regularmente su rama, por ejemplo, cada semana.

Usando un dvcs, 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 hayas escuchado el dicho de que la perfección es cuando no puedes quitar nada más. Eso también debería describir su estándar para el tamaño de confirmación.

Depende de su proyecto donde esté ese tamaño "perfecto". Si realiza envíos 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 próximo 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 acerque más a donde desea estar).

Los sistemas modernos de control de versiones lo ayudan a crear buenos compromisos con ramificaciones fáciles, rebases interactivos, área de preparación, etc.

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

Tiendo a comprometerme cada vez (incluso más ahora que hemos cambiado a git) tengo un fragmento hecho, 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 distintos, y olvidaste ingresar tu código en el medio. El uso git citoolpuede ser muy útil para dividir su trabajo en trozos agradables al final del día, incluso si no fue tan cuidadoso durante el día mientras trabajaba.

git citool puede permitirle seleccionar qué trozos específicos de un archivo (o qué líneas específicas) comprometer en una confirmación particular, para que pueda dividir (no superponer) los cambios realizados en el mismo archivo en varias confirmaciones.

(Parece que usa Subversion. No conozco una herramienta que haga esto para Subversion, pero podría considerar usar git-svnel adaptador de Subversion para git, que cambiará su vida).

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

Para responder tu pregunta:

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

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

3) En las etapas semi-tempranas del desarrollo, permito que los commits incluyan la primera creación de los archivos que se usarán más adelante.

Me gustaría señalar que al terminar me refiero a que todos los errores que puede identificar se han solucionado y no se romperá la compilación al cometer.

Sí, esto genera una gran cantidad de confirmaciones, pero le permite deshacer exactamente lo que rompió las cosas en lugar de tener que revertir una gran serie de cambios que se confirmaron 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 esté usando uno de esos, se compromete cada vez que ha realizado un cambio, pero aún no lo ha probado y luego empuja al repositorio central cuando está funcionando. Esto es preferible ya que le permite revisar más cambios en su código sin preocuparse por romper la compilación.

En mi caso, estoy tratando de confirmar los archivos de un servidor en el sistema de repositorio (SVN). Esta es la confirmación inicial y no quiero descargarla, ya que es un proyecto realmente grande (unos pocos GB) y quiero hacer la confirmación inicial desde el servidor del cliente.

El problema es que el cliente está en un servidor compartido, el cliente svn se mata (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 estoy interesado en saber si hay una opción en SVN para dividir la confirmación grande en más, algo 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 de código de pares para cada confirmación. Por lo tanto, cualquier compromiso que dificulte que un compañero descubra lo que está sucediendo y lo revise en un período de tiempo razonable es demasiado grande.