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.