HgFlow и несколько разработчиков

Question

Мне очень нравится Hg Flow для Mercurial репозиториев. мы в настоящее время используем Bitbucket, и в каждом продукте работают несколько разработчиков. в основном они могут работать, как показано ниже:

• команда может работать над одной функцией.
• Другая команда может работать над выпуском/исправлением.

Так что я держу ветку «развить» в BitBucket или локальных репозиториях. и как насчет ветвей функций, я должен нажать их в центральный репозиторий и удалить, когда это необходимо. Я предполагаю, что мы должны сделать это правильно?

Благодаря

Answer 1

Я лично ни использование git flow или hg flow в качестве инструментов, но я использовать некоторые методы для моих собственных проектов (вручную).

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

Разница между использованием git и mercurial/hg актуальна здесь, так как модели ветвления совсем разные. Для получения более подробной информации см. A Guide to Branching in Mercurial. Использование hg-закладок будет очень похоже на то, что git делает с ветвями, но нет полной поддержки для модели разметки закладки на BitBucket (см. this ticket).

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

У вас нет другого выбора, кроме как держать все ветки в главном хранилище. Однако вы можете решить, когда нажать и когда их закрыть. Я бы посоветовал использовать hg push -r, чтобы нажимать только те ветки/головки, которые вы хотите нажимать, и только нажимать их, когда они либо нужны кем-то другим, либо закончены и объединены. Филиалы должны быть закрыты, как только они больше не понадобятся. (Это, вероятно, сделано автоматически hg flow) Вы должны закрывать филиалы локально, когда это возможно. Таким образом, они могут даже не появляться в интерфейсе bitbucket. Некоторые могут попасть в репозиторий bitbucket только в закрытом состоянии (которое скрывает их от интерфейса).

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

---

В случае, если вы либо не использовать hg-flow или названные ветви вещи немного по-другому. Оба, использующие forks/clones или закладки как метод ветвления, не генерируют постоянные или обязательно глобальные ветви.

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

При использовании вилок в качестве ветвей он немного похож на закладки, но битбакет полностью поддерживает это. Вам нужно иметь новую вилку на битбакете для каждой ветки. Вы, естественно, хотите создать дополнительные вилки, если вам нужны разные люди, чтобы работать над ним, и у вас нет других способов обмена обменами для них. Тогда вам понадобится хотя бы отдельный «разворачивающий» репозиторий.

---

Я лично не буду использовать полный «поток» с hg на битбакете. Для моих проектов ветка «develop» такая же, как и master/default, так как я не запускаю выпуски с git (кроме разработки, которые не будут использовать ветвь релиза в любом случае). Мне не нужна отдельная ветвь «производства», так как теги могут в основном использоваться для использования в производстве. Я также не создаю отдельную ветку «выпуск-подготовка». Есть только момент времени, когда я применяю только исправления для разработки и прекращения слияния функций. Это явно не сработает, когда вам нужно работать одновременно с функциями, которые зависят от функций, которые не будут выпущены в следующей версии.

Всегда использовать полный поток «git» легко, потому что разветвление git легкое и легкое. В зависимости от модели ветвления, которую вы используете и как поддерживаются другие инструменты, , используя полный «поток hg», возможно, не «стоит».

Руководство hg фактически препятствует использованию названных ветвей для короткоживущих ветвей. См. Feature separation through named branches. «Легкая» концепция ветвления, продвигаемая в руководстве, - это разветвление/клонирование. Закладки были бы естественным способом перевести git flow, если бы поддержка инструмента/битбактера была бы лучше (а закладки больше - функция hg).

---

Отказ от ответственности: Я предпочитаю мерзавец, когда я могу выбрать. Я использую hg, но не как мой личный выбор.

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

---

Edit:

Для последующих на комментарии:

Я думаю, Hg закладки сопоставимы с GIT ветвей, потому что оба просто подвижные указатели совершает. Главное отличие состоит в том, что при удалении ветки в git коммиты могут быть потеряны (если они не являются частью других ветвей или не указаны в другой ветке до того, как они будут собраны мусором). Когда вы удаляете закладку в hg, коммиты по-прежнему являются частью репозитория (часть ветви (именованного или по умолчанию)), если вручную не удалить.

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

Названные ветви довольно несвязаны, так как единственное, что у них есть с ветвями git, - это имя. Они легки в сравнении с клонированием всего хранилища (разветвляясь как модель ветвления), но не с точки зрения «вы не можете избавиться от них». Они постоянны. Большинство мест говорят, что вы не используете именованные ветви, если у вас нет веских оснований или это длинная ветка.