- Git 11©2ch.net
882 ：sage[]：2015/03/11(水) 11:52:10.48 ID:MzuOpnCI - git勉強中の身ですが、僕の理解を確認させてください
結論から言えば、 >>654 のやりかたがいいとおもいました。
自分だけ(あるいは十分に小さなチーム内)で閉じている時なら、rebaseにより歴史を改竄して「分かりやすい歴史」「重要な部分のみを含む歴史」にする。
一旦、統合ブランチ(通常は開発ブランチ/場合によってはmasterブランチが統合ブランチになる)などにマージして、他の人と共有したら、もうrebaseによる歴史の改竄はしない、バグやtypo修正もそのまま正直に表す。
これが上手くいくのは、自分だけで開発している段階が、一番小さく重要でない修正が多いから。
こういう理解でいいでしょうか？
|
- Git 11©2ch.net
884 ：sage[]：2015/03/11(水) 13:06:09.72 ID:MzuOpnCI - >>883
いらない人がいるのはわかっています。
だからといって要る人からrebaseを奪うのはどうなのでしょう？
・ローカルのfeatureブランチの小さなfixやtypo修正のコミットが統合ブランチに残って邪魔
・bisectがうまくいかない
という話には、どう反論されますか？
|
- Git 11©2ch.net
885 ：sage[]：2015/03/11(水) 13:10:52.39 ID:MzuOpnCI - >>879
A successful Git branching model では、安定(運用)ブランチと、開発ブランチと、
機能の実装とテストのブランチを分けているように思います。
リポジトリを分けるという話はまだ聞いたことがないけど。
|
- Git 11©2ch.net
886 ：sage[]：2015/03/11(水) 13:19:52.06 ID:MzuOpnCI - >>883
質問なのですが、まつもと先生がマージ前にrebaseしていないということは、どのようにして分かるのですか？
初心者の僕の疑問なのですが、
ローカルリポジトリにあるローカルブランチでrebaseをして歴史を改竄後、ローカルブランチをpushしたら、改竄後のcommitとブランチ「のみ」がリモートに残り、みんなに公開されると思います。
だから、rubyのリモートリポジトリを見ただけで、matzのローカルリポジトリを見ないと、rebaseを使ってないとは断言できないように思いました。
僕の理解は間違っていますか？
教えて偉い人、教えてエロい人
もし >>883 さんがまつもと先生のローカルリポジトリを見たのならごめんなさい。
|
- Git 11©2ch.net
890 ：sage[]：2015/03/11(水) 15:16:01.21 ID:MzuOpnCI - >>887
覗きました。
具体的には mruby のリポジトリをクローンして git log --graph しました。(ブランチはmasterブランチしかありません)
rubyのリポジトリも git log --graph で樹形図を見ました。
しかしrebaseに関して情報が見えません。
rebase前とrebase後を比べれば、commit IDや親のIDが変わっているはずだ、というのは分かります。
しかし見ているのはrebase後のものなので、前とIDを比較することもできず困っています。
ここからどうすれば分かるのですか？
|
- Git 11©2ch.net
891 ：882[]：2015/03/11(水) 15:21:43.53 ID:MzuOpnCI - >>889
何を自演しているということですか？
僕が質問と回答の両方をしているという意味ですか？
僕は今日ひさしぶりに書き込んで、このIDだけしか書いてないです。
自演ではありません。
|
- Git 11©2ch.net
892 ：882[]：2015/03/11(水) 15:34:59.45 ID:MzuOpnCI - rubyのほうは履歴が一直線ですね。
これってrebaseとかは関係なく、svnと連携しているからですかね？
mrubyのほうは履歴がごちゃごちゃしています。
多いところでは5本くらいブランチが並行して走ってます。
ただ、これを見ても、ローカルでrebaseしてないとは僕には分からないのですが、
rebaseしていないということは、どのように分かりますか？
|
- Git 11©2ch.net
895 ：882[]：2015/03/11(水) 16:26:25.54 ID:MzuOpnCI - >>893
rebaseすれば、ログには残らない
対偶をとって、
ログに残っているのだから、rebaseしていない。
と、このような推論をされたのでしょうか？
そうでしたら、その推論は論理的に間違っています。
なぜなら、変更は1つではなく、たくさんあるからです。
命題論理ではなく、述語論理を使わなくてはなりません。
(1) 全ての無駄な変更をrebaseすれば、その変更はログには残らない。
よって
(2) 無駄な変更がログに残っているのだから、全ての無駄な変更をrebaseした、とは言えない。
と、このような推論が正しいです。
(1)から、
(3) 無駄な変更がログに残っているのだから、matzはrebaseしない
を推論しているとすれば、その推論は論理的に間違っています。
形式的に言うと、
∃¬rebase(x) … rebaseしていない変更が存在する
から論理的に正しく推論されるのは、
¬∀rebase(x) … すべての無駄な変更をrebaseしている、とは言えない
であり、
∀¬rebase(x) … (matzは) 常にrebaseしない
や
¬∃rebase(x) … (matzが) rebaseすることはない
は推論できない、ということだと思います。
¬と∀や∃の位置が異なることが分かると思います。
|
- Git 11©2ch.net
896 ：882[]：2015/03/11(水) 16:27:42.36 ID:MzuOpnCI - matzがrebaseについてどんな考え方を持っているかはわかりませんでしたが、
>>893 さんのおかげで ruby / mruby のリポジトリを見ました。
ありがとうございます。
|
- Git 11©2ch.net
897 ：882[]：2015/03/11(水) 16:41:23.48 ID:MzuOpnCI - >>894
共有リポジトリに残すべきでない、つまらない情報というのは
LookupDNS() という関数を作った
↓
f() g() h() から LookupDNS() を使うように修正
↓ ←見直してたら LookupDns() でなければならないことに気づいたので
LookupDns() に修正してコミット
こういう履歴を、rebase を使えば
LookupDns() という関数を作った
↓
f() g() h() から LookupDns()を使うように修正
というようなシンプルな履歴になおせるということだと思います。
他にも、コード修正してたら意味もなくスペースを変なところに追加してしまった、スペースはなかったことにしたい、だとかいうのも、あとで改竄できますね。
このような細かすぎて害(コスト)の方が大きい履歴の場合、rebaseを使ってはどうですか？ というのが、rebase容認派の意見だと思います。
エクセルなどで文書化するのもひとつの方法ですが、それはそれで、コードとドキュメントの整合性を常に確認しなくてはならない、という新たなコストが発生してしまうので、silver bullet ではないと思います。
|
- Git 11©2ch.net
899 ：882[]：2015/03/11(水) 20:21:08.91 ID:MzuOpnCI - >>898
あくまで勉強中の僕の理解ですが
- rebaseをして歴史をほぼ一直線にしておくと、bisectで原因となるcommitを狭い範囲に絞れる。
- 一方、普通のmergeでは、bisectで見つかるのはマージコミットで、具体的に原因となるコミットを探すためには、更にbisectをかける必要があり、コストが増える。
これがbisectとmergeに伴うコストです.
後者は、CIなどで コミット→テスト→赤が増える→自動でbisect というふうに自動化している場合、
bisectが一発で原因特定してくれないと、人間が手動でbisectをかけなおさないといけないのがけっこう面倒(しかも毎回利子が付く技術的負債)なのではないか、と予想しています。
おっしゃってる「クソみたいなコミット」はどのようなものでしょうか？
ローカルで名前を変更した直後にまた変更するようなら、前の変更は他の人に共有する必要がない「クソみたいなコミット」だと思います。
一方、それが本質的な変更なら、rebaseしてもそのコミットを消さずに、そのままpushしなくてはなりませんね。
bisectで絞り込むには、ある程度粒度が細かい方が良いでしょうね。
rebaseするにしても、rebaseの際にどの程度のコミットを消し、どのコミットを残し、どのコミットをまとめるか、というのは、プロジェクトによって最適解が違うような気がしてます。
|
- Git 11©2ch.net
902 ：882[]：2015/03/11(水) 21:22:30.41 ID:MzuOpnCI - >>900
そうではないですよ。
すくなくとも僕はそんな二項対立でとらえていません。
いろいろな手法にメリットとデメリットが存在する、という見方です。
実際、小さなチームで机を付き合わせてる場合なんか、いったん共有したものすら、口頭で確認の上、rebaseして良い場合もあるでしょう。
一方、rebaseを前面的に禁止にしないと弊害が大きいような寄せ集めチームも日本のどこかにはあるでしょう。
一言でいえば、ケースバイケースなんだと思います。
bisectを自動化する上では、--no-ffもやめて完全に一本道にすることに、メリットもあるよね、というだけです。
メリットがデメリットよりも大きいかは、ケースバイケースだと思います。
マージコミットの粒度が小さければ、--no-ffなマージでも十分にしぼりこめたと言えますから、そのメリットは小さくなるはずです。
マージコミットの粒度が大きいような手法なら、ffだけで一本道にすることのメリットは大きくなるとおもいます。
>>901
なぜそのように言えますか？
マージコミットの粒度が大きい場合、そのように言えないと思います。
|
- Git 11©2ch.net
904 ：882[]：2015/03/11(水) 22:07:01.71 ID:MzuOpnCI - >>903
僕も含め、みんなそうしていると思いますよ
その中で並行して議論したり情報交換をしたりしているのだと思います
|
- Git 11©2ch.net
907 ：882[]：2015/03/11(水) 22:13:43.61 ID:MzuOpnCI - >>905
MacでSourceTree使って開発/gitの勉強してます
(ときどきCUI)
SourceTreeのWindows版は重いとか聞きました
|