Плюсы и минусы распределенных систем контроля версий?

Ответ 1

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

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

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

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

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

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

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

Ответ 2

Прочитайте этот question в stackoverflow для получения большой информации о GIT vs SVN и центральных и распределенных системах в целом.

Ответ 3

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

Ответ 4

Да, проверьте этот вопрос для stackoverflow. Если вам нужна дополнительная информация о том, как Git сравнивается с другими системами управления версиями, для этого есть приятный информационный сайт: Почему Git лучше, чем X?