Некоторые из многих причин:

• Инерция: огромное количество людей знакомо с централизованными системами. Вам не нужно «переучивать» разработчиков, если вы просто не меняетесь.

• Взаимодействие с другими инструментами: Корпоративная среда, конечно же, изобилует дополнительными инструментами, такими как непрерывная интеграция, IDE, причудливые средства отслеживания проблем и так далее. Естественно, с ними больше поддержки установленных централизованных VCS, чем с относительно новыми git и hg.

• Поддержка. Покупая коммерческий продукт VCS, вы покупаете не просто программу, а душевное спокойствие.

Конечно, я не говорю, что это веские причины; они просто убеждают людей, которые могут принять такое решение. Думаю, стоит побороть инерцию - сейчас надо работать, но потом окупается. Я думаю, что внешние инструменты улучшают поддержку git, особенно инструменты с открытым исходным кодом - им просто нужны плагины. А что касается поддержки, мы все знаем, что в Интернете существует множество менее формальной поддержки.

На самом деле, во всем этом есть общая мысль - философия свободного программного обеспечения - это просто не то, как корпорации ведут бизнес. Купить товар налажено и легко. Вы платите деньги, вы получаете то, что вам нужно. Руководству не о чем беспокоиться. Использование бесплатного программного продукта ...ну, может быть, это намного лучше, но с этим сложнее справиться. Он не входит в коробку.

Уточнение: я использую слово «бесплатно» так же, как в мире свободного программного обеспечения - «бесплатно» как в свободе, а не как в пиве. Надеюсь, эта фраза в конце концов вбивается всем в головы. Обратите внимание, что я никогда не касался вопроса стоимости здесь - хотя я действительно думаю, что в случае git, в целом, это будет в конечном итоге дешевле, чем купленное решение, несмотря на затраты на то, чтобы все ознакомили с ним и убедились, что это вписывается в остальную часть вашего процесса. Однако это не банальная проблема, и, поскольку я думаю, что git выйдет вперед, нет смысла ставить его среди пуль.

Git - это система управления версиями, ориентированная на сотрудничество и совместное использование. Практически нет способа принудительно установить конкретный шаблон доступа и совместного использования. Если люди, использующие git, не хотят следовать вашим правилам, этот инструмент вам не сильно поможет.

Хотя я лично считаю такое организационное поведение глупым, я уверен, что где-то кто-то думает, что это хорошая идея. Возможно, вы обеспокоены тем, что ваши непослушные сотрудники работают над неправильными проектами, или вы отчаянно пытаетесь сохранить изменения в коде.

Если бы мне пришлось угадывать, я бы сказал, что это потому, что предприятия всегда с осторожностью относились к использованию «бесплатных» вещей. В основном потому, что им не хватает стабильной системы поддержки (обычно поддержка предоставляется в форме StackOverflow.com или форумов, когда дело доходит до открытого исходного кода), но также широко распространен менталитет «вы получаете то, за что платите». Они считают, что если это не будет стоить им огромных затрат на лицензионные сборы, то с точки зрения реального удобства использования это должно стоить столько же.

Конечно, мы, как технические эксперты, знаем, что это большая нагрузка.

Существенным практическим препятствием для внедрения на предприятиях, помимо отсутствия централизованного контроля и интеграции, о чем упоминал Эрик, является "простота использования".

Если вы привыкли к Subversion или подобным инструментам, таким как PVCS, то Git (и DVCS в целом) представляет собой значительный учебный холм, на который нужно подняться - как на концептуальном уровне, так и в ежедневном рабочем процессе. По моему (несколько уязвленному) опыту, многие корпоративные разработчики часто не желают тратить усилия на изучение нового инструмента или концепций; и я боюсь, что это приведет к срыву любой попытки внедрения DVCS.

Пожалуйста, докажите, что я не прав

По моему опыту, это страх перемен. Управление исходным кодом является центральной частью инфраструктуры и затрагивает всех разработчиков. Если текущая система не нанесет слишком много вреда, ИТ-отдел предприятия фактически будет бороться с изменениями.

Еще одна причина, которую я довольно часто слышал, заключается в том, что интеграция IDE еще не достигла качества, например, CVS или Subversion. Хотя аргумент верен, он становится все более серьезной проблемой.

«Помимо того факта, что выбор уже сделан»

Эта часть утверждения на самом деле слишком важна, чтобы ее игнорировать, потому что она связана с кривой обучения любому конкретному инструменту. Например, изучение SVN требует времени, а процесс обучения стоит денег в виде времени разработчика. Изучение git, по моему опыту, требует больше времени и усложняется из-за отсутствия упрощенных интерфейсов (несмотря на продолжающуюся разработку gittortoise). Плюс к этому у Git так много инструментов, что его кривую обучения можно рассматривать скорее как способ обучения.

Выплата после преодоления кривой велика, но первоначальное требование является препятствием для принятия.

Тот же вопрос можно задать о замене любой крупной инфраструктурной службы на что-то другое. Когда что-то используют сотни или тысячи людей, лучше это сломать, или новая вещь лучше предложит какие-нибудь привлекательные функции.

Подумайте о смене почтовой системы. Кто-то должен будет обучить всех пользователей, передать все сообщения, произвести переключение с минимальным временем простоя и без потери данных, а затем убедить руководство, что это не приведет к серьезным сбоям в бизнес-операциях.

В вашем конкретном примере преобразование системы управления версиями для 100 подсистем с сохранением истории и переподготовкой всех разработчиков, тестировщиков и инженеров по выпуску, не влияя на их повседневную производительность, является огромной задачей. Существующая система должна быть действительно сломана.