¿Los mejores hábitos de control de versiones para un desarrollador en solitario?

Soy un desarrollador exclusivo en mi trabajo y, si bien entiendo los beneficios de VCS; Me resulta difícil apegarme a las buenas prácticas. En este momento estoy usando git para desarrollar principalmente aplicaciones web (que nunca serán de código abierto debido a mi trabajo).

Mi flujo de trabajo actual es hacer muchos cambios en el sitio de desarrollo, probar, revisar, probar, ser feliz y confirmar los cambios, y luego empujar el compromiso al sitio en vivo (así que si estoy trabajando en un gran cambio nuevo; solo puedo cometer una vez por semana; pero mi IDE tiene un buen historial de deshacer para cosas no confirmadas).

Básicamente, solo estoy usando git cuando cambio entre máquinas (por ejemplo, computadora de desarrollo de trabajo a computadora de desarrollo doméstica o máquina en vivo), pero durante el día realmente no veo el beneficio. Esto me lleva a tener largas listas de cambios (y tengo problemas para encontrar un buen mensaje para cada confirmación; y cada vez que tengo prisa, tiendo a dejar mensajes desagradables como "cambios misceláneos en el administrador y las plantillas").

¿Con qué frecuencia debo comprometerme? ¿Debería cada cambio de una línea obtener una confirmación? ¿Debo confirmar antes de cualquier prueba (por ejemplo, al menos para errores de sintaxis / compilación y luego tener que deshacerlo por completo, ya que la idea no funcionó o el mensaje es una mentira)?

¿Debo asegurarme de comprometerme cada mañana / tarde antes de dejar de trabajar para la cena mientras todavía está fresca? ¿Qué me estoy perdiendo por tener malos hábitos de VCS?

Te falta mucho.

También estoy solo, en cierto modo. Me comprometo cada vez que hago un cambio significativo, o antes de comenzar uno significativo, así puedo volver si arruino las cosas, y de vez en cuando, incluso si no estoy haciendo nada grande. No todos los días realmente, pero cerca. Algunas veces algunas veces al día.

Lo que obtengo es que puedo volver cuando quiera. Que es mucho Además, tener las ramas ordenadas ayuda.

Supongo que me da mucho orden.

Estoy usando svn, y me estoy cansando de eso. Pero no puedo pasar más tiempo aprendiendo nada más.

Buena suerte.

Debes comprometerte con frecuencia. Sin duda, debe comprometerse después de alcanzar algún hito lógico. Si eso lleva más de un día, al menos debería comprometerse al final de su día de trabajo, o mejor aún, dividir su trabajo en trozos más pequeños.

Hay muchas razones para hacerlo. Por ejemplo, ¿qué pasa si su computadora falla? Es mucho mejor perder solo un día de trabajo que el de una semana o un mes. Otra razón es que las confirmaciones frecuentes hacen que sea más fácil aislar un error. Puede hacer una búsqueda binaria y descubrir qué pequeño cambio causó el error.

Otra cosa: antes de comprometerse, debe hacer una diferencia y observar todos los cambios que ha realizado. Esto le permite comprobar que todos los cambios tienen sentido y que no ha olvidado nada. Esto también te ayuda a crear un mejor mensaje de confirmación. Y, por supuesto, esta es otra razón para comprometerse con frecuencia: es mucho más fácil pasar por un día de cambios que por un mes.

Para obtener el máximo provecho de CVS, debe trabajar en una función / corrección de errores a la vez, y comprometerse cuando se complete esa función / corrección de errores. Al hacer esto ganarás:

• los mensajes de confirmación serán más fáciles de crear y tendrán más sentido;
• seguimiento más fácil de futuros errores a los cambios que los introdujeron;
• es más fácil volver a un estado anterior (incluso si eso significa perder una característica fallida pero mantener las correcciones de errores que ocurrieron después).

Además, dado que cambia de PC, debe tener al menos dos ramas:

• una rama "Listo para funcionar" que siempre funciona (excepto los errores en los que está trabajando en la rama de desarrollo, por supuesto)
• una rama de desarrollo que puede estar en un estado inestable de vez en cuando (como durante su viaje a casa desde el trabajo;).

¿Debería cada cambio de una línea obtener una confirmación?

Si eso es lo que corrige un error, seguro.

¿Qué me estoy perdiendo por tener malos hábitos de VCS?

Trabajé con un chico que tenía "malos hábitos de VCS". Le encantaba trabajar solo y estaba a cargo de una línea de productos que generaba alrededor de $ 1,000,000 / año. Solo se comprometería cuando el jefe lo fastidiaba. Entonces, un día, su disco duro se estrelló. Después de obtener un reemplazo para él, descubrimos que su último registro fue 6 meses antes. Como el VCS era Source Safe, puedes adivinar qué más salió mal: el último commit estaba dañado. Tuvimos que retroceder más de un año para obtener una versión no corrupta de su línea de productos. No fue despedido, aunque debería haberlo sido.

