Стратегия ветвления Git для изменения приоритетов функций
Как Project X может быть выпущен (объединен с Master) без изменений Project Y?
Двигаясь вперед, должны ли решения A, B и C быть отдельными репозиториями, движущимися вперед (несмотря на то, что они связаны на уровне бизнеса)?
сценарий
У нас есть один репозиторий, который содержит:
- Решение А
- Решение Б
- Решение C (Общие компоненты)
Решение A и B оба "подключаются" к нашей общей Системе, которая соединяет их все вместе с помощью общих компонентов. Решения A и B полагаются на общие компоненты в решении C.
Project X требует изменений в решениях A и C. Эти изменения сделаны в функциональных ветках, объединены обратно в dev и постоянно развертываются в нашей промежуточной среде.
Проект Y требует изменений только в решениях B. Снова в функциональных ветках, слитых обратно в dev и постоянно развернутых в Staging.
Git History
На данный момент наша история Git выглядит следующим образом (от самого раннего до последнего):
-> ProjectX -> ProjectY
Бизнес-требование
Бизнес больше не хочет, чтобы Проект X был запущен в производство, поскольку Проект Y теперь является "приоритетом 1". Никакие изменения из Project X не могут быть выпущены.
Стратегия ветвления
Мы придерживаемся следующей стратегии: 
Стратегия релиза
Мы разворачиваем полные пакеты продуктов, а не дифференциальные.
При слиянии с Dev Team Foundation Server развертывается в Staging.
При объединении с Master Team Foundation Server предоставляет форматированный пакет развертывания для каждого определения сборки.
2 ответа
Я вижу, что вы ссылаетесь на стандартную стратегию ветвления 'git flow', представленную на http://nvie.com/posts/a-successful-git-branching-model/ и присутствующую в той или иной форме во многих крупных проектах.
Следует отметить отрывок о ветке "разработка":
[Ветвь разработки] всегда отражает состояние с последними внесенными изменениями разработки для следующего выпуска
и отрывок об особенностях веток:
Суть ветви функции заключается в том, что она существует до тех пор, пока эта функция находится в разработке, но в конечном итоге будет объединена с разработкой (чтобы обязательно добавить новую функцию в предстоящий выпуск) или отвергнута (в случае неудачного эксперимента).
Изменения не должны появляться в ветке 'development' до тех пор, пока они не будут подтверждены к выпуску. Если ваш Project X не получил разрешения на выпуск, он не должен присутствовать в ветви разработки, и поэтому у вас не будет проблем с выпуском только Project Y.
Итак, в ответ на ваши вопросы,
1) Вы можете выбрать свои коммиты Project Y и обратиться к мастеру. Я не рекомендую это, поскольку предполагается, что master является известным стабильным состоянием, и вы не будете тестировать среду с Project Y, но не Project X, чтобы подтвердить это. Вместо этого я бы вернул изменения Project X из разработки (оставив их в ветви функций), повторно протестировал, а затем слил развитие в master.
Будьте осторожны, повторно применяя изменения из ветки компонентов Project X в разработке, так как они по-прежнему будут иметь историю слияний, и повторное их применение становится нетривиальным - см. Здесь для старого обсуждения.
2) Я считаю, что отдельные репозитории вам не помогут, если проекты все равно будут охватывать несколько репозиториев. В общем, вы должны быть в порядке со структурой, как у вас уже есть. Если описанный сценарий (последний выпуск блока для функции, уже находящейся в разработке) встречается часто, то ваша проблема связана с процессом утверждения изменений в разработке. Функции с неопределенным будущим должны быть размещены в их ветвях функций до тех пор, пока не будет подтвержден выпуск. Стоимость (как время, так и риск) возврата изменений после их подтверждения должна быть доведена до сведения бизнеса.
На мой взгляд, вы должны разделить a, b и c на три отдельных репо / проекта. a и b должны ссылаться на c как на зависимость.
Проект x будет иметь прямую зависимость а c "через" а. у проекта у будет b как прямая зависимость и c "через" b.
Вы можете продолжить разработку новых функций для проекта y и решения b без какого-либо влияния на проект x. если вы не внесете изменения в решение c, которые могут изменить значение решения a и / или решения b.
PS: я знаю, что этот ответ не является реальным "решением". но, может быть, своего рода "подтверждение" того, что вы уже знаете. или "поощрение" делать то, что вы когда-либо хотели изменить.:-)