git merge or rebase, ff or no-ff

まとめました。
22
Kazuho Oku @kazuho

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

2012-11-09 16:58:32
ふ''れいす @bleis

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

2012-11-09 17:02:43
Kazuho Oku @kazuho

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

2012-11-09 17:04:31
ふ''れいす @bleis

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

2012-11-09 17:06:38
Kazuho Oku @kazuho

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

2012-11-09 17:22:23
ふ''れいす @bleis

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

2012-11-09 18:11:36
Kazuho Oku @kazuho

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

2012-11-09 18:17:04
Kazuho Oku @kazuho

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

2012-11-09 18:20:07
ふ''れいす @bleis

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

2012-11-09 18:20:17
Kazuho Oku @kazuho

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

2012-11-09 18:22:29
ふ''れいす @bleis

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

2012-11-09 18:24:09
Kazuho Oku @kazuho

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

2012-11-09 18:25:45
Kazuho Oku @kazuho

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

2012-11-09 18:26:35
Kazuho Oku @kazuho

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

2012-11-09 18:28:21
ふ''れいす @bleis

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

2012-11-09 18:29:02
Kazuho Oku @kazuho

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

2012-11-09 18:30:28
Kazuho Oku @kazuho

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

2012-11-09 18:30:41
ふ''れいす @bleis

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

2012-11-09 18:31:25
Kazuho Oku @kazuho

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

2012-11-09 18:32:17
Kazuho Oku @kazuho

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

2012-11-09 18:33:31
ふ''れいす @bleis

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

2012-11-09 18:34:45
ymmt / 山本泰宇 @ymmt2005

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

2012-11-09 18:37:17
Kazuho Oku @kazuho

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

2012-11-09 18:38:21
Kazuho Oku @kazuho

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

2012-11-09 18:39:20
残りを読む(2)

コメント

Tsuyoshi CHO @tsuyoshi_cho 2012年11月15日
svnでもマージメインだったからなぁ...というかコンフリクトするような状態だったら、ただ解消すればいいっていう状態は過ぎてるだろうから、そもそも再考するしな...
0
文殊堂 @monjudoh 2012年11月16日
changesetsのcherry-pickとcommit圧縮の、一つ前ではなくて大本を辿れるトラッキングの仕組みがあると色々解決する気が。branchで作業してbranchを残す形で分岐元にrebaseして問題ない状態にしてcommit圧縮、branchは残すがinactiveにする。圧縮済みchangesetからinactiveな元branchは辿れる。
0
文殊堂 @monjudoh 2012年11月22日
rebaseすると個々のchangesetのコンテキストが変わるのでpatchとしては同じだけど意味が変わってしまうというのはその通りなんだが、それだけだと片手落ちだと思う。rebaseではなく逆方向mergeを使うとtopic branchにtopic外のchangesetが含まれることになる。
0
文殊堂 @monjudoh 2012年11月22日
changesetsのグラフが地下鉄の路線図のようになっているリポジトリでmerge間違いがあったのがある程度の期間たってから発覚するとリカバリが難しいのも、逆方向mergeを使うとtopic branchにtopic外のchangesetが含まれてしまうからではないか?
0