Как настроить распределенный контроль версий в компании

Question

Из моего опыта работы с распределенными системами контроля версий (DVCS), такими как git и mercurial, в проектах с открытым исходным кодом, большинство моделей установки используют централизованную настройку для своего проекта (например, GitHub).

При внедрении распределенной VCS в компании, у вас есть модель централизованной установки ?

Answer 1

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

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

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

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

DVCS, которую я регулярно использую, это Bazaar. Я также попробовал Mercurial.

Answer 2

Да, но у вас есть много вариантов. Лучшая диаграмма, которую я видел, объясняющая некоторые из них, на http://whygitisbetterthanx.com/#any-workflow.

Answer 3

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

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

Это неоценимо, когда у вас есть команда, которая много работает вне офиса. В моей компании инженеры часто вносят изменения в последнюю минуту на месте, где по соображениям безопасности у них нет доступа в интернет. Центральные VCS просто не работают для этого сценария.

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

Answer 4

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

Так что, если у компании есть опыт работы с svn, например. С выделенным сервером для хранилища и модели резервного копирования вы можете применить почти то же самое к DVCS.