¿Qué debo hacer cuando ya he esperado demasiado tiempo entre las confirmaciones?

Para responder, debe preguntarse cómo espera utilizar los resultados de estos compromisos en el futuro. Las razones más comunes son:

• Para ver qué lanzamiento se introdujo un error.
• Para ver por qué una cierta línea de código está presente.
• Para fusionarse en otra rama.
• Para poder verificar una versión anterior para solucionar un problema que un cliente o probador está viendo en esa versión.
• Para poder incluir o excluir ciertas partes de una versión.

Las dos primeras razones pueden servirse igual de bien con un gran registro de entrada, asumiendo que puede crear un mensaje de registro que se aplique igualmente bien a cada línea de código cambiado. Si usted es el único programador, los compromisos más pequeños no harán que su fusión sea más fácil. Si no planea realizar un lanzamiento o realizar pruebas con solo una parte de sus cambios no enviados, entonces las dos últimas razones no se aplican.

Hay otras razones para hacer confirmaciones pequeñas, pero son para cuando estás en medio de los cambios, y ese tiempo ha pasado. Esas razones hacen que sea más fácil deshacer un error o un cambio experimental, y que sea más fácil mantenerse sincronizado con colegas sin grandes fusiones temibles.

A partir de mi comprensión de su situación como la describió, parece que hay poco o ningún beneficio en dividir su compromiso en este momento.

Creo que sea lo que sea que hagas, intenta evitar ingresar el código que sabes no compilará.

Si cree que su tercera opción es factible, esa podría ser una buena forma de hacerlo, siempre que pueda asegurarse de que su secuencia de confirmaciones no cree un sistema no compilable. De lo contrario, solo haz el gran compromiso. Es feo, pero es simple, rápido, y lo hace. En el futuro, cometa más a menudo .

La razón más importante para realizar confirmaciones frecuentes, pequeñas y significativas es ayudar a comprender el historial del código. En particular, es muy difícil entender cómo ha cambiado el código si es difícil generar diferencias comprensibles.

La opción 1 oculta el historial de cambios que has realizado, pero de lo contrario no causará ningún problema.

La opción 2 confunde el historial de cambios que has realizado, posiblemente un poco menos que la opción 1, pero podría causar otros problemas para ti o para otros si asumen o concluyen que los compromisos son distintos , p.ej Se pueden fusionar en otras ramas de forma independiente. A menos que haya una fuerte razón práctica por la que se prefiera esto a la opción 1, esto es menos ideal que él.

La opción 3 es la mejor, todo lo demás es igual, pero si, como ha descrito en otro lugar, hacerlo requeriría cantidades de tiempo "extremas" o incurriría en otros costos significativos, tienen que sopesar esos costos con los beneficios esperados de crear compromisos más limpios.

Según la información que ha proporcionado, optaría por la opción 1. ¿Tal vez debería configurar recordatorios para que confirme sus cambios?

Creación de prototipos y reescritura

Otra consideración a tener en cuenta, especialmente a la luz de su nota acerca de ser el único programador, y mi sospecha de que está trabajando en una base de código relativamente nueva, es que probablemente sea bueno desarrollar diferentes hábitos con respecto a cometer cambios para cuando está creando un prototipo de código nuevo en lugar de mantener o extender el código existente. Probablemente no haya una división terriblemente aguda entre los dos, pero creo que sigue siendo una distinción útil.

Cuando esté creando un nuevo código de creación de prototipos, confirme cada vez que quiera guardar sus cambios, casi con seguridad en una sucursal, pero quizás en un proyecto separado. O tal vez incluso simplemente trabajar fuera del control de versiones en conjunto. En su lugar, puede concentrarse en reunir evidencia sobre la viabilidad de varias hipótesis o diseños que esté considerando. A menudo escribo pequeños prototipos usando diferentes herramientas, por ejemplo. LINQPad en lugar de Visual Studio para el código C #.

Cuando haya validado una hipótesis o diseño en particular, vuelva a escribirla en su proyecto principal, idealmente en una rama, y realice las confirmaciones pequeñas y significativas que ayudarán mejor a la comprensión de los demás (incluido su futuro) en cuanto a la naturaleza. de los cambios que estás haciendo.

Aunque la única respuesta razonable es nunca rompa el tronco , algunas veces no es posible. Por ejemplo, svn puede romper el compromiso si comprometes demasiado (tal vez una opción o una característica, no estoy seguro). En tales casos especiales, simplemente registrarse en piezas. Dado que usted es un programador único, no va a molestar a nadie.

Por lo tanto, optaría por la opción 1. Si no es posible, entonces la opción 2.

La opción 3 requiere mucho esfuerzo, y simplemente no vale la pena.

  

Intente dividirlo en confirmaciones más pequeñas que probablemente no se compilen, ya que los archivos tienen múltiples correcciones, cambios, nombres de métodos adicionales, etc.

Cuando me encontré en una situación similar, utilicé la siguiente técnica:

