- Git 11©2ch.net
688 ：デフォルトの名無しさん[sage]：2015/03/01(日) 13:53:52.15 ID:odvvrg+G - >>683
検証できるもので語ろうよｗ
検証できない事だと嘘付いても調べようがないからね。
それを利用して、さも自分が知っている秘密の世界（笑）では
自分の都合のいいことが起きているという。
でも科学の世界では第三者が検証できなければ意見としてみなされない。
だから検証できるものを出すのが重要。
俺は出した。git本家のリポジトリだ。
君はなにか出したかね？ 信用される行動を取りましょう。
|
- Git 11©2ch.net
691 ：デフォルトの名無しさん[sage]：2015/03/01(日) 14:15:17.53 ID:odvvrg+G - >>690
立証方法は数でいいかな？
より多くのプロジェクトでやっているやり方が
より一般的である。
この定義は問題ないだろう。
今のところgitという例がひとつ出た。
反対意見のプロジェクトは0だから
今の所一般的なのはgit風である。
反対プロジェクトが出たら、また一つ探してくることにするよ。。
|
- Git 11©2ch.net
694 ：デフォルトの名無しさん[sage]：2015/03/01(日) 14:24:45.39 ID:odvvrg+G - >>692
じゃあ、検証可能でもっといい方法があったら
それに変更することにするよ。
それまでは、より多くのプロジェクト（誰でも検証可能なものに限る）で
使われている方が一般的という定義にしておくね。
あ、仮だから、仮。
文句ばかり言って、何もだいたい手段を言わない人を
黙らせるための仮の定義だからね〜。
|
- Git 11©2ch.net
699 ：デフォルトの名無しさん[sage]：2015/03/01(日) 14:36:18.63 ID:odvvrg+G - >>696
> commit直後に修正入れるようなみっともないことしないよう、ちゃんとデバッグしろということ？
コミットはこまめにやるべきだから、ちゃんとデバッグしなくてもいいというか
事実上できないよ。
その代わり、ちゃんとデバッグしてからmasterなり
他人に公開しているブランチにマージする。
こまめにやったコミットをデバッグして、
問題があったらもちろんrebaseして、
きれいなコミットにしてからマージする。
それがgitなどの多くのプロジェクトで極普通に行われている方法。
|
- Git 11©2ch.net
700 ：デフォルトの名無しさん[sage]：2015/03/01(日) 14:38:01.87 ID:odvvrg+G - >>698
それぞれの環境にあったやり方はあるだろう。
例えば、ソースコード管理をせずに
ソースコードに修正履歴のコメントを書く
という環境もあるだろう。
そういう環境があることを否定しているのではなく、
より良い環境とは何か？というのを
多くのプロジェクトをみて学びなさいということ。
|
- Git 11©2ch.net
710 ：デフォルトの名無しさん[sage]：2015/03/01(日) 21:33:37.81 ID:odvvrg+G - >>705
その例じゃわかりづらいだろｗ
まずmasterブランチがあるとする。
そのmasterを元にAさんがある機能を作るとする。
git checkout master // masterにいる
git checkout -b new_feature // 新しい機能作成
そのブランチで開発をする。
touch new_class && vi new_class
git add new_class
git commit -m 'add new_class' # new_classを作成
vi existing_class
git add existing_class
git commit -m 'improve existing_class' # 新機能追加のために、既存のexisting_classクラスを拡張
vi new_class
git add new_class
git commit -m 'fix new_class' # existing_classを書いている時に、new_classにバグや修正やタイポが発覚して修正した
git checkout master
git merge new_feature # 新機能をmasterにマージ
この時のmasterのコミット履歴がこんなふうになったってしょうがないってこと。
* Merge new_feature
- fix new_class (新クラス完成版）
- improve xisting_class (既存クラスの拡張）
- add new_class (バグがある新クラス）
|
- Git 11©2ch.net
711 ：デフォルトの名無しさん[sage]：2015/03/01(日) 21:34:46.93 ID:odvvrg+G - この例はまだ機能がまだ少ないからいいけど、例えば、2つのファイル修正。
2つのファイル作成で成り立つ機能を1週間かけて作る。コミットはこまめにする。
その1週間の作業で間違えることなく完璧に作業していればこれだけで良くなる。
new_featureブランチ（rebase版）
- add new_classB (新クラスBの追加）
- add new_classA (新クラスAの追加）
- improve existing_class2 (既存クラス2の拡張）
- improve existing_class1 (既存クラス1の拡張）
だが1週間かかるような仕事をミスせずにやれる人はいなし
理想的な順番で修正できる人も居ないので、作業履歴的にはこうなる。
new_featureブランチ（全部履歴残す版）
- fix existing_class1
- fix new_classB
- fix existing_class2
- fix new_classA
- fix new_classA
- fix existing_class1
- fix new_classB
- fix existing_class2
- fix new_classA
- fix existing_class1
- add new_classB (新クラスBの追加）※この時点ではバグあり
- fix new_classA
- fix existing_class1
- improve existing_class2 (既存クラス2の拡張）※この時点ではバグあり
- fix existing_class1
- add new_classA (新クラスAの追加）※この時点ではバグあり
- fix existing_class1
- improve existing_class1 (既存クラス1の拡張）※この時点ではバグあり
|
- Git 11©2ch.net
712 ：デフォルトの名無しさん[sage]：2015/03/01(日) 21:35:36.94 ID:odvvrg+G - new_featureブランチ（全部履歴残す版）をみて
他人が結局何をしたのか？なんて把握できるわけがないし、
squash等で全部まとめてみるという考えもあるがそうすると
new_featureブランチ（squash版）
- existing_class1 + existing_class2+ new_classA + new_classB (新クラスA,Bの追加と既存クラス1,2の修正）
diffの内容＝new_classBとnew_classA とexisting_class2とexisting_class1の
修正内容を一度に全部まとめてみることになる。
既存クラスの拡張が、単純な関数の追加だけならまだわかるけど、
それぞれいくつかの既存の関数の修正だと、
全部まとめてみると、二つの独立した機能拡張をまぜて見ないといけなくなる。
小さな修正を見るよりも、大きな修正を見るほうが大変なのは言うまでもない。
で、もちろん、new_featureブランチ（全部履歴残す版）のようなものをmasterに入れることはない。
入れると、git bisectで問題箇所を調べるときの障害にもなる。
（使ったことある？ 二分探索で自動的にコミットをチェックアウトしてバグを調べる機能）
ブランチの段階でプルリクエスト（レビュー依頼）する。
もちろんレビュー依頼をするときには、rebaseしておく。
そこでまた修正があるとしたら、途中もしくは最後にrebaseしてからマージ
有名なプロジェクトをみても途中の作業履歴が残っていないので
それが一般的であるとうことがわかる。
|
- Git 11©2ch.net
713 ：デフォルトの名無しさん[sage]：2015/03/01(日) 21:37:40.19 ID:odvvrg+G - >>707
> プログラムなんて完成させりゃいいのに、
> より完璧にバージョン管理する方法とか、手続きにとらわれすぎて可哀想。
その考えもわかるけど、それだとsquashするほうがまだましだだから
どちらにしろ履歴は残さないよ。
|
- Git 11©2ch.net
716 ：デフォルトの名無しさん[sage]：2015/03/01(日) 22:15:59.98 ID:odvvrg+G - >>714
まとめること自体は、rebaseだよ。
git rebase -i （編集を開始したいコミット）
ってやればエディタが表示される。
そこで順番を並び替えたり
まとめたりするものを選ぶだけ。
ただ、ここでコンフリクト起きたりすると
それを解消するのに時間がかかって本末転倒になるから、
コミットはほんとうに小さく分けてこまめに整理しながらやること。
あと大きな機能は小さな機能に分割してリリースすることだね。
ただしちゃんとした設計ができてないと、あとから大幅に変更することになって
最悪コードやレビューがムダになりかねないから、
小さな機能でもリリース（master等の共有ブランチにマージ）するなら
しっかり作りこまないといけない。
基本は小さく作ることだよ。そうすればコミットをまとめるのも楽になる。
|