¿Con qué frecuencia debo / realizo confirmaciones? [duplicar]

Cada vez que tengo algo que funciona (es decir, no rompe nada para nadie más), haré un check-in. Primero escribo la mayoría de mis pruebas de contenido, así que eso significa que cada vez que tengo una nueva prueba que pasa, me registro.

En la práctica eso significa algunas veces por hora. Al menos un par de veces cada hora, con 5 siendo bastante.

No deberías comprometerse en base al tiempo, sino en función de la función. Cada vez que agregue una nueva característica que valga la pena cometer, confíe. ¿Añadiste un método de trabajo? Cometer. ¿Has arreglado un error tipográfico? Cometer. ¿Has arreglado una sangría incorrecta de archivo? Cometer. No hay nada de malo en hacer pequeños cambios, tan pronto como el compromiso sea relevante.

Lo que está mal es cometer una gran cantidad de cambios, sin relaciones entre ellos. Esto hace que sea muy difícil detectar la fuente de confirmación de una regresión dada.

A veces, hago veinte confirmaciones en una hora, y otras veces cometo una vez al día, dependiendo de la cantidad de código que se haya modificado.

Hacer pequeñas confirmaciones te permite usar herramientas muy poderosas como git-bisect.

No olvides la regla n ° 1 del operador: nunca rompas el maletero. Si necesita realizar varias confirmaciones que puedan romper el tronco, cree una rama en su lugar.

Depende un poco de lo que sea el entorno de desarrollo.

Si usted es el único que contribuye a una base de código, entonces un compromiso diferido no será tan crucial. Sin embargo, si está en un equipo de varios desarrolladores, y todos piensan: "bueno, esperaré un poco", entonces a menudo terminará manejando muchos conflictos y perdiendo mucho tiempo.

La regla general (para ambos escenarios) sería: Comprometerse tan a menudo como sea posible. Si crees que "aún no está listo" (porque romperá la compilación o simplemente no está listo todavía), crea una rama y comprométete con esa rama, pero asegúrate de que la confirmes.

Al menos una vez al día, generalmente tres o cuatro, ya que tiendo a comprometerme cada vez que me tomo un descanso. Trabajo solo, así que no tengo que preocuparme por arruinar a otra persona, y siempre puedo revertir un archivo si creo que he tomado el camino equivocado.

Una vez tuve una mala experiencia cuando no estaba haciendo confirmaciones regularmente y mi disco duro se estrelló y perdí algunas horas de trabajo. Dado que mi repositorio está en otra máquina y se realiza una copia de seguridad con regularidad, no hay razón para que haya perdido nada.

Gracias a las sucursales de git y su fácil manejo, me comprometo muy a menudo. Yo diría que, cada vez que agregues algo que consideres importante y que se pueda acumular para construir algo más adelante, deberías comprometerte.

Además, a menudo me encuentro refactorizando y agregando nuevas pruebas antes del nuevo código, por lo que en este caso me comprometo cada vez que ejecuto la prueba, la veo fallar, la hago pasar nuevamente y la refactorización.

Además, después de cualquier corrección de errores, no importa cuán pequeño o insignificante pueda parecer.

A veces, también voy por el camino "cometerlo en cuanto se compila".

En DVCS, me comprometo básicamente en cualquier momento en el que comience un cambio que sería realmente molesto si no pudiera deshacer, en el momento en que necesito compartir con otros, o en cualquier momento sería realmente útil ver lo que he cambiado desde ese punto. Eso va desde varias veces por hora hasta un par de veces por día. Además, rara vez me comprometo cuando mi compilación no se compila ni se ejecuta al menos sin segregaciones inmediatas, aunque eso también puede ser útil si quiere poder aislar y compartir solo la solución para ese error en particular.

Tenga en cuenta que con el control de versión centralizado, que es muy probable que deba utilizar en el trabajo, generalmente no se compromete hasta que esté bastante seguro de que no recibirá una tormenta de correos electrónicos enojados por hacerlo. Dependiendo de qué tan independientes sean los cambios que realice y de cuánto se suscriba su compañía al dogma de la integración continua, eso va más allá de una vez al día o quizás una vez al mes en una nueva característica importante.

Esa diferencia de frecuencia es una de las razones principales por las que uso git en la parte superior del VCS centralizado oficial de mi empresa.

Si estás trabajando en un entorno de equipo con un servidor de compilación, solo querrás comprometerte cuando tienes algo que compila. Es muy molesto para el resto del equipo :)

He visto esta presentación de Joel On Software - FogBugz / Kiln y creo que se relaciona bien con tu pregunta.

Mientras que en algunos controles de versión, "commit" es sinónimo de "publicar" (o "dar dolor a los demás") en VCS distribuidos, a menudo están separados.

Por lo tanto, cuándo comprometerse dependerá del VCS que uses.

Confirmar automáticamente después de cada compilación exitosa.

Supongo que si desea volver a una versión anterior y puede recordar la hora aproximada del reloj de pared del punto al que desea volver, solo puede consultar esa revisión.

Por supuesto, si usa TDD, entonces hay mejores soluciones integradas.

Todas las noches, cuando voy a casa, tengo un script que automáticamente pasa por todas mis sucursales y hace un compromiso (tenga en cuenta que todos los desarrolladores no reciben estos cambios. Es solo mi sucursal personal). De esta manera no tengo que pensar en ello.

También tengo un script que ejecutará automáticamente una actualización en la mañana. Utilizo este para que si trabajo desde mi computadora portátil por la noche, mis cambios se realicen automáticamente en la mañana.

En cuanto a deshacer los cambios que realicé durante el día, mi editor tiene un historial de todos los cambios y es mucho más rápido que realizar un compromiso en cada guardado / compilación.

Trabajo solo. Mi entorno de desarrollo es mi portátil. El entorno de compromiso es un servidor en la web.

Si el cliente utiliza el servidor web para realizar un seguimiento del progreso. Así que casi todos los días hago una carga junto con un correo electrónico que dice las novedades.

Si el entorno de compromiso es un entorno de producción, tengo que tener más cuidado con cada cambio que se está probando antes de cualquier compromiso. Pero aún así, a menudo parece mejor, ya que nadie tiene dudas sobre si la nueva característica ya está planeada o lista; obtienen lo que piden lo antes posible.