За и против распределенных систем управления версиями?

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

Мы используем Mercurial, но конкретный инструмент менее важен, чем общий рабочий процесс с использованием распределенного контроля версий в отличие от централизованного. По моему опыту, есть два больших преимущества производительности, без которых я больше не хочу работать:

1. Первое и самое главное: ветвление и слияние - это просто. Это побочный эффект распространения, а не строго требование, но он это критично для DVCS, и я считаю это критичным для моей работы. Каждый из нас может свободно разветвлять каждую функцию, над которой нам нужно работать, заставить ее работать в песочнице (без вмешательства со стороны нашего общего репозитория) и, когда мы будем готовы, объединить ее обратно. «Идти в ногу» с изменениями других - это так же просто, как и время от времени слияние, с возможностью отказаться от слияния и продолжить, если разрешение конфликтов требует слишком больших усилий в данный момент. Мы можем захватить определенные изменения и бросить их вместе в тестовой ветке и сохранить результаты, если они нам нравятся, или выбросить их, если нет. Эта способность пробовать разные вещи, делиться ими и сохранять только лучшие результаты является серьезным преимуществом. Как я уже сказал, это не тот, без которого я могу комфортно работать на данный момент.
2. Работа в автономном режиме. Это не похоже на большое дело, пока вы не перестанете работать в своей обычной среде. Я могу уехать в отпуск, или путешествовать, или у меня отключение питания, или просто хочу вынести свой ноутбук на улицу в хороший день и продолжать работать. Психологическая выгода от возможности встать и уйти без необходимости прекращать работу или потерять способность контролировать свою работу, моя работа очень реальна.

Помимо тех эффектов, которые применимы ко всем моим проектам, связанным с работой, а не к одному выгода, характерная для нашей конкретной договоренности, которая связана с вашим вопросом о коммерческом использовании и возникла неожиданно: клиент действительно может работать с кодом. Они могут сделать снимок, внести локальные изменения и либо отправить нам исправления, либо сохранить измененный код для определенной цели. Это очень помогает поддерживать их вовлеченность, помогает не слишком сильно расходиться с тем, что они хотят, и позволяя им настраивать вещи, ничего не нарушая (мы не объединяем их изменения, если они не готовы - те же правила, которые мы применяем для себя.)

У нас не так много жалоб. К этому нужно привыкнуть, хотя набор команд Mercurial достаточно близок к Subversion (который мы использовали), поэтому у нас не было особых проблем. Даже случайные неприятности, такие как случайная проверка двоичных файлов или файлов, которые не должны быть проверены, мы можем обойти, потому что мы можем воссоздать репозиторий без этих изменений и заменить наш основной, если нам нужно. Это плохо масштабируется для большой группы людей, но хорошо работает для небольшой команды из 3-4 человек.

Единственный недостаток, о котором я могу думать, это на самом деле проблема, - это побочный эффект возможности ветвления с легкостью: у вас может быть достаточно незавершенной работы, и вы потеряете ее из виду. Это немного похоже на создание множества черновиков письменного документа: раздайте достаточно копий, и вы не помните, в какой из них были внесены нужные вам изменения. Это не является прямым недостатком инструмента, и, во всяком случае, это облегчает объединение разрозненных работ, чем инструменты, менее способные к объединению. Но это опасность. Единственный известный мне способ справиться с этим - это дисциплинировать в написании полезных журналов фиксации, полезных описаний веток и не пытаться держать слишком много открытых задач одновременно. Другими словами, даже очень хороший рабочий процесс остается рабочим процессом и требует внимания, иначе он выйдет из-под контроля.

У меня есть особые проблемы с Mercurial (я действительно хочу, чтобы поддержка именованных веток была немного немного проще) и с Git (я действительно хочу, чтобы набор команд был более интуитивно понятным даже сейчас), но это жалобы на угловые проблемы, которые приходят с большой известностью. Они были бы даже невозможны, если бы эти инструменты не раздвинули границы того, что, как я думал, может делать VCS, далеко за пределы того, что я знал до того, как начал их использовать.