La teoría (y la terminología) detrás del control de código fuente

Question

He intentado utilizar el control de código fuente para un par de proyectos pero todavía no lo entiendo. Para estos proyectos, hemos utilizado TortoiseSVN y solo hemos tenido una línea de revisiones. (Sin tronco, rama ni nada de eso.) Si hay una forma recomendada de configurar los sistemas de control de origen, ¿qué son? ¿Cuáles son las razones y los beneficios para configurarlo de esa manera? ¿Cuáles son las diferencias subyacentes entre el funcionamiento de un sistema de control de fuente centralizado y distribuido?

Answer 1

recomiendo echar un vistazo a la siguiente de Eric Sink:

http://www.ericsink.com/scm/source_control.html

Tener algún tipo de sistema de control de revisiones en su lugar es probablemente la herramienta más importante que un programador tiene para la revisión de los cambios de código y la comprensión quién hizo qué a quién. Incluso para proyectos de una sola persona, es inestimable poder diferenciar el código actual de la versión de trabajo conocida anterior para comprender qué podría haber salido mal debido a un cambio.

Answer 2

Piense en el control de fuente como un botón gigante de "Deshacer" para su código fuente. Cada vez que ingresa, está agregando un punto al que puede retroceder. Incluso si no usa la bifurcación/fusión, esta característica sola puede ser muy valiosa.

Además, al tener una versión 'autorizada' del control de origen, se vuelve mucho más fácil hacer una copia de seguridad.

Centralizado vs. distribuido ... la diferencia es que en distribuido, no hay necesariamente una versión 'autoritativa' del control de fuente, aunque en la práctica las personas usualmente todavía tienen el árbol maestro.

La gran ventaja de control de código fuente distribuido es doble:

1. Cuando uso Distribuido control de código fuente, que tienen todo el código fuente en el equipo local. Puede comprometerse, crear ramificaciones y trabajar prácticamente como si estuviera solo, y cuando esté listo para impulsar sus cambios, puede promocionarlos desde su máquina hasta la copia maestra. Si trabajas "fuera de línea" mucho, esto puede ser un gran beneficio.

2. No tiene que pedir permiso a nadie para convertirse en distribuidor del control de código fuente. Si la persona A está ejecutando el proyecto, pero las personas B y C desean hacer cambios y compartir esos cambios entre ellos, se vuelve mucho más fácil con el control de fuente distribuida.

Answer 3

Incluso si no se bifurca, puede que le resulte útil usar etiquetas para marcar lanzamientos.

Imagine que ha lanzado una nueva versión de su software ayer y ha comenzado a hacer cambios importantes para la próxima versión. Un usuario lo llama para informar un error grave en la versión de ayer. No puede simplemente arreglarlo y copiar los cambios desde su troncal de desarrollo porque los cambios que acaba de hacer lo hacen todo inestable.

Si etiquetó el lanzamiento, puede ver una copia de trabajo y usarlo para corregir el error.

Luego, puede elegir crear una rama en la etiqueta y verificar la corrección de errores en ella. De esta forma, puede corregir más errores en esa versión mientras continúa actualizando la troncal. También puede combinar esas correcciones en el tronco para que estén presentes en la próxima versión.

Answer 4

Aquí hay dos artículos que son muy útiles para comprender los conceptos básicos. Más allá de ser informativo, la compañía de Sink vende un gran producto de control de fuente llamado Vault que es gratuito para usuarios individuales (no estoy afiliado de ninguna manera con esa compañía).

http://www.ericsink.com/scm/source_control.html

http://betterexplained.com/articles/a-visual-guide-to-version-control/

información Vault www.vault.com.

Answer 5

El estándar común para configurar Subversion es tener tres carpetas debajo de la raíz de su repositorio: tronco, ramas y etiquetas. La carpeta troncal contiene su línea actual de desarrollo "principal". Para muchas tiendas y situaciones, esto es todo lo que siempre usan ... solo un repositorio de código funcional.

La carpeta de etiquetas va un paso más allá y le permite "controlar" su código en determinados momentos. Por ejemplo, cuando lanza una nueva compilación o, a veces, incluso cuando simplemente crea una compilación nueva, "etiqueta" una copia en esta carpeta. Esto solo le permite saber exactamente cómo se veía su código en ese momento.

La carpeta de sucursales contiene diferentes tipos de ramas que puede necesitar en situaciones especiales. A veces, una sucursal es un lugar para trabajar en funciones o características experimentales que pueden demorar un tiempo en estabilizarse (por lo tanto, no desea introducirlas en su línea principal todavía). Otras veces, una sucursal puede representar la copia de "producción" de su código que puede editarse e implementarse independientemente de su línea principal de código que contiene cambios destinados a una versión futura.

De todos modos, este es solo un aspecto de cómo configurar su sistema, pero creo que es importante pensar en esta estructura.