Почему бизнес должен использовать распределенный контроль версий?

Ответ 1

Аргумент кажется мне обратным.

Учитывая, что централизованная система контроля версий является лишь одним из многих случаев использования распределенной системы, как применяется такое ограничение для компании?

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

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

Два аргумента, которые я слышал, не отвечают мне хорошо:

• не может взять весь код и запустить.
• замок

Число 1 просто глупо. Может быть, это немного сложнее, чтобы получить полную историю (и если я не могу, там нет системы контроля версий), но когда дело доходит до такого страха, о котором мы говорим здесь, я могу просто взять последнюю ревизию и это так же опасно.

Число 2 действительно похоже на попытку использовать неправильный инструмент для работы. Я использовал анти-CVS-аргументы от пользователей RCS, потому что они действительно думали, что вы должны каждый раз блокировать каждый файл, чтобы не допустить двух человек, я не знаю, работает.

Коммуникация вне диапазона. Думаю, если у вас есть большие, неурожайные файлы, о них хорошо говорить. IMO, многие из людей с этой проблемой не хотят иметь систему контроля версий, но файловую систему моментальных снимков (zfs, 9fs, Drop Box и т.д.).

В общем, я не понимаю, почему люди даже спрашивают: "Почему я должен давать свои инструменты для разработчиков, которые дешевле, быстрее, надежнее, более надежны и делают их более продуктивными?" виды вопросов.

Ответ 2

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

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

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

Можно также видеть, что DVCS управляется таким образом, что естественный процесс "очистки" (только то, что "действительно" - по крайней мере, проверено, например, устройство, - публикуется в центральном репо), с более чистой историей (все промежуточные коммиты могут оставаться в ветках темы локальных репозиториев).

Ответ 3

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

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

Ответ 4

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

Я нахожу, что git является превосходным клиентом для svn, чем, например, svn. Поэтому, если компания настаивает на использовании системы центрального репозитория, вы все равно можете получить личную выгоду от git, сохраняя при этом центральный репозиторий.

Ответ 5

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

Ответ 6

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

Ответ 7

Проверьте преимущества здесь...

http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git

http://www.ehow.com/info_12217814_git-commit-vs-push.html