git merge or rebase, ff or no-ff

Kazuho Oku @kazuho

バージョン管理システムの目的は変更履歴を管理することなんだから、git rebase とか履歴を改変するコマンドは言うまでもなくダークサイド

ぐるぐる系SQL @bleis

@kazuho Gitをバージョン管理システムとしてしか見ないのであればそうでしょうね

Kazuho Oku @kazuho

@bleis メインラインの履歴をきれいに見せる目的で rebase が濫用されることが多くてそれに対して言ってます https://t.co/f5wvWTqE

ぐるぐる系SQL @bleis

@kazuho 巨大なbranchのrebaseは反対ですけど、トピックブランチを採用する場合、メインラインの履歴をきれいに見せる目的でのrebaseは悪ではないのでは？

Kazuho Oku @kazuho

@bleis [訂正] うんと、rebase&&merge --ffな運用だと、たとえば３つのコミットから構成されるトピックブランチがあるとして、その３つのコミットいずれの段階でも正しく動くことを（rebaseの後にも）検証しないと master に入れたくなくないですか？

ぐるぐる系SQL @bleis

@kazuho 3つのコミットが1つのトピックを表していることが何らかの方法で分かるのであれば、最終コミットのみで動けばいいですし、そういう方法がないのであれば、squashすべきだと考えます。

Kazuho Oku @kazuho

@bleis 「３つのコミットが１つのトピックを表していること」を表現するための方法がトピックブランチ + merge --no-fだ、という点はまずよろしいですか？それを使わずにコメントを読んでどのコミットが最終コミットか確認したりsquashして情報を欠落させるメリットは何？

Kazuho Oku @kazuho

s/--no-f/--no-ff/

Kazuho Oku @kazuho

git merge で --no-ff すべき理由についても触れられている / “見えないチカラ: A successful Git branching model を翻訳しました” http://t.co/tZztPxOn

ぐるぐる系SQL @bleis

@kazuho 3つのコミットが1つのトピックを表していることを表現する方法の一つとしてno-ffがあるのはいいですが、別にマージコミットだけがそれを表現する方法じゃないです。トピックをチケットと1対1対応させるのであればチケットで管理できますし、他の方法も考えられます

Kazuho Oku @kazuho

@bleis mainlineに、特定のトピックにおける作業途中のコミットを入れてしまうとbisectが困難になりますよね。となると、全てのトピックブランチをsquash mergeすることになりますが、それって不便じゃないですか？

ぐるぐる系SQL @bleis

@kazuho トピックブランチでの作業の最後にmasterにrebaseではないんですか？

Kazuho Oku @kazuho

@bleis それは良くないです。masterへmergeしてCONFLICTで処理するか、masterからトピックブランチへmergeして整合性をとるべきです (続く)

Kazuho Oku @kazuho

@kazuho なぜなら、rebaseしてしまうとトピックブランチを構成する各コミットの文脈が変わるから。それぞれのコミット「できていた」はずのことができなくなっていたりする。rebaseされる各コミットについていちいちテストして修正するなら別だけど

Kazuho Oku @kazuho

まあトピックブランチが短いならrebaseしてもいいとは思いますが

ぐるぐる系SQL @bleis

@kazuho ちなみに、トピックブランチってどのくらいで終わる作業を想定してます？

Kazuho Oku @kazuho

@bleis あ、あと、rebaseしちゃうと他のレポジトリにpushされたものと整合性とれなくなりますよね？

Kazuho Oku @kazuho

@bleis 複数コミットに渡る作業ならなんでも、ですね

ぐるぐる系SQL @bleis

@kazuho 他のリポジトリに公開したものをpushするのは、何の調停手段もない状況ではそもそも論外でしょう。

Kazuho Oku @kazuho

@bleis いや、たとえばトピックブランチをサーバにpushして他の人にレビューしてもらってる間にmasterが更新されたらどうするんでしょう？　別名のトピックブランチを作ってそこでrebase masterする？

Kazuho Oku @kazuho

あるいは特定のトピックブランチで複数人が作業することもありますよね

ぐるぐる系SQL @bleis

@kazuho そもそも開発メンバーが少数なので、pushしてのレビューってフローを取り入れてないのもありますけど、トピックブランチは基本独立した作業になっているので、masterにrebaseしたところで矛盾が起こるようなことはめったにないような環境ですね

ymmt / 山本泰宇 @ymmt2005

ちょうどこの前も git merge --no-ff でいいじゃんという話をしたけど、git 初心者の人が rebase の誇大広告に惑わされて merge より rebase を使おうとしてしまうのが問題な気がする。

Kazuho Oku @kazuho

@bleis なるほどです。CONFLICT の発生を前提にする必要がないのであれば rebase でも十分かもしれません

Kazuho Oku @kazuho

@ymmt2005 初心者の人、っていうより svn の運用ルールで考えると rebase に目が行くのかなと思ってます