Según mi experiencia con los sistemas de control de versiones distribuidas (DVCS) como git y mercurial en proyectos de código abierto, la mayoría de los modelos de configuración utilizan una configuración centralizada para su proyecto (piense en GitHub).Cómo configurar el control de versión distribuida en una empresa
Al introducir VCS distribuidos en una empresa, ¿tiene un modelo de configuración centralizada?
Es una buena idea tener algún tipo de repositorio central, porque le permitirá compartir código, pero también tiene una sucursal en algún lugar donde puede generar directamente sus compilaciones/exportar sus instantáneas. Ese servidor probablemente tendrá más de una rama, una de las cuales se considera una rama 'troncal'. Todas las versiones anteriores tendrán su propia sucursal y, dependiendo de la jerarquía de su equipo (es decir, si está dividido en grupos con cada grupo trabajando en un aspecto de la aplicación), puede haber sucursales basadas en equipos o funciones, aunque si No trabaje de esa manera que no sea necesario.
Por supuesto, debido a que se distribuye, cada desarrollador también tendrá su propio repositorio local, para hacer que las cosas sean agradables y rápidas. O pueden tener varios repositorios, incluso. Por ejemplo, un desarrollador que le gusta trabajar durante el trayecto puede tener un repositorio en su estación de trabajo y otro en su computadora portátil, con ramas en su computadora portátil que están "desprotegidas" de las que están en su estación de trabajo. Depende de él. Supongo que la parte 'distribuida' hace que este tipo de cosas sea mucho más fácil, porque puedes comprometer e incluso ramificar mientras estás fuera de la red.
Si está realizando la transición de un VCS no distribuido, puede simplemente deslizarse directamente al mismo modelo que antes, porque un DVCS es lo suficientemente flexible como para funcionar de la misma manera. De lo contrario, puede comenzar con un único repositorio central con algunas ramas, y siempre es muy fácil crear más repositorios y ramas más adelante.
Una última cosa es que todavía necesita copias de seguridad. El hecho de que varios desarrolladores tengan copias de la misma cosa agrega redundancia, pero no es en lugar de copias de seguridad.
El DVCS que uso regularmente es Bazar. También probé Mercurial.
Esa no es exactamente una característica que los diferencie del otro tipo de VCS que se denominan VCS cetralizados.
Por lo tanto, si la empresa tiene experiencia con svn, por ejemplo. Con un servidor dedicado para el repositorio y el modelo de respaldo, puede aplicar prácticamente lo mismo para el DVCS.
Sí, pero tiene muchas opciones. El mejor diagrama que he visto que explica algunos de ellos está en http://whygitisbetterthanx.com/#any-workflow.
Sí, creo que para una empresa, o al menos un producto de la empresa, es mejor o al menos más fácil tener un modelo de configuración centralizada. Usted es tratando de hacer un único producto coherente, después de todo.
Sin embargo, DVCS infunde un espíritu de trabajo diferente y el modo que puede o no puede fomentar en su equipo. En particular, aumenta la experimentación (solo use una copia local y no molestará a nadie). Es más fácil para el mantenimiento de las versiones anteriores, o si realiza muchos cambios específicos del cliente que deben controlarse sin ponerlos en el producto real.
Es invaluable cuando tienes un equipo que trabaja mucho fuera del sitio. En mi empresa, los ingenieros a menudo hacen cambios de última hora en el sitio, donde por razones de seguridad no tienen acceso a Internet. Central VCS simplemente no funcionan para este escenario.
Así que hay un repositorio central, pero el hecho de que usted puede trabajar de forma descentralizada es invaluable. DVCS es un superconjunto de VCS centralizado en términos de flujos de trabajo. Por supuesto, aún puede optar por utilizar un VCS centralizado si no cree que necesitará (o ¡desea!) Las opciones adicionales.