git rebaseに関して、色々なサイトの説明を読んでいて勘違いしていた事があった。
今までは
git rebase → そのブランチで行った変更を、rebase対象のブランチの変更の後に実施するような形のマージを行う
だと思っていた。
ブランチ管理のルール上origin/masterへのmerge前にrebaseが必須だったものを、今回rebaseせずにmergeしてしまった事により
revertしてやり直す事になった。
自分のローカル作業ブランチには修正したものが変わらずあったので、何の躊躇もなく
git rebase origin/master
を実行したところ、修正が全部消えてしまった。
「あれれれー」
自分の想定では、rebaseすることで
現在のorigin/masterの変更が適用された後、作業ブランチで作業した変更が適用
こうなると思っていたが、どうやら少し違うようだ。
自分の作業ブランチで行われたすべての変更を、対象ブランチの差分取得後に適用すると思っていたのだがこれは大きな勘違いだった。
比較対象との最新の共通の祖先まで戻り、そこからの差分を適用するということらしい。
どうやらこういうことらしい
1. 現在のブランチ（D,E,Jコミット）でおこなわれた変更を一時的に保存
2. 移行先のブランチ（master）にリセットする（git reset --hard master）
3. 1.で一時的に保存したコミットを順番に適用していく（親が違うので、コミットIDも変わる）
この1.の部分が、ブランチを切った時点の話だと思い込んでいた。
だがいったんmergeしてしまうと、今度はそこが起点になるようだ。
今回の場合は過去にコミットした修正対象のコミットをcherry-pickすることで解決した。