Gitflow: функция завершения не выполняет слияние --no-ff

Созданный на 14 февр. 2011  ·  12Комментарии  ·  Источник: nvie/gitflow

Мне нравится рабочий процесс, описанный в статье «Успешная модель ветвления Git». Мне особенно нравится использование объектов фиксации для слияния функций.

Я только что заметил, что git-flow может использовать слияние --no-ff, а в других случаях - нет. Почему это? Это задумано?

Нужно ли мне форкнуть git-flow, чтобы заставить его работать с слиянием функций --no-ff, или есть какой-то способ настроить это?

Спасибо,
Скотт

Самый полезный комментарий

Привет Винсент,

Я могу определенно понять мышление, лежащее в основе этого дизайна, но я думаю, что выбор того, следует ли создавать коммит слияния, должен быть продиктован тем, решит ли пользователь запустить ветвь функции. Иногда я могу вносить быстрые изменения в ветку разработки, но я предпочитаю создать ветку функций _ специально_, потому что хочу увидеть фиксацию слияния. Я мог бы сделать только одну фиксацию в функциональной ветке, но это может быть не то, что я как пользователь считаю достаточно незначительным, чтобы гарантировать игнорирование явной фиксации слияния.

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

Мы будем очень признательны за любые указатели на то, где я мог бы пойти в базе кода, чтобы внести это изменение в частную форму!

Большое спасибо за отличный инструмент!
-Скотт

Все 12 Комментарий

Привет Скотт,

По задумке, git-flow использует параметр --no-ff при слиянии, чтобы зафиксировать исторически сложившуюся историю коммитов. Однако, когда функциональная ветвь содержит только одну фиксацию, дополнительная фиксация слияния ничего не добавляет и только без надобности усложняет дерево ветвей. Таким образом, для ветвей с одной фиксацией слияния с быстрой перемоткой вперед выполняются так, как если бы фиксация была сделана непосредственно для develop .

Ваше здоровье,
Винсент

Привет Винсент,

Я могу определенно понять мышление, лежащее в основе этого дизайна, но я думаю, что выбор того, следует ли создавать коммит слияния, должен быть продиктован тем, решит ли пользователь запустить ветвь функции. Иногда я могу вносить быстрые изменения в ветку разработки, но я предпочитаю создать ветку функций _ специально_, потому что хочу увидеть фиксацию слияния. Я мог бы сделать только одну фиксацию в функциональной ветке, но это может быть не то, что я как пользователь считаю достаточно незначительным, чтобы гарантировать игнорирование явной фиксации слияния.

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

Мы будем очень признательны за любые указатели на то, где я мог бы пойти в базе кода, чтобы внести это изменение в частную форму!

Большое спасибо за отличный инструмент!
-Скотт

Здесь происходит волшебство: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

Я не собираюсь добавлять опцию для явного слияния ветвей функции одиночной фиксации с --no-ff, так как я до сих пор не думаю, что это добавляет что-либо (кроме дополнительной сложности другого флага командной строки), но не стесняйтесь вносить изменения в частном порядке, если настаиваете на этом.

Ваше здоровье,
Винсент

Спасибо, Винсент! Ценю указатель!

Лучший,
Скотт

Если я могу добавить свои 5 центов,

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

В том, как я использую git flow, мои функции включают в свое имя номер билета, над которым я работаю. Когда я закончу работу над функцией, мне очень хотелось бы увидеть фиксацию слияния с указанием имени функции (включая номер заявки).

Это полезно для отслеживания каждой фиксации фактического тикета без необходимости указывать номер тикета в каждом сообщении фиксации.

@DonGiulio Не знаю, проверяли ли вы это уже, но я почти уверен, что версия AVH делает то, что вы хотите.

Спасибо, не знал, проверю.

Я также предпочитаю просто добавить возможность иметь одноразовое поведение no-ff. Было бы неплохо, если бы вы могли это пересмотреть.

(Я не уверен, что еще есть в редакции AVH).

@nvie Могу я, а почему ?! "_Я до сих пор не думаю, что это что-то добавляет_"
Я честно подумал, когда группа людей считает, что он что-то добавляет, а некоторые думают, что это не значит, что мы где-то добавляем опцию или, по крайней мере, документируем это, чтобы людям не нужно было искать это методом проб и ошибок. Это не может быть таким серьезным решением!

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

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

@Mehradzie По этому репо не было никаких обязательств за 5 лет. Версия AVH уже некоторое время является популярной и довольно стабильной. Я бы не стал задерживать дыхание, ожидая здесь ответа, не говоря уже об изменении кода.

@jawshooah, если честно, я даже не проверил имя репо, когда оказался здесь, поскольку я преследовал ту же проблему в SourceTree.
Является ли gitflow тем, что SourceTree использует для потоков? Я сейчас немного запутался: D
И если да, то можно ли его порезать и изменить, поскольку вы предлагали вместо этого использовать какие-то другие репозитории!

@Mehradzie AFAIK SourceTree включает слегка измененную версию исходной версии nvie. Есть невыполненные запросы на обновление до версии AVH (см. Здесь и здесь ).

Была ли эта страница полезной?
0 / 5 - 0 рейтинги