git rebase -i でコミットをまとめているだけ(のつもり)なのにコンフリクトに遭遇した

知ってる人からしたら当たり前の挙動なのかもしれないですが、初めて遭遇したので。

起きたこと

いつものようにgit rebase -i mainみたいにブランチの元となるコミットから伸びたコミットをまとめようとしていたら、コンフリクトが発生しました。
もともとmainから伸ばしたブランチでgit rebase -i mainではコンフリクトの発生はないと思っていたので混乱しました。

原因

コミットをまとめようとしていたブランチで過去にmergeでコンフリクト解消を行なっていたのが原因でした。
一度mergeでコンフリクト解消していてもrebaseで再度コミットをまとめようとすると同じコンフリクト解消をやる必要があるみたいです。私はrebase派なため、mergeでのコンフリクト解消はやらないようにしていたのでこれまで遭遇することがなかったのだと思います。

ちなみに、上記のmergeでのコンフリクト解消は他の方がやっていた作業です。チーム内ルールでmergeでもrebaseでもOKだったのでmergeで実施していたみたいですね。

状況説明

その時のgit graphを簡易的に再現したのが↓のような感じです。
コミットハッシュのところは便宜上名前をつけてます。

*   commit merge-commit1 (HEAD -> feature/base)
|\  Merge: base-commit1 dev-commit2
| | 
| |
| * commit dev-commit2 (dev-branch-1)
| | 
| |
| * commit dev-commit1
| | 
| |
* | commit base-commit1
|/  
|
* commit 775e09 (main)

上記の状態になるまでの作業順で言うと以下のような感じです。

1. feature/baseをmainから作成
2. そこからdev-branch-1を作成し、dev-commit1、2を作成
3. dev-branch-1のコミットがfeature/baseにマージされる前にfeature/baseでbase-commit1が作成される
4. feature/baseブランチでgit merge dev-branch-1してコンフリクトを解消しつつfeature/baseに取り込み

この後、冒頭の通りfeature/baseでgit rebase -i mainするとコンフリクトが起きます。内容は4と全く同じなので同じ作業を再度行う必要があるということになります。

結論

rebaseする予定のあるブランチへのマージはrebaseでコンフリクト解消を行ってからやること

で、いいのかな？？
ほんとに再度コンフリクト解消する必要あるのか疑問なのですが、詳しい人いたら教えてください...