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

Question

Работа над немного липкой проблемой и надеялась на помощь со стороны сообщества. В основном, наша команда разработчиков разделена на две команды, позволяет сказать, что "Красный" и "Синий"

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

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

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

Чтобы упростить, скажем, разработчики A и B находятся в команде Red.

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

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

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

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

Answer 1

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

Например, вы могли бы иметь что-то вроде

/branches/dev 
/trunk 

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

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

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

Answer 2

• TeamA
• TeamB
• Мастер

Когда TeamA готов нажать изменения, объединить TeamA в мастера, а когда TeamB готов, слить TeamB в мастера.

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

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

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

Answer 3

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

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

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

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

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

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