Как делает Подвижную работу со многими разработчиками?

Я не знаю, как команда TortoiseHg делает что-то, но вы можете использовать расширение Mercurial rebase , чтобы «отсоединить» ветку и поместить ее на верхушку кончика, создав единственную ветвь.

На практике, однако, я не беспокоюсь о нескольких ветвях, пока я не вижу больше голов, чем должно быть. Слияние на самом деле не имеет большого значения.

Да, нам придется объединиться, и чтобы избежать головных файлов в главном репозитории, объединение должно быть сделано в дочерних репозиториях самим разработчиком.

Таким образом, перед тем, как отправить свой код в родительский репозиторий, вы сначала вытаскиваете последние изменения, сливаете их на своей стороне и (пытаетесь) отправить. Это позволит избежать нежелательных голов в мастер-репозитории

Ядро Linux хранится в тысячах репозиториев и, вероятно, в миллионах ветвей, и это не кажется проблемой. Для больших проектов нужна стратегия работы с репозиториями (например, стратегия "диктатор-лейтенанты"), но наличие множества ветвей - главная сила современных DVCS, и это вовсе не проблема.

Я разработчик Mercurial, поэтому позвольте мне объяснить, как мы / я это делаем.

В проекте Mercurial мы принимаем взносы в виде исправлений, отправляемых в список рассылки. Когда мы применяем те, которые имеют hg import , мы выполняем неявную перебазировку в верхушку ветки, над которой мы работаем. Это очень помогает в сохранении чистоты истории.

Что касается моих собственных изменений, я использую rebase или mq , чтобы линеаризовать вещи, прежде чем я их нажимаю, опять же, чтобы сохранить аккуратность истории. По сути, это вопрос выполнения

hg push  # abort: creates new remote head
hg pull
hg rebase
hg push

Вы можете комбинировать извлечение и перебазирование, если хотите ( hg pull --rebase ), но мне всегда нравилось делать шаг за шагом.

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

Или ... Чего я здесь не вижу? Может быть, это не совсем проблема?

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

На практике это означает, что более 80% слияний может быть выполнено автоматически самим Mercurial.

Возьмем пример:

у вас есть:

[branch 1]  [branch2]
        \    /
         \  /
        [base]

Правка : для ясности, по ветке я имею в виду безымянные ветки.

Если у вас есть файл, измененный в ветке 1 , но тот же файл в ветке 2 такой же, как в base , то версия в ] ветвь 1 выбрана. Если файл изменен как в ветке 1 , так и в ветке 2 , файлы объединяются построчно с использованием одного и того же алгоритма: если строка 1 в файле1 в ветке 1 отличается от строки 1 в файле1 в base , но в ветке 2 и base строка 1 равна, строка 1 в ветке 1 равна выбрал (и тд и тп).

Для строк, которые изменяются в обеих ветвях, Mercurial прерывает автоматический процесс объединения и предлагает пользователю выбрать, какие строки использовать, или отредактировать строки вручную.

Поскольку решение, какие строки использовать лучше всего, принимает лицо (лица), изменившее эти строки, рекомендуется, чтобы лицо, реализовавшее функцию, выполнило объединение. Это означает, что если я и вы работаете над одним и тем же проектом, я реализую свою функцию, затем извлекаю из центрального / общего репозитория (получаю последнюю версию, которую все используют), затем объединяю свою новую версию с извлеченными изменениями, а затем публикую его в общий репозиторий (на данный момент общий репозиторий имеет одну главную ветку с моими объединенными изменениями в нее). Затем вы берете это с сервера и делаете то же самое со своими изменениями.

Это означает, что каждый может делать что угодно в своем локальном репозитории, а общий / официальный репозиторий имеет одну ветку.Это также означает, что вам необходимо определить временные рамки, когда люди должны объединить свои изменения.

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

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