Mercurial репозитории со многими активными разработчиками?
Я прохожу через Bitbucket, и я не могу найти какие-либо репозитории Mercurial, которые выглядят так, как я подозреваю, будет выглядеть наш репозиторий, если мы перейдем на Mercurial.
Поэтому мне интересно, есть ли рабочий процесс, который мы здесь не рассматриваем?
Я говорю о том, что я провел небольшой автоматический тест. Мы - 14 человек, которые работают над одним проектом, разделенным на 4 команды. Чтобы смоделировать 14 (я выбрал 10, округленное число) людей, работающих параллельно над кодом, используя Mercurial DVCS, отправляя его в один и тот же центральный главный репозиторий, я написал скрипт.
- Я создал новый "главный" репозиторий, а затем клонировал его для 10 виртуальных людей.
- Затем я запустил итерационный цикл 1000, выбрав случайный клон и выполнив одно из следующих действий:
- 10% времени делайте отрыв от мастера, объединяйте, фиксируйте объединение и нажимайте
- 90% времени делайте локальные изменения и фиксируйте
Обратите внимание, что я гарантировал, что никогда не будет конфликтов слияния, просто заставляя каждого виртуального человека работать со своим собственным файлом.
Это имитирует людей, работающих локально, делая коммиты 1+ перед вытягиванием, объединением и толканием (чтобы избежать 2+ голов в мастер-репо). Возможно, этот рабочий процесс неправильный.
Вот пример того, как теперь выглядит хранилище (скриншот + ссылка на репо):
Хранилище можно найти здесь: http://hg.vkarlsen.no/hgweb.cgi/parallel_test/graph.
Это выглядит ужасно грязно, и, как я уже сказал, я не могу найти ни одного хранилища с похожей историей. Под "грязным" я подразумеваю, что похоже, что более старая история проекта почти всегда будет иметь 10 параллельных ветвей. Близко к вершине, это, конечно, сужается, но будет расширяться, поскольку люди, которые в настоящее время работают в их локальном хранилище, подталкивают к мастеру.
Итак, у меня есть два вопроса:
- Может кто-нибудь показать мне хранилище с похожей историей? Так как я не могу найти ничего, я начинаю задумываться о том, какие выводы я могу сделать из этого...
- Что-то не так с нашим рабочим процессом (то есть рабочим процессом, который я изложил здесь)? Должны ли мы перебазировать / раздавить / пересадить, передать ответственность за толчок одному человеку, другим вещам, вместо того, как это было сделано здесь?
2 ответа
Впечатляющая подготовка!
Это всегда выглядит грязно, если вы немного вернетесь назад и посмотрите на все старые коммиты одновременно. Это всегда сужается, даже если смотреть на немного старую историю. См. Например, http://hg.intevation.org/mercurial/crew/graph/12402?revcount=120. Это не самый последний коммит, но показывает всю историю до этого коммита.
Rebase очень помогает, особенно если люди работают в разных областях. (Я обычно проверяю входящие коммиты, чтобы узнать, не были ли потенциальные конфликты файлов или функций, и если нет, я делаю ребаз.)
Rebase не защищен от ошибок, поэтому слияние является предпочтительным "безопасным" действием, но оно оставляет больше "мусора" в истории. Компромисс.
Rebase вроде как стандартное обновление SVN болота. Существующий материал сделан базовым, и ваши изменения идут впереди, скрестите пальцы, он все еще работает. Это полезно, но бывают моменты, когда вы чувствуете себя безопаснее, когда ваши, их и слияние являются отдельными коммитами в истории.
Существует также опция фиксации коммитов (возможно, расширение histedit), которая сводит все промежуточные коммиты к одному. Это полезно, когда вы собираетесь выдвинуть и хотите передать много частичных коммитов в своем собственном репо как единый коммит на основной.
У меня 12 разработчиков, работающих в одном и том же репозитории Mercurial, и наша история не выглядит так. Время от времени происходят коммиты слияния, но большинство слияний происходит от слияния фактических веток, т. Е. В нашей основной ветке разработки может быть слияние, вносящее изменения из выпуска исправлений, сделанных в ветке производства / выпуска.
Этого очень легко достичь, разработчики взламывают и фиксируют свой локальный репозиторий, и когда у них есть что-то достаточно стабильное, чтобы поделиться с остальной командой, которую они продвигают.
Если ничего не было совершено, так как они начали совершать толчок, то проходит без проблем.
Если кто-то еще совершил изменение, Mercurial жалуется, что толчок создаст удаленные головки. Затем разработчик делает hg pull --rebase
и повторяет толчок. Толчок проходит, и все счастливы.
Если вы используете непрерывную интеграцию с разработчиками, регулярно отправляющими файлы в общий репозиторий, то это путь. Знать, были ли вы внесены изменения или нет, очень просто, и вы избежите множества бесполезных слияний, которые загромождают вашу историю.