回答編集履歴

1

微修正

2024/01/27 08:36

投稿

ikedas
ikedas

スコア4443

test CHANGED
@@ -1,10 +1,10 @@
1
1
  作業中のブランチ (feature-B) を、更新されたベースブランチ (この質問ではdev) でrebaseすること自体は、必要があればやってよいと思います。
2
2
 
3
- たとえば、ベースブランチの更新 (この質問ではdevをfeature-Aをmergeしたこと) がfeature-Bでの変更とコンフリクトするようになった場合を考えてみます。
3
+ たとえば、ベースブランチの更新 (この質問ではfeature-Aをdevにmergeしたこと) がfeature-Bでの変更とコンフリクトするようになった場合を考えてみます。
4
4
  - feature-Bをすぐにdevにmergeしてよいのであれば、mergeコミットでコンフリクト解消作業をすればいいのでrebaseは不要です。しかし、mergeにはレビューを経るなどある程度の時間がかかるのが普通ですので現実的ではないかもしれません。
5
5
  - feature-Aをmergeした後のdevをfeature-Bにmergeしてそれをpullしてくれば、コンフリクトは解消されます。しかしfeature-Bの作業中にfeature-Aの履歴が割り込むことになり、feature-Bの作業者としては作業しにくいかもしれません。履歴も複雑になります。
6
6
  - feature-Aをmergeした後のdevでfeature-Bをrebaseしてやれば、上述のような問題はありません。
7
7
 
8
- もちろん、rebaseしたものをpushするにはforce pushが必要になります。force pushはコミットのハッシュが変わってしまうので好まない人もいるのかもしれません。ですが逆に、コミット履歴がきれいになるようにコミットの分割・統合などをしたがる人もいます。後者のような人にとっては、コンフリクト解消などの手間いらず履歴がきれいなrebaseずみブランチの方が好ましいでしょう。
8
+ もちろん、rebaseしたものをpushするにはforce pushが必要になります。force pushはコミットのハッシュが変わってしまうので好まない人もいるのかもしれません。ですが逆に、コミット履歴がきれいになるようにコミットの分割・統合などをしたがる人もいます。後者のような人にとっては、コンフリクト解消などの手間いらず履歴がきれいなrebaseずみブランチの方が好ましいでしょう。
9
9
 
10
- 要は、force pushは必ずだめなのではなく、何をやっているか分かっていて使うのならよいと思います (もっともプロジェクトによってはforce pushを禁止している場合もあるでしょうから、そういった場合はプロジェクトの方針に従うべきでしょうが)。
10
+ 要は、force pushは必ずだめなのではなく、何をやっているか分かっていて使うのならよいと思います (もっともプロジェクトによってはforce pushを禁止している場合もあるでしょうから、そういった場合はプロジェクトの方針に従うべきでしょうが)。