1. Agregue solo el código que sea relevante para una función en particular: git add --patch
2. Guarda todos los demás cambios: git stash save --keep-index
3. Ejecutar pruebas / intentar compilar
4. Confirma los cambios si todo está bien, si no vas a 1

No estoy familiarizado con SVN, así que no sé si esto es aplicable a su situación específica, pero la base debería ser la misma: aísle pequeñas partes del código y pruébelas individualmente.

¿Qué hay de la opción 4? Realice una copia de seguridad del estado actual de su repositorio en un lugar temporal, revierta el repositorio a su estado original, haga una lista de todos los cambios que realizó (aún puede consultar la copia de seguridad temporal) y luego vuelva a implementarlos manualmente. (y compílalos y pruébalos) como comillas separadas.

Esto debería ser más fácil, porque ya has escrito el código, es solo un poco de averiguar qué partes copiar y pegar desde tu copia de seguridad temporal.

Cuando haya reimplementado todos los cambios de manera limpia y, por lo tanto, se aseguró de que las confirmaciones sean autocontenidas, pequeñas y compiladas, puede eliminar la copia de seguridad temporal, y todo será casi exactamente igual (excepto la hora / fecha de confirmaciones) habría sido si lo hubieras hecho bien desde el principio.

Eres el único programador; solo haga un registro masivo detallando los puntos importantes de lo que hizo.

¿Es probable que retroceda "partes" de lo que hizo? Si no, continúe con la opción 1.

Hay un par de razones para verificar el código en un sistema de control de versiones. Y TODOS, cuando eres el único desarrollador, giran en torno a la seguridad, es decir, si te equivocas, la máquina muere o lo que sea, siempre puedes volver al último punto de control.

Es poco probable que un programador que ingrese al proyecto más adelante quiera volver a una versión que no se compile. Así que, en mi humilde opinión, la opción 2 es una locura.

La opción 3 suena como una pérdida de tiempo tal que, si yo fuera tu jefe y te viera perder horas haciendo esto, hablaría contigo un poco sobre el valor de tu tiempo.

Para iterar: al registrar su código, está cubriendo / guardando su trasero en caso de falla en su máquina. Todo lo demás, en un equipo de un solo hombre, es escaparate.

Mi regla es: ningún registro sin una revisión seria del código. Si estoy por mi cuenta, tendré que revisar el código yo mismo, pero se se revisará. Parece que tiene una cantidad de cambios en el código que otra persona no pudo revisar, por lo tanto, no puede revisarlo usted mismo (revisar su propio código es más difícil y requiere más disciplina, porque asume automáticamente que su propio código es correcto ).

La regla totalmente irrompible de todos es: nunca ingrese el código que ni siquiera se construye, y evite seriamente el código que no funciona.

Solución: Copie el código modificado, vuelva al punto original. Combine un cambio a la vez en el código original, revíselo, pruébelo, verifíquelo. Con el método de programación que describió, está obligado a encontrar algunos errores graves de esa manera.

También es una buena forma de aprender buenos hábitos de programación.

Creo que te estás preocupando demasiado. Si usted es el único programador y no tiene una hoja de especificaciones con la cual trabajar, entonces depende totalmente de usted lo que haga. Supongo que nadie lo castigará por cometer un gran compromiso, por lo que los únicos problemas con los que se encontrará son tecnológicos, como no poder deshacer los cambios de archivos individuales dentro del compromiso. Ya que solo tienes el control del repositorio en este momento, tampoco debería ser una gran preocupación.

Hay que trazar una línea entre el pragmatismo y el dogmatismo. Lo que hiciste no sería una buena idea en un equipo y probablemente no debería repetirse en el futuro, pero en tu situación simplemente enviaría el gran compromiso.

El problema no está en largos retrasos entre confirmaciones, sino en el hecho de que mantiene el código en un estado no compilable durante demasiado tiempo. En primer lugar, ¿cuál es tu definición de 'largo'? Para algunas personas, 5 minutos para el estado de transición es demasiado, pero algunos pueden pulir su código durante días sin siquiera intentar ejecutar el compilador.

De hecho, no importa, lo que importa es que perdiste el control de tu código, tu código se volvió inmanejable. Esto es normal, solo significa que tiene una deuda tecnológica y es hora de pensar en la refactorización. ¿Así que estás frustrado? ¿Tu código no se compila, ni siquiera tienes pruebas de unidad? ¿Cómo puedes pensar en refactorizar en este caso? Sin preocupaciones. Termina tu "codificación de vaquero" y comienza a limpiarlo. Lo ideal es tratar de escribir algunas pruebas. ¿No tienes tiempo para eso? Ok, empieza con pequeñas mejoras.

Algunos cambios no requieren pruebas. Cambie el nombre de la variable para que sea más adecuado, mueva el código de repetición a una función separada, etc ... Obtendrá una mejor idea de su código. Después de eso puedes hacer cambios más grandes. Una vez más, intente escribir pruebas si es posible. Haga que su código sea manejable.

Después de eso, verás que el próximo cambio no te llevará "demasiado tiempo" (lo que sea que signifique).