Creo que en la práctica los desarrolladores preferirán usar un repositorio central que empujar y tirar entre los repositorios locales de los demás. Una vez que hayas clonado un repositorio central, mientras trabajas en las ramas de seguimiento, ir y buscar son órdenes triviales.Agregar media docena de controles remotos a todos los repositorios locales de sus colegas es una molestia y estos repositorios pueden no ser siempre accesibles (apagados, en una computadora portátil llevada a casa, etc.).
En algún momento, si todos están trabajando en el mismo proyecto, todo el trabajo debe integrarse. Esto significa que necesita una rama de integración donde todos los cambios se combinen. Esto naturalmente debe ser accesible desde cualquier lugar por todos los desarrolladores, no pertenece, por ejemplo, en la computadora portátil del desarrollador principal.
Una vez que haya configurado un repositorio central, puede usar un flujo de trabajo de estilo cvs/svn para registrarse y actualizar. La actualización de cvs se convierte en git fetch y rebase si tienes cambios locales o simplemente git pull si no lo haces. cvs commit se convierte en git commit y git push.
Con esta configuración, se encuentra en una posición similar con su sistema VCS completamente centralizado. Una vez que los desarrolladores envían sus cambios (git push), que deben hacer para ser visibles para el resto del equipo, están en el servidor central y se les hará una copia de seguridad.
Lo que requiere disciplina en ambos casos es evitar que los desarrolladores mantengan cambios de larga ejecución fuera del repositorio central. La mayoría de nosotros probablemente haya trabajado en una situación en la que un desarrollador está trabajando en la función 'x', que necesita un cambio fundamental en algún código central. El cambio hará que todos los demás necesiten reconstruir por completo, pero la función aún no está lista para la transmisión principal, por lo que solo la vigilará hasta un momento adecuado.
La situación es muy similar en ambas situaciones, aunque existen algunas diferencias prácticas. Al usar git, debido a que puede realizar confirmaciones locales y puede administrar el historial local, es posible que el desarrollador individual no sienta tanto la necesidad de ingresar al repositorio central como algo parecido a cvs.
Por otro lado, el uso de confirmaciones locales se puede utilizar como una ventaja. Impulsar todos los compromisos locales a un lugar seguro en el repositorio central no debería ser muy difícil. Las sucursales locales se pueden almacenar en un espacio de nombre de etiqueta específico del desarrollador.
Por ejemplo, para Joe Bloggs, se podría hacer un alias en su repositorio local para realizar algo como lo siguiente en respuesta a (por ejemplo) git mybackup.
git push origin +refs/heads/*:refs/jbloggs/*
Se trata de un mando único que se puede utilizar en cualquier momento (por ejemplo, al final del día) para asegurarse de que todos sus cambios locales están respaldados con seguridad hacia arriba.
Esto ayuda con todo tipo de desastres. La máquina de Joe explota y puede usar otra máquina, y guarda los commits guardados y continúa desde donde lo dejó. Joe está enfermo? Fred puede ir a buscar las ramas de Joe para agarrar ese arreglo de 'debe tener' que hizo ayer, pero no tuvo la oportunidad de probar contra el maestro.
Para volver a la pregunta original. ¿Es necesario que haya una diferencia entre dVCS y VCS centralizado? Usted dice que las funciones a medio implementar y las correcciones de errores no terminarán en el repositorio central en el caso de dVCS, pero yo afirmaría que no debe haber ninguna diferencia.
He visto muchos casos en los que una característica a medio implementar se mantiene en una caja de trabajo de desarrolladores cuando se usa VCS centralizado. O bien adopta una política que permite que la mitad de las características escritas se registren en la secuencia principal o se debe tomar una decisión para crear una rama central.
En el dVCS, puede ocurrir lo mismo, pero se debe tomar la misma decisión. Si hay un trabajo importante pero incompleto, debe guardarse centralmente. La ventaja de git es que crear esta rama central es casi trivial.