Распределенный контроль источника - продвижение отдельных наборов изменений

Question

Работал над небольшой проблемой и надеялся на помощь сообщества. По сути, наша команда разработчиков разделена на две команды, скажем, «Red» и «Blue»

3 репо:
1: Мастер
2: Красный >> Клон мастера
3: Синий >> Клон мастера

Каждый разработчик клонирует красный или синий на своем локальном компьютере, на котором он работает.

Обе команды работают над различными задачами для нашего основного приложения. У каждой команды есть клон нашего общего «главного» репозитория, в котором они применяют свои наборы изменений. Наборы изменений проверяются на этом уровне, и в этот момент они готовы быть вставленными в Мастер.

Для упрощения предположим, что разработчик A и B работают в команде Red.

Таким образом, проблема возникает, когда разработчик A нажимает набор изменений 1, затем разработчик B нажимает набор изменений 2. Затем набор изменений 1 проверяется и готов к переходу в Master, а набор изменений 2 - нет.

Я хочу передать набор изменений 1 на Master как можно скорее, а не ждать проверки набора изменений 2, тем более что в это время может быть введен набор изменений 3.

В настоящее время мы используем Mercurial, и мне это нравится - я хотел бы перейти на Git, если рабочий процесс для того, что я хочу сделать, будет проще.

Думаю ли я об этом неправильно? Я ценю помощь.

Answer 1

В конкретном случае, который вы описываете:

Я хочу как можно быстрее переключить набор изменений 1 в мастер, а не ждать проверки для набора изменений 2, тем более что набор изменений 3 может быть

все, что вам нужно сделать, это hg push -r cset1, где cset1 - номер ревизии или хеш узла нужного вам набора.

Когда вы нажимаете -r, он выталкивает изменения и всех его предков , так что вы можете нажать набор изменений 1, не нажимая набор изменений2, но не изменять набор 2, не нажимая набор изменений 1 .

Если вам нужно вытолкнуть их из строя (два, но не один), то вам придется выбирать вишню с помощью TransplantExtension, но пока вы идете в порядок, у вас есть простой вариант.

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

Answer 2

• TeamA
• TeamB
• Мастер

Когда TeamA готов к отправке изменений, вы объединяете TeamA с мастером, а когда TeamB готов, вы объединяете TeamB с мастером.

Периодически в обоих направлениях TeamA & TeamB Следует выбрать / Слить с Master, чтобы убедиться, что их версии имеют самый последний код.

Если вам нужно больше примеров, посмотрите, как настроен Gitorious / Github. Каждый разработчик имеет свой собственный клон проекта, а затем, когда они готовы, они подают заявку на слияние с главным репо.

Этот же принцип может быть применен к Merc, ключ заключается в том, что вы часто выбираете / объединяете с Team Repos (Developer Repos), чтобы убедиться, что новый код вводится в их цикл разработки.

Answer 3

Я не знаком с ветвлением в Mercurial, но вот как вы бы это делали в SVN - я уверен, что есть эквивалент. Вам нужно настроить ветки и вместо этого объединить наборы изменений в / trunk. Это позволяет вам выбирать, какие ревизии выходят, а не просто делать «svn up» и получать их все.

Например, у вас может быть что-то вроде

/branches/dev
/trunk

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

svn merge <host>/branches/dev -r 99:100
svn merge <host>/branches/dev -r 109:110

И только изменения, сделанные в этих конкретных ревизиях, будут объединены в /trunk.