Otra anécdota me involucra a mí mismo. Solía ​​almacenar código para pasatiempos y proyectos de investigación en discos duros extraíbles. Un día, mi departamento fue allanado. La computadora portátil (que estaba rota) y todos los discos duros extraíbles fueron robados. Todos los DVD (con la excepción de Red Dawn) fueron robados. Ninguna de las computadoras de escritorio fue robada. Si tuviera el control de la fuente fuera del sitio, no habría perdido 15 años de proyectos, especialmente porque algunos se basaron en proyectos académicos; muchos de los profesores dejaron la academia para ir a la industria privada, por lo que esos proyectos se desvanecieron en un agujero negro corporativo de IP que hizo que Código perdido imposible de recuperar.

¿Con qué frecuencia debo comprometerme?

Lo divido en algunas métricas:

• ¿Cuánto trabajo estás dispuesto a perder si tu computadora se apaga? o es robado?

• Si esto corrige el Bug_1234, entonces verifique el código con el comentario "corrige el Bug_1234".

• Si se trata de una entrega / hito lógico, regístrese con un comentario como "Bug_1234, form_xyz" (o Task_1234 según corresponda).

• Siempre verifique el código el viernes por la noche antes de regresar a casa. También haga un check-in (o deshaga los checkouts) de todo antes de irse de vacaciones.

• Cada vez que lo dicta la política de la empresa.

No piense en términos de cambios en el número de líneas. Piense en trozos de funcionalidad. VCS le permite dar un título en un lugar central para cada fragmento de funcionalidad para que pueda ver fácilmente "lo que ha sucedido aquí" con, por ejemplo, git log.

Además, los IDE como Eclipse le permiten apuntar a una línea determinada e ir al commit que la puso en la forma que ve. En otras palabras, puede ir directamente desde una línea de origen a la confirmación. Si el commit es pequeño y tiene un buen mensaje, es mucho más útil que "toneladas de errores corregidos".

Diría que lo más importante que se está perdiendo al agrupar los cambios juntos es la capacidad de rastrear cuándo y dónde se introdujeron los errores.

En mi experiencia, ha habido un par de veces en que se notó algún error dos o tres semanas después de que se introdujo y tener que examinar las confirmaciones de una semana es difícil mucho después del hecho. En estos casos, fue útil simplemente buscar binaria a través de los commits para rastrear qué cambio individual causó el problema. Estos errores fueron principalmente errores de uso de memoria en el código C ++, por lo que puede que no ocurra con tanta frecuencia en su proyecto.

Otros beneficios entran en juego cuando se desarrolla en un equipo: comentarios de confirmación simples, fusiones más fáciles, confirmaciones relacionadas con correcciones de errores, etc.

Supongo que con su flujo de trabajo, si comienza a comprometerse diariamente o semi-diariamente, necesitará usar etiquetas o marcadores para realizar un seguimiento de qué versión de código está en uso en el sitio en vivo. Diría que es lo más importante a tener en cuenta.

También soy un desarrollador en solitario, uso SVN y me encanta. Incluso he escrito una herramienta para convertir la estructura de mi base de datos y los datos de prueba en xml para poder incluir eso en el control de código fuente.

Por lo general, me comprometo cada vez que he completado una unidad de trabajo autónoma. A veces, si realizo un montón de arreglos triviales y no relacionados de una sola línea aquí y allá, los comprometo a todos juntos, pero si ocurre un arreglo de una sola línea entre dos grandes unidades de trabajo autónomas no relacionadas, entonces obtiene su propio cometer, no hay nada de malo en eso.

Además, siempre confirmo el código que compila, y casi siempre el código que también pasa todas las pruebas básicas. Si no, me aseguro de incluir "NO FUNCIONA" en el mensaje de confirmación. El único caso cuando esto sucede es cuando he realizado cambios importantes que no quiero perder a pesar de que todavía no funcionan del todo, y además estoy a punto de embarcarme en una gran aventura de refactorización de la que no estoy seguro si Será exitoso. Entonces, utilizo el repositorio como una copia de seguridad del trabajo que he hecho hasta ahora antes de arriesgarme a estropearlo y tener que tirarlo.

Esto significa que siempre me comprometo cuando mi código fuente necesita ser confirmado; no tiene ningún sentido tener reglas de compromiso de la mañana o de la tarde. Es el estado en que se encuentra el código el que dicta si es hora de comprometerse o no.

Los mensajes que pones en el repositorio no importan mucho. Si absolutamente no puede llegar a algo significativo, es mejor comprometerse con un mensaje en blanco que no hacerlo cuando debería.

