Какой рабочий процесс Git использовать для разработки и настройки продукта - PullRequest
0 голосов
/ 20 сентября 2018

Некоторое время мы использовали git-flow для разработки программной среды.У нас есть ветки master и development в одном репозитории.

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

До сих пор мы разветвляли новую ветку feature-customerXYZ для каждого клиента от мастера.сделал там настройку и оставил ветку открытой после завершения настройки (что предотвращает «заражение» ветки продукта master / development от настройки).

Параллельно с этим разработка самой платформы продолжается с использованием обычного рабочего процесса git-flow на ветвях master, development, features, hotfixes и release.

В этом контексте происходит два общих сценария, для которых, я думаю, наш рабочий процесс не может оптимально обрабатывать:

  1. Разработка ветки feature-customerXYZ может содержать коммиты, достойные реализациив продукте master / development филиал.Поскольку ветвь feature-customerXYZ никогда не будет закрыта, эти коммиты должны быть rebased или cherrypicked для веток продукта, что требует дополнительной работы после настройки и подвержено ошибкам.

  2. Исправления, обнаруженные при открытой ветке feature-customer, обрабатываются git-flow путем объединения открытых ветвей hotfix после исправления только с веткой master и development продукта, но не объединяются в открытую feature-customer ветви (точнее: они не объединены во все открытые feature ветви).

Существует ли рабочий процесс git, который может обработать это кратко?Есть ли более умная альтернатива вместо merge, cherrypick или rebase коммитов в продукт master / develop или открытых feature ветвей соответственно?

Ответы [ 2 ]

0 голосов
/ 01 октября 2018

Хотя теоретически возможно поддерживать отклонения клиентов в специализированных филиалах, как предлагает @VonC, я осмелюсь сказать, что это технически очень сложно и не масштабируется.

Да, у вас могут быть рабочие места (в Jenkinsили что-то в этом роде), которое автоматически отклонит ваши отклонения от основной ветви, но когда дело доходит до инструментов, вы сами по себе.Как минимум, будьте готовы к таким ситуациям, как:

  • rebase будет терпеть неудачу с конфликтами - легко, git сообщит вам
  • rebase удастся, но результат будет содержать логические конфликты - это требует хорошего тестового покрытия, потому что ни один инструмент не сможет предупредить вас

Вместо этого я рекомендую минимизировать отклонения и после этого держите их все в одной ветке рядом друг с другом.

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

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

Преимущества очевидны:

  • это просто
  • ваш CI являетсяпростота настройки для одновременной сборки всех модулей (= отклонения от клиентов)
  • вы можете запускать на них тесты и легко выбирать, какой тест предназначен для одного клиента, какой является общим, а какой является специфическим для отклоняющейся функции.Кроме клиента
  • , вам не нужно блокировать свою модель ветвления из-за этого, и вы все равно можете использовать git-flow или что-то еще, что соответствует вашим потребностям

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

Чтобы свести к минимуму отклонения, я рекомендую следующие методы:

  • некоторые отклонения могут быть лучше представлены параметрами конфигурации
  • другие могут быть скорее специфичными для функций, чем специфичными для клиента
  • и самое лучшее, некоторые отклонения могут быть отклонены - хотя это редко возможно

Просто подвести итог - свести к минимуму отклонения и строить их все рядом .

Распределение вашей кодовой базы по нескольким основным ветвям (для каждого клиента) быстро станет невозможным.

0 голосов
/ 26 сентября 2018

также использовать запросы на извлечение для объединения общих действительных коммитов из feature-customerXYZ для разработки?

Да.

Таким образом, сопровождающий проекта может выбрать, какие части кода полезны для основной записи / разработки продукта?

Нет: сопровождающий проекта должен принимать только PR, тривиальный для слияния (ускоренная перемотка вперед), и запускать тесты для проверки работоспособности PR.
Он / она не отвечает завыбор частей: только разработчик должен выбирать их (поскольку он / она знает о том, что нужно подвергать воздействию dev / master.

Так что для случая 1 все еще требуется выбор вишни или перебазирование, чтобы сделать выделенную ветку (отдельную от функции), которая затем будет передана в dev или master через PR для проверки.

Для случая 2 исправление должно быть объединено для разработки, и каждая ветвь функции может,в свое время перебазирует в самое последнее состояние разработки , следовательно, включая hostfix

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...