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

Question

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

В более общем случае мне было бы интересно услышать от людей, которые используют DVCS на работе, в средних и больших командах.

1. Как вы справляетесь с N-way слияниями? Это общий сценарий? Mercurial поддерживает только N-way merging, выполняя (N-1) 2-way merges (и read , что это предпочтительное решение в других DVCS), что звучит как очень трудоемкий процесс даже для относительно небольших N .
2. Используете ли вы один центральный авторитетный репозиторий или это действительно P2P?
3. Часто ли разработчики проталкивают и извлекают код друг из друга или все идет через центральный репозиторий?

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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