git: вливание в основную ветку частичного функционала

Serab

У меня вот такой workflow: есть master, есть feature-branch'и. Иногда делаю merge _из_ master'а, чтобы подтянуть прогресс основной ветки в feature branch.
Теперь допустим некоторый feature branch дошел до стадии, когда его можно влить в master, но допустим я хочу немного ограничить функционал, например, не отображать некоторые пункты меню в интерфейсе.
Пока сделал так:

master:           *---*--*----*--*--*

                             /

feature-limited:        *-*-*          <------- тут отключаю сыроватый функционал

                       /

feature:          *---*---*----*

Когда работа будет завершена, просто откатываются изменения feature..feature-limited и все гуд.
Тут все красиво, пока мне не понадобятся изменения из master'а. Если сделать merge из master в feature, то в него же войдут коммиты из feature-limited, которые я там не хочу.
Как это реализовать для людей?
Маза ли сделать merge из feature-limited в feature без внесения изменений (-s ours)? Или есть какой-то более логичный workflow для подобной задачи?

danilov

Вынести ограничения в конфиг, который не лежит под гитом?

Corrector

разбить на 2 задачи и соответственно 2 ветки - с рабочим функционалом и сырым

Serab

ну по сути так и есть: feature-limited с сырым функционалом.
В такой схеме решение с merge -s ours выглядит единственным логичным.

Dimon89

ну по сути так и есть: feature-limited с сырым функционалом.
В такой схеме решение с merge -s ours выглядит единственным логичным.

да, мы так и делаем.

Serab

блин, но что-то оно не работает как я ожидал. Т.е. не выходит сделать две ветки, между которыми можно невозбранно мерджить, но они будут немного отличаться при этом. Видимо, я не должен этого хотеть.
Или тут надо вводить дополнительную dev-ветку перед master'ом.

Serab

ах ты ж ебаный ты нахуй

Serab

Вынести ограничения в конфиг, который не лежит под гитом?

в итоге сделал так

6yrop

тут отключаю сыроватый функционал

Не должно быть вот этого. Должны быть две задачи. Надо не отключать функционал, а его не должно быть в некоторой ветке F1. Сырой функционал полностью делаешь в ветке F2 вместе с пунктами меню. Можно подмерживать из F1 в F2.
P.S.я написал с точки зрения TFS

Bibi

Был бы я такой умный вчера, как моя жена сегодня (c)

bleyman

Это эмулируется же постфактум.
В ветке feature-limited отключаешь сырой функционал и коммитишь. И мержишь в мастер.
Дальше мержишь её в ветку feature, а затем git revert отключательный коммит.
Дальше вроде можно спокойно мержить из мастера в фичу, новая функциональность туда попадает, убранные фичи не убираются.
Если честно, я не понимаю _почему_ это работает, ну как бы гит же делает тупой 3-way merge и на него не должно влиять наличие сделанных и ревертнутых коммитов где-то посередине? Или он конструирует merge base хитроумным образом, а не тупо берёт то, что выдаёт git merge-base?
Ну, в любом случае, я щас проверил, вроде работает.

Serab

Был бы я такой умный вчера, как моя жена сегодня (c)

+1 история развивается так: разрабатывается фича, потом внезапно решают влить какую-то готовую ее часть. Да, можно сказать, что надо было заранее "по частям" делать. Но это как грится преждевременная декомпозиция или как там.

Serab

Дальше мержишь её в ветку feature, а затем git revert отключательный коммит.

я пробовал merge -s ours feature-limited.
После этого нельзя было мержить из мастера в feature, он отрубал функционал там.

bleyman

Я сделал простой merge и у меня всё вроде работает правильно, ну, в моём тестовом репо.
Зацени:
edit: "merge -s ours feature-limited" ну ясен пень что тогда отключает же. Допустимые направления для мержа: feature -> feature-limited, master <-> feature, master <-> feature-limited.
Если ты почему-то добавил нужный функционал сначала в feature-limited, то мержи её в мастер, потом обратно в feature. Ну или cherry-pick и поставь свечку к иконе Линуса (у тебя есть, конечно же?) чтобы гит сам разрулил конфликты.