git rebaseを用いたdevelop branchがmain branchに追いつく際の注意点についての相談

mainから分岐しているdevelop branchに対して
mainの変更を取り入れ追いつきたい場合に、
mergeとrebaseの二通りがあると思います。

私としてはrebaseを推しているのですが、fource pushが必要になったりと
いまいちそれに対してはっきり大丈夫ですと人に説明ができません。
というか本当に大丈夫なのかあんまりわからないので教えてください。
(業務ではgitlabのrebaseのボタンを押していつもやっています)
(そもそもこのボタンが具体的に何を行っているのかも教えていただきたいです)

まず、私の理解を下記に示しますので、おかしいところがありましたらご指摘お願いします。

* 10000(develop分岐前のcommit) | * 10001(mainの更新commit) <- main, origin/main, origin main

* 10000(develop分岐前のcommit) | * 20000(developのcommit) |\ * | 20001 | * 20002 |/ * 20003 (Merge remote-tracking branch 'origin/develop' into develop) | * 20004 <- develop, origin/develop, origin develop

例えばmain, developはそれぞれ状況のようなcommit logだったとします。
これらはremoteにもpushで反映済みです。
また、数字はcommit idのつもりです。
(developはlocalの更新などなんだかんだで枝分かれしてたりしています)

ここでmainには新しいcommit10001が積まれているのでdevelopに反映したいです。

bash

1$ git checkout develop 2$ git rebase main

すると......

* 10000 | * 10001 | * 21000 (元 commit20000) | * 21001 (元 commit20001) | * 21002 (元 commit20002) | * 21004 (元 commit20004) <- develop

となりました。 (手元で確認した結果 もちろんcommit idは適当です)
(merge commit20003は消えていました、そういう仕様なんですね？)

rebaseをしたことにより歴史の改変が行われ、
明らかにorigin developとdevelpが異なり(non-fastfowardというっぽいですね)、
fource pushが必要であることはわかります。

もしも最後に自分がfetchしてから今までにdevelop branchを共有している誰か(Bさん)が
remoteを更新した場合(commit20004のあとに新しいcommit 20005を積んだ)、
fource pushするとその人のcommit20005がまるまるきえてしまうので危険！というのはわかります。

しかし、

bash

1$ git fetch 2$ git checkout main 3$ git rebase origin/main 4$ git checkout develop 5$ git rebase main 6$ git push -f origin develop

常に最新のbranchに対して行えば、つまり上記の手順を一瞬でやれば
危険はないと思うのですが、理解としてあっていますでしょうか。
以上のことからGitlabのrebaseボタンは上記のコマンドをやってくれているのかなと思っています。

そのあとBさんが新たにcommit20006をlocalで積んでてて
pushしようとすると、おっッとなりますが

bash

1$ git checkout develop 2$ git fetch 3$ git rebase origin/develop 4$ git push origin develop

で問題なくできると思います。(できますよね？)

こういう場合で危険な場合もあるのでrebaseはおすすめしません、などがありましたら教えていただきたいです。