Как выполнить спорадическое слияние одной ветви в другую

Question

Я развиваю на ветке dev и каждые пару недель хочется объединить текущее состояние в ветку staging, Кажется, я не продумал это достаточно, потому что теперь, когда я хочу сделать это во второй раз, я получаю конфликт, так как последний общий предок все еще от того, когда я разделился dev выкл - и первое отличие было добавлено к staging в отдельном коммите.

Я использовал запрос слияния gitlab в обоих случаях, с squash commits флажок отмечен

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

---

Как изображение: v_0.2 слияние не удается. То, что я хочу, это сделать выборку функций 5-7, и я надеялся, что gitlab поймет это, поскольку я уже слил функции 1-4. Но это не так.

---

Как вывод консоли: ffc9a2c Является ли последний общий родительский элемент обеих ветвей (по-видимому, слияние, которое произошло там, помещает этот коммит правильно в качестве нового родительского элемента), после чего я запустил схему слияния, описанную выше. Ты можешь видеть staging во всей полноте с этого момента. Я опустил большинство dev, так как это просто очень долго.

git log from staging:
*   5ac9823 Merge branch 'dev' into 'staging'
|\  
| * 50bac27 Code update for v1.rc0.0
|/  
*   5f38284 Merge branch 'dev' into 'staging'
|\  
| *   ffc9a2c Merge branch 'formatting_fix' into 'dev'


git log from dev:
*   176971e Merge branch 'doctest_fix' into 'dev'
|\  
| * 4f0a423 Fix bug for doctest in filters.py
.
.
.
*   945d9ab Merge branch 'return_codes' into 'dev'  # v1.rc0.0 took place here
|\  
| * aed6133 Replace return codes 
.
.
.
|  
*   ffc9a2c Merge branch 'formatting_fix' into 'dev'
|\  
| * 0451416 Improving Error Message Quality

Answer 1

Ваша проблема заключается в squash commits коробка. Вы не объединяли коммиты feature_1 в feature_4 напрямую, но новый сдавленный коммит, который вносит те же изменения. v_0.2 Слияние теперь имеет конфликты, так как вы пытаетесь слить другой сдавленный коммит, частично внося те же самые изменения.

С точки зрения Gits, когда вы пытаетесь объединить dev в stable с v_0.2есть изменения в тех же файлах в stable которые не на dev (из сдавленного коммита слияния), а также изменения в dev которые не на stable (новые изменения, а также изменения от feature_1 до 4, так как эти коммиты не являются частью stables история, только изменения были внесены).

Я думаю, что лучшее решение здесь было бы не так, чтобы раздавить изменения от dev при объединении их в stable, Вы также можете решить это путем слияния stable в dev или перебазирование dev на stable, но это сделало бы вещи еще более запутанными.

Хеши не должны быть одинаковыми; нет проблем с развертыванием исправлений на этапе подготовки и без необходимости их разработки (с точки зрения git. С точки зрения чистого рабочего процесса, по крайней мере, сомнительно что-то исправить, а не объединить его для разработки).