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

Fui travieso ... Demasiado "código vaquero", no me comprometí lo suficiente. Ahora, aquí estoy con un enorme compromiso. Sí, debería haber estado comprometiéndome todo el tiempo, pero ya es demasiado tarde.

¿Qué es mejor?

1. Haga una confirmación muy grande que enumere todas las cosas que cambié
2. Intente dividirlo en confirmaciones más pequeñas que probablemente no se compilarán, ya que los archivos tienen múltiples correcciones, cambios, nombres de métodos adicionales, etc.
3. Intente realizar reversiones parciales de archivos solo para las confirmaciones apropiadas, luego vuelva a colocar los nuevos cambios.

Nota: a partir de ahora soy el único programador que trabaja en este proyecto; la única persona que analizará cualquiera de estos comentarios de compromiso soy yo, al menos hasta que contratemos más programadores.

Por cierto: estoy usando SVN y Subclipse. Creé una nueva rama antes de hacer cualquiera de estos cambios.

Más información : hice una pregunta por separado relacionada con cómo me metí en esta situación en primer lugar: cómo prepararse para reescribir el pegamento de una aplicación

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

• Para ver qué versión se introdujo un error.
• Para ver por qué una determinada línea de código está presente.
• Para fusionarse en otra rama.
• Para poder consultar 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 un lanzamiento.

Las dos primeras razones pueden servirse de la misma manera con un gran check-in, suponiendo que pueda crear un mensaje de check-in que se aplique igualmente bien a cada línea de código modificado. Si usted es el único programador, las confirmaciones más pequeñas no harán que su fusión sea más fácil. Si no planea hacer una versión o prueba con solo una parte de sus cambios no enviados, entonces las dos últimas razones no se aplican.

Hay otras razones para hacer pequeños commits, 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 retroceder un error o un cambio experimental, y que sea más fácil mantenerse sincronizado con colegas sin grandes fusiones de miedo.

Según tengo entendido de su situación tal como la describió, parece que hay poco o ningún beneficio en dividir su compromiso en este momento.

Creo que hagas lo que hagas, trata de evitar registrar el código que sabes que no se compilará.

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

La razón más importante para realizar confirmaciones frecuentes, pequeñas y significativas es ayudar a comprender la historia 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 ofusca el historial de cambios que ha realizado, pero de lo contrario no causará ningún problema.

La opción 2 ofusca el historial de cambios que ha realizado, posiblemente algo menos que la opción 1, pero podría causar otros problemas para usted u otros si asumen o concluyen que las confirmaciones son distintas, por ejemplo, pueden fusionarse en otras ramas de forma independiente. A menos que haya una razón práctica sólida por la que se prefiere esto a la opción 1, es menos ideal.

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

De acuerdo con la información que ha proporcionado, optaría por la opción 1. ¿Quizás debería configurar recordatorios para que confirme los cambios?

Creación de prototipos y reescritura

Otra consideración a tener en cuenta, especialmente a la luz de su nota sobre 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 estamos creando prototipos de código nuevo en lugar de mantener o ampliar 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 prototipos de código nuevo, confirme cada vez que desee guardar sus cambios, casi con seguridad en una rama, pero tal vez en un proyecto separado. O tal vez incluso simplemente trabajar fuera del control de versiones por completo. En su lugar, puede concentrarse en reunir evidencia sobre la viabilidad de varias hipótesis o diseños que está considerando. A menudo escribo prototipos pequeños 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 escribirlo en su proyecto principal, idealmente en una rama, y ​​realice los compromisos pequeños y significativos que ayudarán mejor a la comprensión de los demás (incluido el futuro) en cuanto a la naturaleza de los cambios estás haciendo

Aunque la única respuesta razonable es nunca romper el tronco , algunas veces no es posible. Por ejemplo, svn puede romper el compromiso si se compromete demasiado (tal vez una opción o una característica, no estoy seguro). En tales casos especiales, solo regístrese en pedazos. Como usted es un programador único, no molestará a nadie.

Por lo tanto, elegiría 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 compilarán, 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 característica particular: git add --patch
2. Guarda todos los demás cambios: git stash save --keep-index
3. Ejecute pruebas / intente compilar
4. Confirmar cambios si todo está bien, si no, vaya a 1

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

¿Qué tal la opción 4 ?: Haga una copia de seguridad del estado actual de su repositorio en un lugar temporal, revierta su repositorio a su estado original, haga una lista de todos los cambios que hizo (aún puede ver la copia de seguridad temporal), luego vuelva a implementar manualmente (y compile y probarlos!) como commits separados.

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

Cuando haya vuelto a implementar cada cambio de manera limpia y, de este modo, se haya asegurado de que las confirmaciones sean independientes, pequeñas y compiladas, puede eliminar la copia de seguridad temporal, y todo será casi exactamente como (excepto la hora / fecha de las confirmaciones) hubiera sido si lo hicieras desde el principio.

Eres el único programador; solo haz un registro masivo detallado que detalla las partes importantes de lo que hiciste.

¿Es probable que revierta "partes" de lo que hizo? Si no, entonces 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 ellos, 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 a ese último punto de control.

Es poco probable que un programador que ingresa al proyecto más tarde quiera volver a una versión que no se compila. Entonces, en mi humilde opinión, la opción 2 es la locura.

La opción 3 suena como una pérdida de tiempo, que si yo fuera tu jefe y te viera desperdiciando horas haciendo esto, hablaría contigo sobre lo que vale 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 escaparatismo.

Mi regla es: no registrarse sin una revisión seria del código. Si estoy solo, tendré que revisar el código yo mismo, pero será revisado. 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 automáticamente asume erróneamente que su propio código es correcto )

La regla totalmente inquebrantable de todos es: nunca registre un código que ni siquiera se construye, y evite seriamente registrar un código que no funciona.

Solución: copie el código modificado y 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ó, seguramente encontrará algunos errores graves de esa manera.

También es una buena manera de capacitarse en 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 para trabajar, entonces depende completamente de usted lo que haga. Supongo que nadie lo va a castigar por realizar una gran confirmación, por lo que los únicos problemas con los que se encontrará son tecnológicos, como no poder deshacer los cambios de archivos individuales dentro de la confirmación. Sin embargo, dado que usted tiene el control exclusivo del repositorio en este momento, tampoco debería ser una gran preocupación.

Hay 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 los largos retrasos entre confirmaciones, sino en el hecho de que mantiene el código en estado no compilable durante demasiado tiempo. En primer lugar, ¿cuál es su 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 perdió el control de su código, su 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. ¿Entonces estás frustrado? Tu código no se compila, ¿ni siquiera tienes pruebas unitarias? ¿Cómo puedes pensar en refactorizar en este caso? Sin preocupaciones. Termine su "codificación de vaquero" y comience a limpiarla. Lo ideal es intentar escribir algunas pruebas. ¿No tienes tiempo para eso? Ok, comienza con pequeñas mejoras.

Algunos cambios no requieren pruebas. Cambie el nombre de la variable por una más adecuada, mueva el código repetido a una función separada, etc. Obtendrá una mejor idea de su código. Después de eso puedes hacer cambios más grandes. Nuevamente, intente escribir pruebas si es posible. Haz tu código manejable.

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