Я думаю, вы обнаружите, что на практике разработчики предпочтут использовать центральный репозиторий, а не перемещаться между локальными репозиториями друг друга. После того, как вы клонировали центральный репозиторий, работая над любыми ветвями отслеживания, выборка и отправка становятся тривиальными командами. Добавление полдюжины пультов дистанционного управления во все локальные репозитории ваших коллег - это боль, и эти репозитории могут быть не всегда доступны (выключены, на ноутбуке забраны домой и т. Д.).
В какой-то момент, если вы все работаете над одним и тем же проектом, все работы должны быть интегрированы. Это означает, что вам нужна ветка интеграции, где все изменения объединяются. Это, естественно, должно быть где-то доступно всем разработчикам, это не относится, например, к ноутбуку ведущего разработчика.
После настройки центрального хранилища вы можете использовать рабочий процесс в стиле cvs / svn для регистрации и обновления. cvs update становится git fetch и rebase, если у вас есть локальные изменения, или просто git pull, если у вас нет. cvs commit становится git commit и git push.
С этой настройкой вы находитесь в аналогичном положении с вашей полностью централизованной системой VCS. После того, как разработчики отправят свои изменения (git push), которые они должны сделать, чтобы они были видны остальной части команды, они находятся на центральном сервере и будут сохранены.
То, что требует дисциплины в обоих случаях, не позволяет разработчикам не допускать долгосрочных изменений из центрального хранилища. Большинство из нас, вероятно, работали в ситуации, когда один разработчик работает над функцией 'x', которая требует фундаментальных изменений в некотором основном коде. Это изменение заставит всех остальных полностью перестроиться, но функция еще не готова к основному потоку, поэтому он просто проверяет ее до подходящего момента времени.
Ситуация очень похожа в обеих ситуациях, хотя есть некоторые практические различия. Используя git, поскольку вы выполняете локальные коммиты и можете управлять локальной историей, необходимость отправки в центральный репозиторий может ощущаться не столько отдельным разработчиком, сколько с чем-то вроде cvs.
С другой стороны, использование локальных коммитов может использоваться как преимущество. Перенос всех локальных коммитов в безопасное место в центральном хранилище не должен быть очень трудным. Локальные ветви могут храниться в пространстве имен тегов разработчика.
Например, для Джо Блоггса в его локальном хранилище можно создать псевдоним для выполнения чего-то вроде следующего в ответ (например,) git mybackup.
git push origin +refs/heads/*:refs/jbloggs/*
Это одна команда, которую можно использовать в любой момент (например, в конце дня), чтобы обеспечить безопасное резервное копирование всех его локальных изменений.
Это помогает при всевозможных бедствиях. Машина Джо взрывается, и он может использовать другую машину и получать сохраненные коммиты и продолжать с того места, где он остановился. Джо болен? Фред может получить ветки Джо, чтобы получить исправление «должно быть», которое он сделал вчера, но у него не было возможности протестировать против мастера.
Вернемся к исходному вопросу. Должна ли быть разница между dVCS и централизованным VCS? Вы говорите, что наполовину реализованные функции и исправления не окажутся в центральном репозитории в случае dVCS, но я бы сказал, что не должно быть никакой разницы.
Я видел много случаев, когда наполовину реализованная функция остается на одном рабочем месте разработчиков при использовании централизованного VCS. Либо требуется политика, позволяющая возвращать половину написанных функций в основной поток, либо необходимо принять решение о создании центральной ветви.
В dVCS может произойти то же самое, но должно быть принято то же самое решение. Если есть важная, но незавершенная работа, ее необходимо сохранить централизованно. Преимущество git состоит в том, что создание этой центральной ветви почти тривиально.