LINUX.ORG.RU

Вопрос по git merge

 


0

1

Допустим, есть бранч develop, от которого сначала отпочковывается бранч release, а спустя еще несколько коммитов — feature branch. Фича доводится до ума и мержится в develop. Однако фича получается настолько хорошей, что ее страшно хочется пропихнуть в release.

Как это правильно сделать?

То есть, грубо говоря, нужно влить в release все коммиты, которые показывает git log develop.., будучи сделанным из feature-branch'а. Очевидно, что можно сделать кучу cherry-pick'ов, или заsquash'ить все нужные коммиты в feature и перенести их уже за один cherry-pick, но это не очень хорошо, т. к. коммиты будут разными, что вызовет немало проблем.

По манам выходит, что можно сделать

git checkout release
git merge-base feature develop # запоминаем "точку ветвления" $BASE
git merge -s ours $BASE # делаем вид, что в release есть все, что в feature на момент ее "отпочковывания" от develop
git merge feature

Чисто теоретически это должно работать, но напрягают дополнительные «левые» merge. Может я чего-то не знаю или делаю что-то не так?

Очевидно, что можно сделать кучу cherry-pick'ов, или заsquash'ить все нужные коммиты в feature и перенести их уже за один cherry-pick, но это не очень хорошо, т. к. коммиты будут разными, что вызовет немало проблем.

Только не кучу черри-пиков, а один rebase --onto. Проблем особых это не вызовет, т.к. git поймет что эти коммиты уже были замержены при резолве конфликтов и автоматом их проигнорирует.

maloi ★★★★★
()

Может я чего-то не знаю или делаю что-то не так?

Думаю да:

Однако фича получается настолько хорошей, что ее страшно хочется пропихнуть в release.

Kilte ★★★★★
()
Ответ на: комментарий от tailgunner

Что мешает замержить feature branch прямо в release?

очевидно, что в релиз тогда попадут коммиты из develop, не относящиеся к фиче.

maloi ★★★★★
()
Ответ на: комментарий от maloi

rebase --onto

Но ведь rebase и cherry-pick оба изменяют коммиты, что сильно портит жизнь при дальнейших merge. Или имеется в виду rebase --onto release develop feature с последующим merge результата в develop и release?

kawaii_neko ★★★★
() автор топика
Ответ на: комментарий от Kilte

плюсую, если в релиз хочется пропихнуть дополнительную фичу, то проще уж выкинуть текущий релиз и создать новый.

maloi ★★★★★
()
Ответ на: комментарий от kawaii_neko

что сильно портит жизнь

Только если коммиты в общем доступе.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от kawaii_neko

Но ведь rebase и cherry-pick оба изменяют коммиты,

да

что сильно портит жизнь при дальнейших merge.

нет, git видит что у коммитов совпадает diff и понимает, что это один и тот же коммит.

Или имеется в виду rebase --onto release develop feature с последующим merge результата в develop и release?

можно и так, но какая разница, если ты уже замержил фичу в develop и теперь тебе либо вымерживать её (то ещё удовольствие), либо точно так же мержить её повторно в develop (а ты почему-то боишься, что в таком случае будут конфликты)

maloi ★★★★★
()
Ответ на: комментарий от tailgunner

Что мешает замержить feature branch прямо в release?

feature растет из develop, где происходит активная разработка.

         F---G---H feature
        /
A---B---C---E develop
    \
     release
И вот хочется взять только коммиты, относящиеся к feature и бахнуть их в release, причем merge-friendly способом, поскольку хотфиксы рождаются в release и merge'атся в develop

Если я сделаю git merge feature в release, то туда помимо желаемых F..H попадет еще C, который нафиг не нужен.

kawaii_neko ★★★★
() автор топика
Ответ на: комментарий от maloi

если ты уже замержил фичу в develop и теперь тебе либо вымерживать её

Нет, все не настолько плохо: буквально перед merge в develop стало понятно, что это хочется впихнуть в release, причем feature весьма хорошо «изолирована» (т. е. ничего из develop со времен отпочковывания release ей не надо), однако окружающий код в release..$(merge-base feature develop) поменялся таким образом, что rebase-onto приведет к ряду конфликтов, и merge этого нового бранча обратно в develop также будет иметь ненужные конфликты.

Хотелось бы избежать этого «двойного конфликтного пути».

kawaii_neko ★★★★
() автор топика
Ответ на: комментарий от kawaii_neko

feature растет из develop, где происходит активная разработка

Если develop не мержился в feature, то backout (или что там в git) тебе поможет. А если мержился... либо забить на всю затею, либо тупо cherry pick.

tailgunner ★★★★★
()

У коммита есть parent. Если ты вольёшь коммит из feature в release, то у него с необходимостью parent поменяется, что означает изменение коммита. То есть, коммит стопроцентно будет другой. Отсюда вывод: никак.

Miguel ★★★★★
()

Мне кажется это не совсем «гитовая задача», больше связана с самим проектом.

Либо увеличить частоту релизов (что не всегда приемлемо);

- либо по аналогиям с рабочими циклами kernel.org: от нумерации версий, сбора патчей, уменования до LTS: что неизбежно приведет к необходимости бэкпортов.

swwwfactory ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.