Релиз Git с отменённой фиксацией на мастере

Я просто попал в очень неожиданное поведение git, следуя стандартной dev/master разработке модель.

В прошлом я случайно объединил PR A от участника с master и использовал онлайн-функции «отката» GitHub, чтобы добавить возврат-фиксацию R, чтобы исправить ошибочно размещенную фиксацию. Затем я объединил A с dev.

• master: ...-1-2-3-A-R
• dev: ...-1-2-3-4-5-6-A-...

Спустя несколько месяцев я выпустил новую версию программного обеспечения со слиянием с dev на master посредством простого слияния (онлайн-реклама на GitHub).

• dev: ...-1-2-3-4-5-6-A-7-8-9 as PR to master

Слияние теперь реализовано «эй, у меня уже есть коммит A» и применены все остальные коммиты. Но теперь изменения A не находятся в HEAD мастера, так как они также были отменены R, который затем не воспроизводился снова со слиянием от dev до master, которое должно было окончательно добавить A.

С точки зрения кода это выглядит так, а [7-8-9] — это фактическая дельта коммита слияния, примененная к основной ветке:

• master: ...-1-2-3-A-R-[7-8-9]

Вот фактическая история git, упрощенная, в виде графика с визуализацией сети GitHub:

или как текстовый график (будет полный набор ветвей функций)

*   b8f9e33 (HEAD, tag: v1.5.0, mainline/master) Merge pull request #253 from dev
|\  
| *   563da86 Merge pull request #252
| |\  
| | * 562f9b4 ChangeLog for Release 1.5.0
| |/  
| *   b780652 Merge pull request #251
| |\  
| | * 2275d92 Werror: On Travis Only
| * |   3e02c75 Merge pull request #250
| |\ \  
| | |/  
| |/|   
| | * 1674897 update documentation
| | * d31a7f1 Attribute Writing: Create Group if Missing
| | * a047ab5 extent attribute tests (parallel/serial)
| |/  
| * f9ebe2e Fixed indentations
| * 2b2c146 README: Minor Fix line break
| *   9254272 Merge pull request #247
| |\  
| | * 2bb3e90 Throw exception on invalid calls
| * |   c55e4e7 Merge pull request #246
| |\ \  
| | |/  
| |/|   
| | * 419cd57 Implement generateCollectionType in cpp
| |/  
| *   7053e39 Merge pull request #242
| |\  
| * \   32dab56 Merge pull request #243
| |\ \  
| | * | 894e31a Compare agains NULL
| | * | 0cc4cca Compile in debug mode so runtime tests can trigger assertions
| | * | b9e3b14 Move typeid check into assertion
| | * | 47a810a Fix memory leak in generateCollectionType
* | | |   e3f2a88 Merge pull request #241 from revert-234-master
|\ \ \ \  
| * | | | fb8800e Revert "Make filename creation consistent"
|/ / / /  
* | | |   0b6cb96 Merge pull request #234
|\ \ \ \  
| |_|/ /  
|/| | /   
| | |/    
| |/|     
| * | 4f6e7e6 Fix close/finalize order
| * | f36f925 Disallow using Fullname ...
| * | 6f1c0cd Close files on dtor
| * | 936c002 Don't delete test h5-files and honor line length
| * | e43906a Fix tests
| * | a68c7cf Address PR comments
| * | 380e5de Consistent use of fileNameScheme instead of singleFile
| * | c6033bc Make filename creation consistent
|/ /  
* |   467c85e (tag: v1.4.0) Merge pull request #230 from dev

Следовательно, слияние dev с master теперь приводит к «уже актуальному», а слияние master с dev предлагает удалить A. Но... я хочу A!

Ты знаешь

• каков был бы правильный рабочий процесс, чтобы изящно отменить такое слияние и применить его позже?
• как выйти из этой ситуации?

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

(master $=) $ git merge dev --strategy=theirs