Как DVCS используется в больших командах?

Моя команда у моего предыдущего работодателя использовала Git, и он нам хорошо помог. Мы не были такими уж большими (может быть, 16 или около того, может быть, 8 действительно активных коммиттеров?), Но у меня есть ответы на ваши вопросы:

1. Слияние N-Way не очень распространено. Мы придумали некоторые соглашения об именах веток, которые позволили нам писать сценарии, которые упростили процесс «разработки релиза» (я использую запугивающие цитаты, потому что у нас не было инженера по выпуску), и люди создавали частные ветки функций, но мы редко возникла проблема с объединением более двух веток (см. следующую).
2. (и №3). У нас был центральный репозиторий на сервере разработки по трем причинам: (а) машина для разработки имела RAID5 (более отказоустойчивый) и ночное резервное копирование (рабочие станции разработчиков не работали по ночам), (б) производственные выпуски создавались на сервере разработки, и (c) наличие центрального хранилища упрощенных сценариев. В результате N-образных слияний просто не произошло. Самое близкое, что у нас было к N-way, - это когда кто-то сливается по горизонтали, а затем сливается по вертикали.

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

Обновление: наши соглашения в основном были такими:

• каталог на нашем сервере NFS, в котором размещались все центральные репозитории
• у нас было несколько проектов с общими компонентами, поэтому мы разбили их на библиотеки, по сути, с их собственными репозиториями, а поставляемые проекты просто включали их как подмодули git.
• сверху были навязаны строки версий и названия выпусков, поэтому мы просто использовали их варианты в качестве названий веток.
• аналогично, для тегов они следовали названиям релизов, продиктованным процессом.
• поставляемые проекты содержали файл свойств, который я читал в сценариях оболочки, и это позволило мне написать один сценарий для управления процессом выпуска для всех проектов, даже если у каждого из них были небольшие вариации процесса - вариации были учтены в этих файлах свойств
• Я написал скрипты, которые пересобирали бы доставляемый пакет из любого тега
• использование git позволило нам контролировать доступ с помощью PAM и / или обычных пользовательских разрешений (ssh и т. д.)
• Были и другие соглашения, которые сложнее поместить в маркированный список, например, когда должно происходить слияние. На самом деле, я и еще один парень были в некотором роде внутренними «гуру», и мы помогли всем разобраться, как использовать ветки и когда их объединять.
• Было непросто заставить людей делать коммиты небольшими кусками и не сбрасывать разностные бомбы в главную ветку. Один парень вложил около двух недель работы в одну фиксацию, и в конце концов нам пришлось все это распутать. огромная трата времени и разочарование для всех.
• информативные и подробные комментарии к коммитам

Были и другие вещи, которым вы научились по мере того, как ваша команда набирается опыта и учится работать друг с другом, но этого было достаточно, чтобы мы начали.

Обновление: любой, кто следит за такими вещами, уже знает об этом, но Винсент Дрейссен написал солидный и довольно исчерпывающий (но не исчерпывающий) взять на себя разработку ветвления и выпуска с использованием Git. Я настоятельно рекомендую использовать его метод в качестве отправной точки по двум причинам:

• многие команды делают это таким образом или используют какой-либо близкий вариант (включая Linux, Git и многие другие проектные группы OSS), что означает, что этот метод был протестирован и настроен для успеха в большинстве случаев. Маловероятно, что вы столкнетесь с проблемой, с которой не сталкивались и не решались в рамках ограничений этой модели.
• Из-за вышесказанного практически любой инженер с опытом работы с Git поймет, что происходит. Вам не нужно будет писать подробную документацию о фундаментальной природе вашего процесса выпуска; вам нужно будет только задокументировать вещи, относящиеся только к вашему проекту или команде.

Схема рабочего процесса из whygitisbetterthanx:

_{(источник: whygitisbetterthanx.com)}

Чтобы охватить еще больше разработчиков, вы просто добавляете еще один уровень «доверенных помощников» между менеджером интеграции и разработчиками.

Я несколько лет работал с командой Glasgow Haskell Compiler, используя Darcs. Недавно (несколько месяцев) я начал использовать git для своей собственной копии репо, как для повышения производительности, так и для улучшения моего образования.

1. Как вы справляетесь с N-образным слиянием?

   Нет N-сторонних слияний. Каждый разработчик создает поток исправлений, и потоки объединяются по одному в каждом репо. Таким образом, если N разработчиков вносят изменения одновременно, они объединяются попарно.

2. Используете ли вы единый центральный авторитетный репозиторий?

   Абсолютно. Это единственный способ узнать, что такое GHC, а что нет.

3. Часто ли разработчики отправляют и извлекают код друг от друга или все идет через центральный репозиторий?

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

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

Достаточно известный «Tech Talk: Линус Торвальдс на git» объясняет, как он используется для Linux (примерно такая большая команда, как я могу себе представить)

Если я правильно помню, его использование сравнивалось с военной цепочкой командования - у каждого модуля есть сопровождающий, который обрабатывает запросы на извлечение от разработчиков, затем есть несколько «самых доверенных» людей, которые занимаются извлечением данных от разработчиков модуля в официальный репозиторий kernel.org git.

"Linux: Управление исходным кодом ядра с помощью 'git'" также объясняет это, хотя опять же, это вряд ли кратко. объяснение..

Вот один пример (отнюдь не «универсальный»)

У нас есть центральная система контроля версий (ClearCase или SubVersion, в зависимости от различных проектов), и мы используем их для «официальных» разработок (разработка, патчи, исправления), где количество веток ограничено и четко обозначено.

Однако для рефакторинга разработок, включающих множество промежуточных состояний, где ничего не работает и где многим разработчикам требуется собственная ветвь на основе действий или ветки, некоторые репозитории Git создаются между этими разработчиками в метод P2P.
Как только работа достигает некоторой стабильности 0.1 и количество слияний сокращается, она повторно импортируется в VCS, где работа может продолжаться "упорядоченно" из центра.

Поскольку Git в Windows работает хорошо (MSysGit), мы управляем чтобы таким образом можно было быстро выполнить небольшие начальные разработки на стороне.

Тем не менее, мы все еще оцениваем Git для полномасштабной разработки проекта.

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