Si no puede pensar en un buen mensaje de confirmación porque todo lo que se le ocurre suena estúpido, tenga en cuenta que está bien; se espera que los mensajes de confirmación indiquen lo obvio, por lo que seguramente te sonarán estúpidos cuando los escribas. Pero confía en mí, si necesitas examinar las revisiones anteriores un mes después, estarás agradecido incluso por los mensajes estúpidos sobre ningún mensaje.

Comprométete cada vez que hagas un cambio "lógico". Por ejemplo, si está implementando una nueva característica, lo está haciendo paso a paso. Cada uno de esos pasos generalmente depende el uno del otro. Por lo tanto, puede confirmar esos pasos por separado y explicar en el mensaje de confirmación por qué se requiere cada paso.

El mensaje de compromiso es realmente importante. Debes evitar decir lo que estás haciendo, decir por qué lo estás haciendo. El código ya documenta los cambios, pero en 6 meses te alegrará ver por qué los hiciste.

Esto también es útil si por casualidad alguien interviene y ya no estás solo. Incluso para usted, un historial limpio hace que sea más fácil usar un git blamepara saber cuándo y por qué se ha cambiado esa línea que tiene un error.

Hacer pequeños cambios en lugar de grandes cambios de lodo también te permite probar el estado intermedio. Puede esconder los cambios si tiene que liberar algo con urgencia. Si introduce un error mientras funcionaba antes, puede esconderse y verificar si son sus cambios no confirmados los que introducen el error, o si fue en una confirmación anterior.

También puede desatar el poder de git bissecteso le dirá la confirmación de que este error desagradable. Si el commit tiene 2.000 líneas de largo, todavía ayuda, pero no tanto ...

Otra cosa es que es el primer paso para la integración continua (CI) y luego la implementación continua (CD). CI y sus pruebas se pueden activar en una nueva confirmación, por lo tanto, le indicará cada vez que presione sus cambios si rompen algo o no. De esta manera, puede saber si es seguro implementarlo o no, y recibir una notificación al respecto en el momento en que se presenta el problema y no solo antes de su lanzamiento cuando tiene prisa.

Sobre sus otras preguntas:

• no confirmes cosas que ni siquiera compilaste, a menos que estés dispuesto a reescribir tu historial para eso (usando git rebase --interactive).
• un cambio de una línea merece una confirmación si tiene un propósito separado (corrige un error o no está relacionado con los cambios no confirmados actualmente). Úselo git add --patchpara organizar esos.
• no es necesario obligarse a comprometerse antes de la cena, a menos que tenga cosas importantes que no pueda permitirse perder. En ese caso, es posible que desee comprometer en una rama separada su trabajo en progreso.
• comprometerse y empujar a un repositorio remoto es una copia de seguridad. Si se compromete y presiona solo una vez a la semana, en el peor de los casos puede perder una semana de trabajo.

¿Con qué frecuencia debo comprometerme?

Como desarrollador en solitario, generalmente me comprometo cada vez que siento que he hecho un cambio significativo, después de las pruebas básicas y cuando dejo un proyecto al final de la noche.

¿Debería cada cambio de una línea obtener una confirmación?

No, a menos que ese cambio de una línea cambie significativamente una característica o error.

¿Debo confirmar antes de cualquier prueba (por ejemplo, al menos para errores de sintaxis / compilación y luego tener que deshacerlo por completo, ya que la idea no funcionó o el mensaje es una mentira)?

Probablemente no. Al menos para mí, hago la mayor parte de mis pruebas y codificaciones en una 'copia de trabajo' y me comprometo después de que estoy satisfecho con mis cambios. En muchos IDE, me mostrará lo que cambió antes de hacer el compromiso y me dará la oportunidad de adjuntar notas al compromiso

¿Debo asegurarme de comprometerme cada mañana / tarde antes de dejar de trabajar para la cena mientras todavía está fresca? ¿Qué me estoy perdiendo por tener malos hábitos de VCS?

No estoy muy familiarizado con VCS o los malos hábitos que causa. Creo que he compartido mi opinión sobre esto en respuesta a la primera pregunta.

En respuesta a la pregunta general postulada, parece que está utilizando principalmente commits como ramas que se abordan en otra publicación de respondedores. No estoy seguro de qué IDE está utilizando que tenga un buen historial de deshacer, etc., pero no encontré uno que me pareció que fuera bueno después de reiniciar el IDE y pasar de una máquina a otra.

Soy un confirmador habitual y descubrí que me conviene, pero es cierto que mis mensajes de confirmación casi siempre son,

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Por lo tanto, no puedo decir exactamente que realizar confirmaciones tan frecuentes y habituales en mi rama (mercurial) haya fomentado exactamente los registros de confirmación más detallados. A veces, incluso cometo código a mitad de camino si, por ejemplo, mi esposa me pide que salga a cenar, momento en el que simplemente copiaré y usaré el mensaje de compromiso anterior "Trabajando en [...]".

