- Git 12©2ch.net
480 ：デフォルトの名無しさん[sage]：2015/05/20(水) 12:05:48.01 ID:qzEPJuIN - >>474
あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コミットが何十個にもなってるでしょ？それはコミットをまとめないからだよ。
それから一度に変更（マージ）する内容が多すぎだろうね。
これはもう仕事のやりかた、作業の進め方のレベルの話だね。
まともなレビューが行われているかどうか不安になるな。
まず自動テストをしているならば、その内容をテストしたのは明らかなわけで、
何をレビューするかというと書いてあるテストとコードが正しいか漏れがないかだよ。
人力テストをしてもらうんわけじゃない。
つまりコード見て理解できる程度の量でないといけない。それも短い時間でね。
修正内容がバラバラで、順番も修正箇所もごちゃまぜな大量のコミットを一個ずつ見るのは不可能だし
全部まとめて見ると一度に大量のコードを見ないといけなくなるから大変。
レビューアに負担をかけるようなコードはだめだよ。
あと一連の機能を全部まとめてレビューしてもらってるでしょ？
細かい機能毎にわけないとだめだよ。リファクタリングならリファクタリングだけでマージ
モジュールの追加なら（テストコードも含めて）モジュールだけのマージ
それらをいっぺんにレビューするよりも、分けたほうがレビューアの負担は減るのはわかるよね？
君はいっぺんに全部やろうとするから、コミットまとめたり入れ替えた時の時の再テストが
大変とかいう話になってるが、俺の場合は、細かく分けてマージ可能な最小単位に分割するから、
一つの作業ブランチに含まれるコミットは数個しかない。
君、悪循環に陥ってるよ。コミットをまとめないから、マージできる単位に分割できない。
分割できないから一つのブランチの内容が多くのコミットになる。コミットが多いから並び替えたら
コンパイル・テストが通るか不安になる。面倒くさい。だからコミットをまとめないって。
|
- Git 12©2ch.net
481 ：デフォルトの名無しさん[sage]：2015/05/20(水) 12:10:17.30 ID:qzEPJuIN - 長々と書いてしまったが、疑問点としてまとめるわ。
一連の機能を作っている時にリファクタリングやモジュールの追加は
絶対に発生する。ミスも発生する。
一連の機能をいっぺんに全部レビューするのはすごく大変だから
小さく分けた方がいい。
ならば一連の機能をリファクタリングだけのブランチ
機能追加だけのブランチ等にわけて、出来た所からマージした方がいいが、
コミットを入れ替えたりまとめたりしないで、どうやってそれを実現するの？
|
- JavaScript 4©2ch.net
113 ：デフォルトの名無しさん[sage]：2015/05/20(水) 12:18:11.33 ID:qzEPJuIN - 誰でも10日で出来る作業なら
クソだろうさｗ
10日でとても出来ないような作業を
10日で作ったのならば、それは優秀ってことだよ。
優秀な人が作ったのだから、とても良く出来ている。
|
- JavaScript 4©2ch.net
115 ：デフォルトの名無しさん[sage]：2015/05/20(水) 15:12:28.11 ID:qzEPJuIN - どれだよ権威ってｗ
権威じゃなくて実力だろｗ
|
- Git 12©2ch.net
483 ：デフォルトの名無しさん[sage]：2015/05/20(水) 16:38:52.05 ID:qzEPJuIN - >>482
こんな感じにすればいいよ。別にコミットは実際の作業順に合わせる要はない。
* ちょっと書く
* テスト
* ちょっと書く
* テスト
↓ 並び替え（これが失敗することはまずない）
* ちょっと書く
* ちょっと書く
* テスト
* テスト
↓ まとめる（これが失敗することもまずない）
* ちょっと書く
* テスト
この作業を随時やっていく。
・・・つづく
|
- Git 12©2ch.net
484 ：483のつづき[sage]：2015/05/20(水) 16:47:02.59 ID:qzEPJuIN - ところで「ちょっと書く」と「テスト」を一つにするか？
それは内容によって変わる。
コミットを（まとめるべき内容なら）まとめながら作業するのは一緒だが
リファクタリングの時は「ちょっと書く」と「テスト」はまとめない。
* テスト
* ちょっと書く（リファクタリング）
最終的にこうなる。なぜならリファクタリングしても動作は変わらないはずなので、
コードを書いた前と後で全く同じテストが通るから。
それを確認するためにも、リファクタリング前に（テストが不足している場合は）
テストを書いておき、そしてリファクタリングを行う。
またコミットを入れ替えることを前提にすると「後からテスト駆動」が実現できる。
理想としてはテストを先にやるのがテスト駆動なのだが、現実には後からミスが見つかったりして
コードを書いてからテストを追加することが多い。
実際の作業ではコードを書いてからテストを書いたとしても、そしてそれらが
コード書いてテスト、コード書いてテストって繰り返していたとしても、
テストだけまとめて1つ目のコミット。リファクタリングして2つ目のコミットの形にできる。
これでレビューする人は、問題なくリファクタリングできたことを確認できるわけ。
もちろん仕様変更や機能追加などであれば、テストコードと修正を
分ける意味が無いし、一つにするべきなのでまとめる。
|
- Git 12©2ch.net
488 ：デフォルトの名無しさん[sage]：2015/05/20(水) 17:07:28.79 ID:qzEPJuIN - >>485
なんで？ 意味がある単位で小さくすればいいよ。
でも意味がないのに分割する必要はない。
（ローカルでの作業中に）
例えば、関数名これでいいかな・・・コミット
やっぱり、関数名こっちにしよう・・・コミット
いやいや、やっぱり戻そう・・・コミット
ってタイポしてたよ修正・・・コミット
これってコミットを細かく分けたかったわけじゃない。
作業上の都合でコミットがわかれてしまっただけ。
こういう意味が無いコミットはまとめるべき。もちろん
別々の修正であれば、どんどん細かく分けた方がいい。
細かく分けておくと並び替えや分離がしやすくなるよ。
修正しているうちにコミットがたくさんになって、これ一度に
レビューするの無理だろと思ったら、抜き出して別のブランチにするとかね。
でももし意味が無いコミットに分かれていたら、逆に抜き出すの難しくなるからね。
重要なのは、意味がある単位で小さいコミットに分けておくこと。分ける意味が無いものはまとめること。
これがコミットをうまく管理するコツだよ。
|
- Git 12©2ch.net
489 ：デフォルトの名無しさん[sage]：2015/05/20(水) 17:15:41.65 ID:qzEPJuIN - >>487
> みんなそこまでやってたの？ すげーな
git歴は2年ぐらいかな？
最初は当然できなかったよｗ
ただレビュー可能なコードの重要性はわかっていたから、
subversion使っている時、こんな行き当たりばったりの修正履歴じゃ
レビューできないだろっていう認識はあった。
（計画的にやれって思うかもしれないが、ミスや漏れどうしても発生する）
gitを使ってからはどうすればレビューしやすくなるか？を
考えてコミットを作るようにしていたよ。
（ちなみにどちらかと言うと俺はレビュー依頼する側じゃなてレビューする方だけどね）
|
- 今までみた絶望的なソースコード [転載禁止]©2ch.net
126 ：デフォルトの名無しさん[sage]：2015/05/20(水) 17:56:58.18 ID:qzEPJuIN - 念の為に言っておくと、開発効率が悪いから
不具合が発生するリスクが高いから
という理由でコードを綺麗するのは重要なこと
|
- 今までみた絶望的なソースコード [転載禁止]©2ch.net
128 ：デフォルトの名無しさん[sage]：2015/05/20(水) 18:41:48.75 ID:qzEPJuIN - ムダに高い金を払っているってことを
知らせない、知らないほうがお互い幸せだからなｗ
金を払う方は金を払って、作る方は残業して。
こんなに苦しい物が実は無駄なんてｗ
|
- VBプログラマ質問スレ（Ver.6.0 まで） part64
660 ：デフォルトの名無しさん[sage]：2015/05/20(水) 18:58:47.25 ID:qzEPJuIN - VBにはGCは使われていません。
|
- Git 12©2ch.net
492 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:00:00.11 ID:qzEPJuIN - > コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。
数秒で終わらないのが困るのなら、大量にあるコミットが
ある状態で、rebaseとかどうするのさ？
数秒で終わらないなら、逆にコミット減らすべきだろ。
矛盾してるぞｗ
あと中間ファイルが残ってるはずだから、
適切にソースコードが分割されて依存関係が少ないなら
一つ一つのコミットの修正が僅かなはずなので
コンパイルにそんなに時間がかかるはずがない。
|
- Git 12©2ch.net
493 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:05:10.63 ID:qzEPJuIN - > 昔のコミットや昔の挙動を残しておいても
> 問題調査の役に立つことが少ないとか
これも逆に不要なコミットは消すべきだよね。
何か勘違いしてる（他の人にされそう）だから
念の為に言っておくけど、俺が言ってるのは、
本来一つであるべきコミットは一つにするって話で
何でもかんでもまとめろって話じゃない。
だから当然、昔のコミットは残ってる。
調査に使うよ。git bisectで二分探索で。
でだ、この時大量にコミットがあるとその分探索の回数増えるわけで、
コンパイルと自動テストが数秒で終わらないとしたら大変だよなぁ？
問題調査のためにも無駄なコミット減らしたほうがいいって結論になるぜ？
|
- Git 12©2ch.net
495 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:30:23.27 ID:qzEPJuIN - >>494
rebaseって二つの複数の意味があるから気をつけないといけないなｗ
master(1)
＼A→B→C→D
で開発をはじめてさ、他の人のマージが先に加わった時、
master(1) → master(2)
＼A→B→C→D
master(2)からの開発にrebaseするという話。
master(1) → master(2)
＼A→B→C→D
この時、A〜Dまですべてが書き換わるわけだから、
コンパイルと自動テストをするわけでしょ？
時間がかかるのならなおのこと、まとめておいたほうがいいでしょ。
master(1) → master(2)
＼AC→B→D
もしかしてこのタイプのrebaseも禁止してるのかな？
なんか下手なコミットのせいで、時間が掛かるから便利なものを
封印せざるを得ない状態を作っているようにしか見えない。
|
- Git 12©2ch.net
497 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:50:55.88 ID:qzEPJuIN - もう一つ「もしかしてこのタイプのrebaseも禁止してるのかな？」
と思った理由もかいておく。
A, B, C, D が同じ箇所の修正（前のコミットのやり直し）をして
本来一つであるべきものが分かれていたとする。
そしてmaster(2)にrebaesしたときにAでコンフリクトが発生したとする
master(1) → master(2)
＼A→B→C→D
そうすると、B, C, D も同じ箇所の修正だから
必然的に、BでもCでもDでもコンフリクトが発生するわけよ。
わー、大変だ。コンフリクトだ。しかもこれさっき直したじゃないか？
コンフリクトわけわからん。わー。ってなってるはず。
同じ箇所の修正を一つにまとめておけば、コンフリクトの修正も一回だけだよ。
関連あるコミットをまとめておかないから、コンフリクトが沢山発生する。
時間かかるし正しく修正できたわからんからrebaseしない方がいい！ってなってると思う。
コミットが沢山にわかれている → コンフリクトが沢山発生する → そうなるからrebase禁止 と
考えているのだろうが、本当の原因はコミットが沢山にわかれていて、それが意味もない順番でごちゃごちゃ並んでることだから。
関連あるコミットは随時まとめておく。順番も適切な順番になおしておく。そうしておけばコンフリクトの発生は少ない。
コミットの数も少なくなるし、だからrebaseしてもコンパイルにも自動テストに時間はかからなくなる。
コミットは意味がある形で最小限に抑えられているから、レビューも楽になる。
後から問題の調査をするときも、存在理由がわからない大量の謎コミットを見る必要もなくなる。
gitの機能を最大限使うことが出来るわけよ。
ってもう何回も言ってるねｗ 毎回長文でｗ
|
- Git 12©2ch.net
498 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:54:58.15 ID:qzEPJuIN - >>496
> その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが
その場合ってどの場合？
一人で開発してるんじゃないんだよ。
自分が開発をし始めた時からコードは変わっているから
これをmaster(3)になんか出来ない。
他人の仕事を消してしまうじゃないか。
他人の仕事と自分の仕事を合わせてないと行けないんだよ。
コンフリクトが起きようと起きまいとね。
コミットが沢山あればあるだけ、全てのコミットが
正しく動くか再テストをする必要がある。
|
- Git 12©2ch.net
500 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:01:15.60 ID:qzEPJuIN - >>496
> このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
別ブランチにできるかどうかは内容次第だね。
コミットとしては一つ一つ取り込めたとしても
機能としては一つ一つでは完成しないこともある。
で、俺は一連の作業中に、先にマージ可能なものができたら、
別ブランチに抜き取って先にマージした方がいいとも書いた。
そのためにも、コミットをそのまま放置するのではなく
関連があるものはまとめていくようにって言ってるんだよ。
関連あるコミットがバラバラだったら、別のブランチに抜き出すのは大変だからね。
それもあって、そのケースでAとCをまとめたんだよ。
つまり最初のAとCが関係ある内容ならまとめますか？の質問の
答えはまとめた方がいいってこと。
で、これやるとコンフリクトが〜とかいって、まとめない方がいい
並び替えないほうがいいって言ってる人がいるわけよ。
|
- Git 12©2ch.net
501 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:05:27.02 ID:qzEPJuIN - >>499
> これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
> 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
話がループしているがｗ
rebase後にACとBのコンパイルと自動テストをスレばいいだけだろう？
そんなのすぐに終わる。たった2回（ACとB）じゃないか？
すぐに終わらないのは、コミットがたくさんあるからだよ。
そりゃコミットが10個も20個もあれば、10回20回もコンパイルと自動テストをしなきゃならんだろうさ。
コミットがたくさんあるために、rebaseを許さない状況になってしまっている。
rebaseってさ、gitの基本じゃん？
チュートリアルの最初のほうで出てくる作業だよ。
許されるも何もこれは普通にやるべきことだよ。
ね？ 下手なコミットのせいで普通にやることがやれない状況になってしまっている。
コミットがたくさんあるために、rebase（master(2)への付け替え）を
封印してしまってるでしょ？
|
- Git 12©2ch.net
504 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:28:53.73 ID:qzEPJuIN - > AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。
> AとBとDはブランチを分けるな。
分けたいなら後で分ければよくね？
作業用ブランチなんだからそれはどっちでもいい話だと思うが。
AとBとDがお互い前のコミットに依存している場合、
最初にブランチを分けておくと、ごちゃごちゃしてくると思うが。
Aを作ったはいいけれど本当にこれでいいかは、そのAを使う
Bを作らないとはっきりしないことだってあるしさ。
残念ながら人間はミスを犯すんで、どうしても後からバグを発見する。
後から修正をするものだよ。
一つのブランチで作業しておいて、ある程度納得がいったら別ブランチに
抜き出せばいいと思うけど。コミットが整理されていれば簡単な作業だし。
それとレビューは間違いを見つけるものだから、修正が入るのはあたりまえだよ。
レビュー中はまだ作業中段階。作業中のごみコミットを残したままマージする必要はないよ。
一連のレビューが終わったら整理すればいいだけの話。整理し終わってそこで完成。
|
- Git 12©2ch.net
505 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:30:22.13 ID:qzEPJuIN - >>503
> 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
そんなのすぐに終わらないって前提がおかしいんだよ。
だって開発中に何度もコミットしてるじゃん？
その段階でコンパイルと自動テストしてるじゃん？
コミットがたくさんあるのなら、その分だけやってるわけじゃん
開発中にすぐに終わらない作業を何回もやってるのか？
まずそれを解決した方がいいぞｗ
|
- Git 12©2ch.net
506 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:35:21.24 ID:qzEPJuIN - 補足すると、コンパイルがすぐに終わらないってのはおかしい。
なぜなら、コミットの前後で修正されるファイルは少しだから
該当ファイル以外のオブジェクトファイルはそのまま使えるわけで
差分のみのコンパイルしかしないはずだから。
そして自動テストは作業中は関連のあるところだけテストすれば良い。
で、最終段階（もう変更がないと思った時点）で全部やればいいんだよ。
最後にブランチ内の全コミットをテストするのか！という疑問に対しては
だからぁ、コミット数が多いから大変なんじゃねぇかそれ。という話。
関連あるものはまとめろ。先にマージできるのは別ブランチに分けろ。
コミットは小さく分けろ。だが無駄なコミットはまとめろ。
|