Git rebaseの使い方が正しいか知りたい

実現したいこと

rebaseについての疑問点を解消したい
リモートに1度pushしているブランチをrebaseすると必ずforce pushが必要になるが、現在のrebaseの使い方が正しいか知りたい

発生している問題・分からないこと

以下のrebaseの手順が正しいか知りたい

2チームで開発を進めている
devブランチからfeature-Aとfeature-Bを作成し,それぞれ開発を進める
※両ブランチともレビューしてもらうためリモートにはpush済み
先にdevブランチにfeature-Aをmerge
その後feature-Bをdevブランチにmergeする→この時devブランチはfeature-Aのmerge分1コミット進んでいる状態

この状態でローカルでfeature-Bをrebaseしてdevブランチの最新を取り込む
rebase後devブランチにfeature-Bをmerge

該当のソースコード

特になし

試したこと・調べたこと

teratailやGoogle等で検索した
ソースコードを自分なりに変更した
知人に聞いた
その他

上記の詳細・結果

一度リモートにpushしたブランチはrebaseしてはいけないという記事があった
反対にrebaseをするとforce pushが必要になるのはしょうがないという記事もあった

そもそもリモートにあげたブランチをrebaseしなければforce pushの作業は発生しないと思うので
今回のrebaseの使い方が正しいのかわからない

補足

特になし

行動規範の内容に同意します

回答1件

作業中のブランチ (feature-B) を、更新されたベースブランチ (この質問ではdev) でrebaseすること自体は、必要があればやってよいと思います。

たとえば、ベースブランチの更新 (この質問ではfeature-Aをdevにmergeしたこと) がfeature-Bでの変更とコンフリクトするようになった場合を考えてみます。

feature-Bをすぐにdevにmergeしてよいのであれば、mergeコミットでコンフリクト解消作業をすればいいのでrebaseは不要です。しかし、mergeにはレビューを経るなどある程度の時間がかかるのが普通ですので現実的ではないかもしれません。
feature-Aをmergeした後のdevをfeature-Bにmergeしてそれをpullしてくれば、コンフリクトは解消されます。しかしfeature-Bの作業中にfeature-Aの履歴が割り込むことになり、feature-Bの作業者としては作業しにくいかもしれません。履歴も複雑になります。
feature-Aをmergeした後のdevでfeature-Bをrebaseしてやれば、上述のような問題はありません。

もちろん、rebaseしたものをpushするにはforce pushが必要になります。force pushはコミットのハッシュが変わってしまうので好まない人もいるのかもしれません。ですが逆に、コミット履歴がきれいになるようにコミットの分割・統合などをしたがる人もいます。後者のような人にとっては、コンフリクト解消などの手間がいらず履歴がきれいなrebaseずみブランチの方が好ましいでしょう。

要は、force pushは必ずだめなのではなく、何をやっているのか分かっていて使うのならよいと思います (もっともプロジェクトによってはforce pushを禁止している場合もあるでしょうから、そういった場合はプロジェクトの方針に従うべきでしょうが)。

投稿2024/01/27 08:23

編集2024/01/27 08:36