¿El control de versiones es sobre el historial de implementación o el historial de desarrollo?

… digamos que reviso algún código, hago un pequeño desarrollo o refactorización o lo que sea … ¿solo lo reviso cuando estoy completamente feliz? … ¿y si cambio de opinión sobre cosas mientras estoy codificando? ¿Puedo volver a una versión local anterior? ¿Hay una historia de mi desarrollo local?

¿El control de versiones es sobre el historial de implementación o el historial de desarrollo?

Curiosamente, aún no se menciona a nadie usando bifurcaciones.

Las twigs son una excelente manera de mantener el tronco saludable mientras revisas continuamente lo que sea que estés haciendo, roto o no. Piense en ello como una nueva línea de time para el código; la línea de time primaria (el tronco) resuena y siempre está funcionando; las twigs pueden ser cualquier estado sin afectar el tronco.

Esto te permite comprometerte temprano y con frecuencia sin tener que preocuparte si has arruinado a alguien más, y te garantiza que nunca tendrás un I -ve-ido-demasiado-y-no-puedes-invertir-este momento cuando desarrolles algo nuevo, o un oh-señor-he-perdido-a-semana si tu disco local debería morir. (¡No hace falta decir que su repository debería vivir en algún lugar con frecuencia respaldado!)

Una vez que su código esté funcionando, puede fusionar la twig de nuevo al tronco, y el tronco ahora obtiene su nuevo código; las nuevas twigs del tronco ahora tienen todo el código de funcionamiento hasta el momento.

Este es el gran atractivo de git para muchos: es muy fácil de ramificar y fusionar, por lo que es muy fácil simplemente lanzar una nueva twig, o incluso twigs de twigs, cuando sea necesario. Incluso CVS puede hacer ramificaciones y fusionarse, aunque es considerablemente más engorroso.

Respuesta corta. Son ambos.

Debe poder retroceder a versiones anteriores por muchas razones.

"¿El control de versiones es sobre el historial de implementación o el historial de desarrollo?"

Ambos.

Revisiones / versiones de files para desarrolladores y sucursales / tags / tags para implementación.

Mucho de esto depende de las políticas de su organización.

En cuanto a copys y revisiones locales, si tiene un VCS que permite áreas de trabajo privadas / sucursales y luego promoción o un sistema distribuido, realmente no importa si ingresa el código incorrecto y puede usar el VCS para cosas privadas. usted quiere.

Para un sistema centralizado, probablemente no desee verificar el código no probado / no disponible …

nuevamente, esto depende de tu organización.

Ambos, pero principalmente historia de desarrollo. El maletero no necesita estar en un estado desplegable todo el time, eso sería una locura.

En su lugar, compromete commit commit hasta que esté listo para implementar. Luego, etiquete / etiquete / bifurque su repository para indicar qué código se implementó.

er, ambos …

Debería revisar su trabajo en cualquier momento en que sea estable; esto ocurrirá muchas veces en desarrollo.

Todos los repositorys de origen tienen una versión de labeldo; usted usa esto para marcar las versiones de lanzamiento que son las que finalmente se implementan.

Así que el desarrollo en su mayoría, pero también se libera intrínsecamente.

Depende de usted, de su equipo y de sus herramientas. Por ejemplo, con un sistema de control de versiones centralizado, no debe asignar material "roto" o "incompleto", mientras que con uno distribuido puede hacerlo, y obtendrá ventajas si lo hace. Vea aquí para ejemplos más detallados (e interesantes): http://bazaar-vcs.org/Workflows

Creo que la respuesta correcta es "depende" 🙂

Si está utilizando el control de versiones en un entorno de producción, se trata del historial de implementación. Si lo está usando en un desarrollo, se trata del historial de desarrollo. Si está utilizando el mismo sistema de control de versiones en ambos lugares (no es raro), entonces probablemente variará según la sucursal. Por ejemplo, tendría las twigs troncales y características que tratan sobre el desarrollo, luego las ramificaría en twigs de liberación que se colocarían en los sistemas de producción. El historial de las twigs de publicación muestra el historial de implementación.

Algunos sistemas de control de versiones, como git y mercurial, y creo que SVK (un raro SVN modificado) te permiten tener repositorys locales de los que puedes get versiones locales previas. AFAIK, ninguno de estos le permitirá retroceder si al less no ha confirmado su cambio a su repository local. Eclipse también le permite retroceder a versiones anteriores independientemente de su sistema de control de versiones.

El control de versiones tiene que ver con la security y la modificación simultánea de la información almacenada. Incluso con el software de control de versiones, aún necesita definir qué es la versión y qué unidad de deployment es. Sin él, el control de versiones solo ofrece un mecanismo de reversión básico y muchas opciones de bajo interés y significado sutil.