Mis patrones de registro de confirmación suelen ser, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Sin embargo, por otro lado, me ha salvado el trasero. A veces me encuentro con un caso límite que no anticipé y no probé, en cuyo punto los compromisos frecuentes me ayudan a descubrir exactamente dónde presenté el error.

Por lo tanto, no conozco los mejores hábitos y, desde luego, no soy de los que escucho en cuanto a los hábitos ideales de registro de compromiso, pero ciertamente puedo decir que comprometerse con más frecuencia definitivamente puede ayudar cuando necesita realizar una regresión.

¿Debería cada cambio de una línea obtener una confirmación?

He cometido cambios de una línea antes, pero por lo general son complicados y tal vez tenía poco tiempo. Mis compromisos no siempre se parecen a unidades perfectas y completas de trabajo o cambio. Como se dijo, a veces son solo el resultado de que mi esposa me pidió que saliera a cenar inesperadamente.

TBH, muchos de mis compromisos que siguen ese "Working on [...]"patrón de registro no están modelando unidades coherentes de cambio (por qué a menudo no puedo encontrar un mensaje mejor que "Working on [...]"), sino solo el resultado de tomar un respiro, como prepararme una taza de café. El "Completed [...]"mensaje indica el final de esa unidad de trabajo, y allí a menudo escribo un mensaje mucho más detallado junto con el primer "Started working on [...]"tipo de mensajes cuando empiezo a trabajar en algo. Si promedia las confirmaciones como una vez cada 15 minutos, entonces esos mensajes "Trabajando en [...]" son más como intermedios para lo que alguien podría cometer en una confirmación más voluminosa con un mensaje más detallado.

¿Debo confirmar antes de cualquier prueba (por ejemplo, al menos para errores de sintaxis / compilación y luego tener que deshacerlo por completo, ya que la idea no funcionó o el mensaje es una mentira)?

Simplemente sigo adelante y lo comprometo antes de incluso ejecutar pruebas a veces (nuevamente si tuve un evento inesperado). Además, aunque estoy solo, presiono a un servidor (solo uno que se ejecuta aquí en casa en una LAN) que hace CI. Puede parecer exagerado, pero no sé, me acostumbré a apoyarme en eso en mis antiguos lugares de trabajo. Además, no quiero molestarme en tener que ejecutar todas las pruebas de mi unidad e integración a mano cada vez. Me gusta tener todo eso ligado a solo empujar. Si una prueba falla, es bastante fácil trabajar de manera progresiva donde hago la regresión, corrijo el error en la última revisión y sigo adelante. Dicho esto, al menos compilo el código contra una compilación de depuración antes de comprometerme.

¿Debo asegurarme de comprometerme cada mañana / tarde antes de dejar de trabajar para la cena mientras todavía está fresca?

Me gusta comprometerme antes de salir y tener un descanso entre la programación. Realmente no pensé mucho en por qué exactamente hasta que me encontré con esta pregunta. Supongo que es para evitar que retome desde donde lo dejé sin un registro de confirmación allí en lugar de donde lo dejé que puedo diferenciar y así sucesivamente. Hmm, necesito volver a hablar de eso, ya que tal vez no sea teóricamente necesario dada la frecuencia con la que me comprometo. Todavía me siento más cómodo comprometiéndome y empujando antes de dejar la computadora por cualquier razón. Algo de eso podría ser ese antiguo miedo psicológico a, por ejemplo, la computadora se prendió fuego después de que me fui y tenía gerentes de proyecto en los días en que estábamos usando SVN con los desarrolladores que a veces pasaban semanas sin cometer problemas y nos recordaban constantemente que revisáramos el código con la mayor frecuencia posible mientras nos recordaban que Nuestro código es propiedad de la empresa. Además, es un poco más eficiente, especialmente con la presión para que mi proceso de CI pueda comenzar a ejecutar todas las pruebas mientras estoy fuera, para que pueda volver y ver los resultados.

Ah, y a veces me emborracho un poco después de irme y, por lo general, es una mala idea intentar escribir código complejo mientras estoy borracho (aunque no siempre; una vez se me ocurrió un sistema de menú contextual realmente agradable después de tener un momento eureka mientras estaba borracho, pero solo tenía como 6 cervezas y no era tan complejo de codificar). Si intento hacer eso, al menos cometí el código escrito con sobriedad antes de irme para volver atrás en lugar de mezclar el código borracho con el código sobrio, en cuyo punto mi registro de confirmación podría leer, "Reverting back to code written before Jagermeister shots."no hago esto con mucha frecuencia, a menos que obtuviera una inspiración de código borracho, pero en esos casos raros, realmente ayudó que cometiera algo antes de salir y emborracharme.