Стратегия ветвления Git для адаптации к изменению приоритетов функций

Я вижу, вы ссылаетесь на стандартную стратегию ветвления «git flow», представленную в http://nvie.com/posts/a-successful-git-branching-model/ и присутствует в той или иной форме во многих крупных проектах.

Следует отметить отрывок о ветке «разработка»:

[Ветка разработки] всегда отражает состояние с последними доставленными изменениями разработки для следующего выпуска.

и пассаж о ветках фич:

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

Изменения не должны появляться в ветке «Разработка» до тех пор, пока они не будут подтверждены для выпуска. Если ваш проект X не получил разрешения на выпуск, его не должно быть в ветке разработки, и поэтому у вас не будет проблем с выпуском только проекта Y.

Итак, отвечая на ваши вопросы,

1) Вы можете выбрать свой проект Y, чтобы подать заявку на мастер. Я не рекомендую это делать, так как master должен быть известным стабильным состоянием, и вы не будете тестировать среду с проектом Y, но не с проектом X, чтобы подтвердить это. Вместо этого я бы отменил изменения Project X из разработки (оставив их в ветке функций) , повторно протестируйте, а затем слейте в мастер.

Будьте осторожны при повторном применении изменений из функциональной ветки Project X в разработке, так как они по-прежнему будут иметь историю слияния, и их повторное применение становится нетривиальным — см. здесь для старого обсуждения.

2) Я считаю, что отдельные репозитории вам не помогут, если проекты все равно будут охватывать несколько репозиториев. В общем, у вас должно быть все в порядке со структурой, как у вас уже есть. Если описанный сценарий (блокировка релиза в последнюю минуту для функции, уже находящейся в разработке) происходит часто, то ваша проблема связана с процессом утверждения изменений в разработке. Функции с неопределенным будущим должны размещаться в соответствующих ветках до тех пор, пока не будет подтвержден выпуск. Стоимость (как время, так и риск) отказа от изменений после их подтверждения должна быть ясна для бизнеса.

с моей точки зрения, вы должны разделить a, b и c на три отдельных репозитория/проекта. a и b должны ссылаться на c как на зависимость.

проект x будет иметь прямую зависимость a и c «через» a. проект y будет иметь b как прямую зависимость и c «через» b.

вы можете продолжить разработку новых функций для проекта y и решения b без какого-либо влияния на проект x. если вы не внесете изменения в решение c, которые могут изменить реализацию решения a и/или решения b.

PS: я знаю, что этот ответ не является настоящим «решением». а может быть своеобразное "подтверждение" того, что вы и так знаете. или «поощрение» делать то, что вы когда-либо хотели изменить. :-)