El margen entre estos dos es muy pequeño. Sin embargo, si el control de la versión se usa de forma correcta, se trata del control de la fuente, es decir, el control / historial de desarrollo. Si se usa bien, se echa un vistazo con frecuencia y se obtiene un buen historial de versiones, que también se puede usar para rastrear cuándo se hizo qué, para informar sobre el time y hacer reservas cuando se producen errores.

La respuesta corta es, ambas cuando se usan correctamente 🙂

… digamos que reviso algún código, hago un pequeño desarrollo o refactorización o lo que sea … ¿solo lo reviso cuando estoy completamente feliz?

Esta es una cuestión de preference personal. Claro que puede verificar el código que no comstack o donde la característica que estaba agregando no está completa. Pero podría ser una molestia para cualquier otra persona que acceda a su repository (si es que lo hay) ver los files que no funcionan. Creo que la respuesta a esto depende en gran medida del tamaño del equipo de su proyecto y la personalidad del equipo.

¿Hay una historia de mi desarrollo local?

Depende del sistema de control de fuente específico que use. Git te permite rastrear los cambios locales.

¿El control de versiones es sobre el historial de implementación o el historial de desarrollo?

El historial de desarrollo, aunque no veo qué le impida consultar los files desplegables y los files de configuration en el repository con cada versión (sin embargo, hay probablemente mejores sistemas para rastrear este tipo de cosas).

En términos de control de return, cuando comprometes depende de la política de tu equipo. Algunos equipos usan herramientas de continuous integration para asegurarse de que la versión actual del código comstack y pasa las testings, lo que significa que, por lo general, no debería comprometer el código roto. Trabajar en una sucursal puede mitigar el riesgo de pérdida de trabajo en esta situación.

Para la historia local, no se obtiene de forma gratuita con el control de la versión, aunque algunos IDE mantienen sus propios historiales locales.

Jeff cree que deberías registrarte temprano, registrarte a menudo . Entonces me suscribo al mismo tipo de idea. Sin embargo, la forma en que lo hago es usar mi troncal como mi repository principal que es "seguro" para la producción, mientras que mis twigs son donde hago todo mi desarrollo. De esta forma puedo verificar todos mis cambios cuando quiera sin preocuparme de que vaya a producción. Cuando termine con esa mejora particular, me fusiono de esa twig al tronco.

Definitivamente es una elección personal en cuanto al momento del check-in y el check-in. Algunas cosas que pueden ayudar a determinar la mejor opción serían si usa un sistema de control de versiones central o distribuido, así como si hay un equipo o una persona trabajando en el código.

Con los sistemas distribuidos, lo que registras es local para ti y solo lo que eliges presionar a los demás es lo que ven, así que si tienes un tree roto porque haces check-in frecuentemente, no importa, mientras que con un repository central deberías se registrará en el tronco, entonces generalmente es una buena idea tener solo el código de trabajo registrado. ¿Cómo se sentiría si hiciera una actualización de su tree y alguien más en su equipo rompiera el código y entonces su copy ya no se comstackrá? Una forma sencilla de evitar este problema en una configuration de repository central sería ramificar el código de la línea externa, hacer que los cambios se comprometan con frecuencia y luego, cuando esté satisfecho de que esté funcionando correctamente, podrá fusionar la twig nuevamente en la línea troncal. De esta forma no se evita que trunk se encuentre siempre en estado ejecutable, que es un estado útil para mantenerlo. Esto se vuelve aún más importante a medida que agrega personas a su equipo.

Con respecto a volver a las versiones anteriores, esto no es un problema si se ha registrado en el repository. Puede volver tantas versiones como desee al mirar el logging de compromiso y luego usar el command correspondiente para volver a una revisión específica.

Eso depende de cómo se use su sistema de control de versiones …

En mi experiencia, la mayoría de las empresas lo usan para el historial de implementación en la mayoría de los sentidos. Es decir, solo se debe include el código de trabajo. Si comtesting algo y luego está en el process de agregar un bloque de código que aún no funciona, al volver a revisarlo, significa que existe la posibilidad de que alguien más esté prestando un service. un producto roto

Me he topado con situaciones en las que las empresas lo usan para que revises tu código cada mañana y en cualquier estado en el que estés al final del día. Lo revisas de nuevo. De esa forma, si alguien más quiere agregar algo, puede hacerlo. de qué estado está actualmente … y aunque puedo ver algo de sentido en la lógica, eso simplemente no funciona para mí.