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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

Схема рабочего потока из whygitisbetterthanx:

alt git рабочий поток с менеджером интеграции http://whygitisbetterthanx.com/images/workflow-b.png

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

Ответ 3

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

• Как вы справляетесь с слияниями N-way?

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

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

  Совершенно верно. Это единственный способ рассказать, что такое GHC, а что нет.

• Разве разработчики часто нажимают и вытаскивают код друг другу и друг от друга, или все идет через центральный репозиторий?

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

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

Ответ 4

Известный "Tech Talk: Linus Torvalds on git" объясняет, как он используется для Linux (примерно такой же большой, как команда, о чем я могу думать)

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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