Gitをより良くするための運用ガイドライン作成スレ

[表示 : 全て最新50 1-99 101- 201- 2ch.scのread.cgiへ]
Update time : 07/21 18:41 / Filesize : 109 KB / Number-of Response : 250
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:08.66 ID:5CuOmznL.net]: gitのコミットをより意味があるようにするためのガイドライン作成スレです。
なぜコミットはあるのか？コミットが残っていることで
何の役に立つのかをよく考えましょう。

そしてガイドラインを言う時は、ちゃんと理由も書きましょう。
上司が言ったから絶対なんだ！今までそれでやってきたからそれでいいんだ！
みたいなのは理由ではありません。
101 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:43:18.36 ID:QV1BHlUK.net]: >>98
--no-ffすればマージコミットになるのは当たり前だし、
>>95ではffになったらって前提でマージコミットにはならないって言ってるし、
>>90ではffマージもあり得る話としているから、イマイチgitの仕組みを理解してない人なのか、github前提で話をしている人なのかの区別が付かなかったんだ。

今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
それともgithubのpull requestの運用だと--no-ffを原則にしなくても問題ないの？
102 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 02:44:17.56 ID:In84evFv.net]: githubのpull requestの運用だと--no-ff勝手につけてくれるな
103 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 12:14:12.79 ID:tnRZvA/G.net]: >>101
> 今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
いつも思うんだけど、単純なルールを欲しがるよね。

関係ないけど、ちょうどこんな記事を読んだんだよ。

アジャイルの破綻―原因、そして新たな提案
postd.cc/the-failure-of-agile/

> あなたが新しいプログラミング言語や技術、または開発手法などの新しいスキルを初めて学ぼうとする時、
> 経験やメンタルモデル、”調査と順応”といった抽象概念に対応する能力を持ち合わせていません。
> これらの能力は、より経験を重ねた熟練者だけが持ち合わせているものです
>
> 初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。
> 例えば、「これが起こったら、あれをする」といったようなルールです。
> ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、
> 初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、
> 凝り固まったやり方になってしまいます。

何も考えたくないから、簡単なルールを求める。
そうじゃなくてちゃんと考えようよ。

俺は「マージするときは必ず--no-ffをつける」なんて言ってないからね？
まず一つ「masterへのマージ」と言った。そして「原則として」と言った。

原則として
www.weblio.jp/content/%E5%8E%9F%E5%89%87%E3%81%A8%E3%81%97%E3%81%A6
> 例外が許容される場合があるという意味合いを含むことがある。

殆どの場合masterのへのマージは--no-ffになっており、それを参考にしろという話
何にでも例外はあって>>94はその例外。その例外を持って来られても
大半のmasterへの、”masterへの” マージは--no-ffになってるんだから、それ見ればわかるでしょ。
104 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 12:19:15.57 ID:tnRZvA/G.net]: >>102
> githubのpull requestの運用だと--no-ff勝手につけてくれるな

そうなんだよね。基本的にmasterへのマージは--no-ffになるから
そんなの基本的な話だと思っていた。

そしたら、masterへのマージでffになる例を持って来られたから、
今さら（masterへのマージに）--no-ffをルールにすべきか？
って話をせざるを得なくなったんだよ。>>101

俺としては当たり前すぎの話だったので省略してしまった部分。
105 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 14:47:21.91 ID:pO7+dMQJ.net]: うん、やっぱりgithub前提なんだね。
masterへのマージは--no-ffが基本だと思ってるってことは、masterへはrebase+ffで変更を取り込まない方が良いって思ってるってことだ。
それは何でだ？
106 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 14:58:19.81 ID:pO7+dMQJ.net]: githubを前提にしないでコマンドラインだけで運用した場合は、マージコミットが増えることはログの煩雑化を進める気がする。
やっぱり、運用ガイドラインにはgitをサポートするツールに何を使用するか、というのも条件に含めないといけないと思う。
107 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:28:49.04 ID:rhusAjzF.net]: >>105
github前提でもなんでもなくて、一般的な話だよ。
理由もそこに書いてあるとおり。

どうやら俺が説明すると、それは変なやり方だって思い込んでるのか
いちいち調べもせずに絡んできてるようだから、他人が説明した理由を紹介することにする

keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html
> --no-ff フラグは、たとえマージがfast-forwardで実行できるとしても、
> 新しいコミットオブジェクトを作成する。これは、履歴にフィーチャーブランチが
> 存在したという情報を失うのを避けるのと、機能の追加に使った全ての
> コミットをひとまとめにしておける。比べてみよう：

> 右の場合、ある機能を実装したコミットオブジェクトをGitの履歴から見つけられない
> ――あなたは全てのコミットログメッセージを手動で見なければならなくなるだろう。
> 機能の全て（例えば、一連のコミット）を revert しなきゃいけないなら、右の状況では
> 本当に頭を痛くさせる。だがもし --no-ff フラグを使用したなら、簡単に終わるのだ。
>
> 確かに、これだとより多くの（空の）コミットオブジェクトを作成するはめになるが、
> そこから得られるものはコストよりずっと大きい。
108 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:37:06.02 ID:pO7+dMQJ.net]: これは、git flowモデル前提だね
109 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 17:58:50.29 ID:pO7+dMQJ.net]: で、マージコミットでコミットを纏めるって考えは、コミットを意味のある単位で纏めるって話と繋がっていて、
githubなどのオープンソース開発モデルだと、マージコミットをpull request単位に出来て相性が良いと思うんだよね。
じゃあ、常にこのモデルが優れてるかという点については議論の価値があると思う。
4、5人の少人数開発で一つの意味あるコミットの大きさが小さい開発の場合は、コミット一つにつき一つのマージコミットが出来てそのログに書かれた内容が同じってことになる。
だったら、せっかく一つ一つのコミットを読み易く分割してるんだから、rebaseモデルで、masterを出来るだけ一本線に保つという考え方の方が、bisectが有効に働きやすいというようなことがあるかもしれない。
110 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 19:45:56.09 ID:2dhAz4DT.net]: gitのgitを見ると、ブランチをマージしたってコミットはたくさんあるけど
普通のマージコミットみたいに、ブランチの中にあったはずのコミットはログに出てないね
すっきりしてていいから真似したいんだけど、--no-ff使って作ったもんなのかな
111 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 20:02:32.79 ID:rhusAjzF.net]: >>108
> これは、git flowモデル前提だね

どこに書いてるのさｗ

「git flowモデル前提と知っている」ということなら
「git flowモデル以外では違うと知っている」はず。

ならば、違うフローでは、--no-ffをつけていないということを
具体例を上げて示すべきでは？
112 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 23:17:41.64 ID:pO7+dMQJ.net]: >>110
これがgithubの機能として当たり前なのかどうかが分からないんだよね。
例えば、gitのコミットログをsourcetreeで見ると、とんでもなく並行してブランチが存在するように見える。
もし、sourcetreeのようにしかログを参照してなかッタトしたら、もっとブランチの分岐点を制御する運用にしようと考えるんじゃないかな？
113 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 23:52:06.93 ID:pO7+dMQJ.net]: >>111
A successful Git branching modelのことを、git flowモデルとも言うんじゃないの？
danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html

このモデルでも--no-ffを原則にしてるから一般的なんだということをしめしたかったのかと思ったんだけど。

--no-ffを使わない、というgit運用モデルがあるかどうかは知らないなあ。
と、いうより、githubとgit flowのモデル以外に明文化されたgit運用モデルを知らない。

rebaseを主体としてmasterを出来るだけシンプルに保つ運用モデルがあっても良いとは思うんだけど、ちょっと調べた限りでは見つからなかった。

他にも知っているモデルがあったら、>>107のように紹介してくれたら有り難いんだけど。
114 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 10:55:14.55 ID:l25RfAPf.net]: 勘違いしてたんだけど、git自体が使用しているワークフローとgithubが想定しているワークフローとgithub flowというワークフローは全部違うみたいだね。

・git開発のワークフロー
daretoku-unix.blogspot.jp/2014/01/git-flowgithub-flowgit.html?m=1
・github flow
https://gist.github.com/Gab-km/3705015

githubがどんなワークフローを想定しているかは見つかってないんだけど、github flowがgithubの機能をシンプルに使って、みたいな感じで書いているから、github自体はgit自体と同様に特にワークフローを定義せずに利用者に任せるスタンスなのかもしれない。
115 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 12:35:00.39 ID:Y0tcUgcD.net]: masterへのマージで--no-ffをつけるって、githubフローの話だっただろ？

>>113
それをgit flowというのなら、githubフローとgit flowの
両方共、masterへのマージで--no-ffをつけるってことだ。

補足すると、gitlabでもmasterへのマージで--no-ffをつける

これで、git flow、github flow、gitlab flowの三つとも
masterへのマージで--no-ffをつけるということがわかった。

つけないものはあるのか？
116 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 13:44:56.64 ID:l25RfAPf.net]: >>115
>>114で貼ったgit自身の開発モデルでは--no-ffは付けないみたいだね。
gitworkflowにも書いてないし、gitのmasterブランチにもmergeコミットではないコミットも含まれている。
例えば、0e8771fなんてffされたmergeに見えないか？

そもそもpatchで取り込むことも想定されてるから、mergeの時だけ--no-ffを前提にすることは無意味だと思う。
117 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 19:05:48.16 ID:RaZQIMSq.net]: gitをより良くするのは諦めたのか
118 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 19:10:42.34 ID:FzphauAa.net]: スレタイは
Gitをより良く使うための～
にするべきだったな
119 名前：デフォルトの名無しさん mailto:sage [2015/06/19(金) 23:37:29.06 ID:RaZQIMSq.net]: >>11で終わってたな
120 名前：デフォルトの名無しさん mailto:sage [2015/06/20(土) 12:58:37.97 ID:Z2ENSL80.net]: ぶっちゃけコミットログを綺麗にするのって
綺麗にするために払う時間コストに比べたらどうでもよくね？
121 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 21:45:19.09 ID:1BopKhVm.net]: コミットログメッセージの書き方についての話題が無いけど、>>1的にはどうなの？
ルールや提案、アドバイスなんか無いの？
122 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 06:34:11.93 ID:hmqK9V2H.net]: そういえばコミットログは暗黙の了解な書き方があったね。
1行目：題名
2行目：空行
3行目以降：詳細説明

format-patchすると1行目から空行までを切り取られてSubjectにされるので
空行を入れずにたくさん書くと、なかなか面倒な事になった。
123 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 07:56:37.13 ID:Jo3Uu3lv.net]: x 暗黙の了解

o プロトコル
124 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 21:37:10.67 ID:aUxHdKYd.net]: 問題となるのはタイトル文。

アプリを作っているのなら、開発者ではなくそのアプリを主語にした文を書くという流儀があるね。
（ただし、主語そのものは省略する）

開発者がやったことではなく、アプリができるようになったこと、とか。
125 名前：デフォルトの名無しさん [2015/06/30(火) 06:51:11.57 ID:vdY22gQv.net]: 運用のスレができたのはいいことだがわしには難しすぎる

とりあえず、テストのことを考えてみた。
こういうガイドラインはどうかな？

・どのコミットもコンパイル & 実行可能であることが好ましい
126 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 08:12:45.77 ID:SNIIX8MT.net]: どのコミットもコンパイル可能であることを保つと、rebaseやcherry-pickに制限が発生する気がするな。
あと、コミットを分かりやすい単位で分割する、とい指針と矛盾するときもあると思う。
・コンパイルが通らなくても構わないコミットを他と区別つくようにする
例えば、コミットA～Dは変更内容の分かりやすさのために分割しているが、順序入れ替えや途中適用が出来ないことを示す記法を使用するとか。
127 名前：デフォルトの名無しさん [2015/07/01(水) 11:32:57.36 ID:5x1pwjnr.net]: >>126
なるほどにゃぁ
128 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 12:47:28.53 ID:osw3K43k.net]: >>126
それはコミット同士の依存関係であってコンパイル可能かどうかとは関係ない。
A>B>Cという歴史があってBで実装された関数をCで使っているのなら
コンパイル不能なコミットを許可したとしても問題は解決できない。

コンパイル可能なコミットにする事というのは
A
A>B
A>B>C
各歴史のHEADでコンパイルできる状態になっていますという事だよ。
129 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 13:50:55.44 ID:E0yPgYN2.net]: ごめん、何を言いたいかわからない。
各コミットをコンパイル可能にしておくのも、結構難しいって問題を出したつもりだけど、そっちが問題と考えてるのは何？
130 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 15:32:42.97 ID:ok9JQHnv.net]: コンパイルが通らないバージョンがコミットされてるなんて、気持ち悪くて嫌だ。
131 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 16:33:20.96 ID:WrSpGcQO.net]: 気持ち悪いのは主観
作業用ブランチなら好きにしなはれ
132 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 18:11:07.44 ID:ok9JQHnv.net]: そっか、ビルド可能（あるいはテストパス）を区切りにしない人もいるんだ。
133 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 18:15:48.22 ID:ok9JQHnv.net]: というか、前回コンパイル可能から再びコンパイル可能までに書くコード量が違うのかな？
あるいは、ビルドにめっちゃ時間がかかるから、頻繁にビルドできないとかなのかな。
134 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 20:55:57.02 ID:osw3K43k.net]: >>129
コンパイル、実行可能にしておくのは当たり前で、そういうのは理由にならないって事

全てのコミットがコンパイル可能になっていなければgit bisectが使えない
実際gitのソースコードでもv2.4.5からHEAD~1500くらいまで
全部コンパイルしてもコンパイルエラーになることはない。

git bisectみたいにgitの機能として実装されているのだから
gitを使う人にとっては全てのコミットをコンパイル、実行可能にしておくのは
当たり前で、難しいことではないという認識なんだよ。
135 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 21:01:43.98 ID:uCElgjag.net]: developmentブランチ的な共有品に、ビルドすらコケるようなのを上げるのは
人の仕事を止めるから考えるまでもなく当然ダメだろう
136 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 22:49:22.90 ID:E0yPgYN2.net]: >>134
だから、何の理由にならないかって所を聞いてるんだけど？
共有ブランチ上のどのコミットに着目してもコンパイル可能であるべきで、それは分かりやすいコミット分割に優先するって話かな？
つまり、コンパイル不能な途中経過をコミットするぐらいならsquashした方がマシ、と。
137 名前：デフォルトの名無しさん mailto:sage [2015/07/01(水) 23:06:27.57 ID:E0yPgYN2.net]: >>135
例えば、mater→A→B→Cというコミットのあるブランチをpull request受けた場合、マージする側はA,Bのそれぞれでコンパイル確認をしてからマージするべきだと思うかい？
それともCまでか？または、マージコミットに対してだけで良いと思うか？
自動実行テストがある場合はどうだ、それぞれで実施すべきか？
138 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 00:32:21.77 ID:BOecX6fF.net]: >>136
だから履歴を遡っての問題分析を難しくしてしまうのと
git bisectが使えなくなるのが問題。
コンパイル実行可能なのもコミットのわかり易さもどっちも必須条件
コンパイル出来ないけど分かりやすいって具体的にどんな例？
オープンソースのリポジトリにそんな例ある？
139 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 03:31:37.55 ID:hbh5BBnI.net]: SVNかなんかと勘違いしてないか
140 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 06:44:16.55 ID:H40fLBlj.net]: 日時ビルドでコケましたってのが事故としてはありえても
それを理由に、開き直って機能しないってわかってるブランチpull requestしていいことにはならんだろ
発覚した時点で最優先でに修正することになるだろうし
141 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 18:30:32.56 ID:eJl3FSc8.net]: revertでもresetでもなんでもいいんだけど、変更を破棄したくなったときに、どのcommitが
コンパイル可能なものなのかわからんという状況は困らないのかな。
142 名前：デフォルトの名無しさん [2015/07/02(木) 19:13:17.37 ID:bMzAU0w9.net]: commitにコンパイル禁止と書いて桶
143 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 20:35:15.89 ID:E2OQ2sTs.net]: >>138
オープンソースの例ではないが、業務上でありそうなものとしてはモジュール毎に担当者が決まっていて
1) 共通APIに機能を追加するために引数追加
2) それを使用している他のモジュールで引数追加に対応
で、1と2で担当者が違うから別々のコミットにしたい場合とか。
144 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 20:48:20.71 ID:E2OQ2sTs.net]: merge --no-ff必須にしておけば、mergeコミットは必ずコンパイルもテストも通る、って運用は可能だと思う。
pushする前にはコンパイル確認必須、とした場合も、masterブランチにコンパイル不可なコミットが混ざる可能性があるが、動作保証を自動テストで担保している場合はそれほど困らないんじゃないかな？
テストの方は全コミットで動作保証できることを期待してないだろうし、コンパイルに通らない事はテストに失敗したとみなせば同じ事だし。
145 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 21:08:43.42 ID:BOecX6fF.net]: >>143
ないな。新しいAPIを追加して前のものは残す。
新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。
そんなガチガチの縦割り組織ならリポジトリも別にするべきだ。

>>144
そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
過去バージョンのアップデートリリースが作りにくくなる。
146 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 21:57:29.71 ID:E2OQ2sTs.net]: >>145
>>>143
>ないな。新しいAPIを追加して前のものは残す。
>新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。

各コミットのコンパイル可能を保証するために、その手順を踏むことが望ましいという主張だね。
俺だったら引数追加するたびにAPI名を変更するぐらいなら、squashでまとめるか、常にコンパイル可能を諦める方を選ぶな。
147 名前：デフォルトの名無しさん mailto:sage [2015/07/02(木) 22:01:33.42 ID:E2OQ2sTs.net]: >>144
>そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。
cherry-pickが完全に取り込めるかは、そのときのHEADがコンパイル可能かどうかとは関係ないよね。
新APIを追加するコミット無しに、新APIを使うコミットは適用しても、コンパイル出来ないよ。
148 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 00:27:07.02 ID:9/hHKZ1h.net]: >>147
cherry-pickの結果コンパイルは出来なくても意味のない単位で分割するよりは
必要な修正がまとまっている分、不完全なものになる可能性はずっと低くなる
例えば、Aに前処理とBに本処理がコミットが分かれていて
Bのみを拾った場合、理解不能な挙動をを起こすことになる。
コンパイルエラーになるならまだ良いほうで、
偶然コンパイルが通った場合は余計なデバッグに時間を費やすことになる。
149 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 08:59:41.32 ID:DfE7bDzR.net]: いやだから、cherry-pickの結果、コンパイル通らなくても構わないのであれば、そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても、意味のある単位で分割されてれば阻害要因にならないよね。
>>143の例のようなモジュール単位でコミットを分ける、というのも意味のある分かりやすい単位だけど、複数のコミットの一部しか適用していない状態だと全体のコンパイルが通らないという弊害がある。
ガイドラインとして、それを許容するか否か、ということが論点のつもりだけど。
また、それを許容しない場合は、rebaseしたときに、手を入れた各コミットの段階ごとにコンパイル確認が必要になる。
全コミットでコンパイル保証をするというのは、その手間を払う価値があるか否か、というのも論点になる。
150 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 09:11:49.14 ID:OZHQEleK.net]: >>146
+1
151 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 09:33:38.89 ID:AYyF2a3j.net]: Gitではコミットって、見せる前にちぎってくっつけて書き換えるもんだから
粒度小さければ後はどうでもいいよな
SVN時代のコミットの話は、動かないブランチをメインにマージしていいか？のほうが近そう
152 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 10:45:33.74 ID:DfE7bDzR.net]: >>149
>そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても

誤解を招く表現な気がしたので訂正。

>そのコミットを指定してcheckoutしたときにコンパイルが通らないとしても
153 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 10:55:08.66 ID:9/hHKZ1h.net]: >>149
意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
これは阻害要因じゃないのか？
rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
そんなに手間だろうか？
154 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 11:57:45.03 ID:bMlB0lVi.net]: >>153
多分、bisectは使ったことないから実感ないんだと思うよ。
逆の視点で言えば、全てのcommitが意味ある単位でビルド可能で、望ましくはテストOKなら、
gitの恩恵の全てを受けることができると言える。
155 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 12:43:03.22 ID:DfE7bDzR.net]: >>153
>意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。
>これは阻害要因じゃないのか？

確かにbisect使ったことないけど、コンパイル出来ないと何が困るの？
そのコミットをskipするなり、無視するスクリプトにするなり出来そうだけど。
git bisectのマニュアルにはその例が載ってるよね。

www8.atwiki.jp/_pub/git_jp/git-manual-jp/Documentation/git-bisect.html

>rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。
>そんなに手間だろうか？

ごめん、こっちは全然分からない。
bisectは二分探索だと思ってたけど、ある範囲のコミットを全チェックすることも出来るの？
そして実際にそうすることをガイドラインに組み込むべきだと思う？
156 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 13:15:10.09 ID:bMlB0lVi.net]: gitのpost-commit hookは使ってないのかな？
各コミットが、少なくともビルド可能であることを条件にしとくと、post-commit hookも
利用価値が出てくるのでは。
157 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 14:34:13.11 ID:DfE7bDzR.net]: >>154
post-commit hookで何をしたいのかな？
コンパイル確認じゃないよね？
158 名前：デフォルトの名無しさん [2015/07/03(金) 15:13:32.77 ID:Z21jSVmf.net]: コンパイルできなかったものはスルーすれば良いだけだよね
どうみても
159 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 15:33:27.81 ID:bMlB0lVi.net]: >>157
> post-commit hookで何をしたいのかな？
それは、post commit hookなんか、誰にとっても不要だって言いたいのかな？
160 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 15:35:16.28 ID:bMlB0lVi.net]: >>158
> コンパイルできなかったものはスルーすれば良いだけだよね
> どうみても
意図しないエラーと、そうでないものを区別できないよね。
自動的に何かをするときは、意図しないものを検知したいときがほとんど。

クリーンビルドしても問題がないかとか、全テストを実行するとか、静的解析をするとか。
161 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 15:46:36.46 ID:DfE7bDzR.net]: >>159
いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど？
まさか、post-commit hookでコンパイル確認させるつもりじゃないよね？
162 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 15:54:21.39 ID:bMlB0lVi.net]: >>161
> いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど？
post-commit hookの前提が、
・ビルド可能かどうかもわからないもの
・ビルド可能なのが前提
・ビルド可能だし、テストもパスしているのが前提
それぞれで、できることが違うよね。
163 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 15:57:46.77 ID:bMlB0lVi.net]: それと、コミットが、
・ビルド可能なのが前提
・ビルド可能だし、テストもパスしているのが前提
にすると、pre-commit hookでやれることもでてくる。
164 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 16:21:58.51 ID:9/hHKZ1h.net]: >>155
スキップは例外的にコンパイルエラーが出てしまう場合にも
bisectを継続できるようにするための機能であって、常時使うような方法じゃないよ。
コンパイルエラーでスキップしたコミットがあると、当然中身はテストされないので
正確なエラー発生位置がわからなくなってしまう。
結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。

bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
した事にすればいい。結果的に全部のコミットがコンパイルされる。
git bisect run sh -c ‘make; exit 125’
勢いで簡単にできるように書いてしまったが、本来の使い方じゃないね。
165 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 16:28:38.11 ID:DfE7bDzR.net]: >>162
だから、何をやらせようとしてるんだよ。
commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。前提を満たすかどうかのチェックをさせるならまだ分かるけど、それにしたって0.1秒以内に終わる程度の処理しかさせたくないな。
166 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 16:44:04.07 ID:bMlB0lVi.net]: >>165
> だから、何をやらせようとしてるんだよ。
別に何をやってもいいと思うけど。

ローカルな開発環境で、マニュアルで実行していることや、各種タスクランナーにやらせてるようなことを、
commitをhookして自動実行させるのが目的。

> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
ひょっとして、数分に一回くらいの頻度でコミットしてるのかな？
1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。

> そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。
前提があるからやる意味がある。

「ビルド可能」なことが前提だとしたら、ビルドをやらせて本当にビルド可能なことをチェックするのも良い。
ローカルな開発環境ではビルドできたけど、リポジトリから取得してビルドするとビルドできないなんて
間抜けなことがなくなる（そして、これはたまに発生する）。

「テストをパスすること」が前提なら、テストを実行させるのも良い。
これも、ローカルな開発環境だとパスするが、そうでないとエラーになるとかありがち。
167 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 16:44:05.36 ID:DfE7bDzR.net]: >>164
>結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、
>コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。

そこが、bisectの経験が無くて分からないんだけど、bisectの結果、最後にコンパイル出来てテストも通るコミットと、その次のコンパイル出来てテストに通らないコミット位置が分かるんじゃないの？
その間にあるコミットはコンパイルは出来ないかもしれないけど、分かりやすい単位で分割されているから、バグを特定しやすい気がするんだけど。

>bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ
>した事にすればいい。結果的に全部のコミットがコンパイルされる。

なるほど、こちらはためになった。
全スキップさせれば、全探索になるのか。
168 名前：デフォルトの名無しさん mailto:sage [2015/07/03(金) 16:51:48.49 ID:DfE7bDzR.net]: >>166
>> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。
>ひょっとして、数分に一回くらいの頻度でコミットしてるのかな？

作業中は数分間隔でコミットするね。
1日に均しても数回だろうけど。

>1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。

1日数回なら、commit hookに任せずに、自分でコマンド叩くよ。
commitの度に自動ビルド、自動テストなんて、こっちの環境じゃとても耐えられない。
ガイドラインの前提には出来ないな。
169 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 10:16:17.26 ID:XRnm36kK.net]: hoge-commmit hookが自分にとって役に立たないものかどうかと、commitはビルド可能な
ものにしたほうがいいかどうかは別問題。
170 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 12:16:46.31 ID:xERthjiE.net]: >別問題
の後の続きを書かないと主張が分からん
171 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 13:19:51.86 ID:XRnm36kK.net]: 普通に開発してると、ビルドOKかテストOKが作業の区切りになって、そのときコミットするから、
ビルド不可なものをコミットする人の気持ちもわからないし、デメリットもわからない。

ただ一つ言えるのは、俺はローカルリポジトリのcommit hookは使ってないが、それでも
ビルドが通らないものをコミットしようとは思わない。

普通に考えると、ローカルであれこれやりたいときに、どれがちょうど区切りがいいのかわからん
状態だと、作業に支障がありそうだと思う。
172 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 16:14:45.97 ID:xERthjiE.net]: commit hookと関係なくビルド不可なコミットを行うケースが想定できないって主張ね。

元々全てのコミットをビルド可能にするかどうかは、最終的に共有ブランチ上に残るコミットについての話だから、個々人が一時的にビルド不可なコミットを行おうがどうでも良かったんだよね。
ただし、commit hookにてビルド可能かどうかを確認することになると、個々人の作業ブランチが影響を受けるから、ガイドラインにするには適当じゃないと考えてる。

作業ブランチ上でビルド不可かも知れないコミットを作る例として、
・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース
・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース
・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース
・家に帰るので、念のためコミットしておくケース
とかが、あった。

上にも書いたように、この状況は最終的にrebaseで解消されるから、
・分かりやすいコミット分割とコミット毎のコンパイル保障/試験動作保障が両立できない場合にどうするべきか？
という、当初の議題とは関係無いんだ。
173 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 16:58:12.27 ID:XRnm36kK.net]: >>172
俺の感覚だと、

> ・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース
いや、stashしろよ

> ・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース
特殊ケースだね

> ・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース
差分ビルドできない言語は特殊ケース

> ・家に帰るので、念のためコミットしておくケース
意味がわからない

IDEがgitと統合されてるか、コマンドラインで開発するけど、ビルド・実行可というのが、俺の考える普通。
174 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 17:00:43.60 ID:XRnm36kK.net]: TDDは確信を得ながら開発を進めていく手法なんだけど、ローカルのcommitが全てビルド可能
（またはテストOK）にしながら開発を進めるのも、同じようなメンタリティな気がする。

俺がローカルであろうと「壊れたcommit」をしたくないのは、そういうことかもしれない。
175 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 17:16:13.76 ID:xERthjiE.net]: >>174
別にそのメンタリティを否定するわけじゃ無いけど、gitの運用ガイドラインに入れるわけにはいかんよね。
gitはビルドに時間が掛かる言語では使うな、ってわけにはいかんでしょ。
176 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 17:18:07.15 ID:xERthjiE.net]: >>174
ちなみに、TDDで通らないテストの時点ではまだコミットしない？
177 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 17:31:46.58 ID:XRnm36kK.net]: >>176
> ちなみに、TDDで通らないテストの時点ではまだコミットしない？
俺がやってるのはTDD的なものなんだけど、コードと前後してテストを書く場合は、テストが通らないと
commitはしないよ。
というか、テストが通らないコードのcommitに、なんの意味があるのかわからない・・・。
178 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 18:26:20.10 ID:xERthjiE.net]: いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。
つまり、コミットするときは、すべてのテストが通ってからなのかな？
俺とはコミット頻度がだいぶちがうね。
179 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 21:31:12.57 ID:mHUPaf2c.net]: >>177
便乗して俺も訊きたいんだが、そのコミット前のテストというのは、
単体テストのレベルのこと？
つまり、関数一つ作って、その関数の単体テストだけをして、
テストに通ってからコミットという話？
（当然、テストを作るのは関数を作る前だが）

それとも、今実装している機能に関係した部分の自動機能テストも通ってからコミットするの？

前者なら分かる、俺も同じだから。
180 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 01:02:07.10 ID:7aEyySce.net]: 公開するものはmake test相当のものをするだろう
https://docs.docker.com/project/create-pr/
https://nodejs.org/contribute/code_contributions/
フルテストとリベース、dockerの方はコミットをまとめろとまで書いてある
181 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 04:28:18.56 ID:FHtVzgus.net]: >>178
+1
182 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 10:11:12.92 ID:K0epweTJ.net]: >>178
> いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。
テストもその後リファクタリングするかもしれないから、テストだけ書いてcommitするというのはしない。

・テストを書く（コードが先の場合もある）
・コードをテストがパスするまで実装
・テストに改良点があれば改良する
・commit
という流れ。

百歩譲ってテストコードをcommitするとしても、TDDで言うRed->Greenの状態でcommitすると思う。
Redの状態でcommitする意義がわからない。

>> 179
> 便乗して俺も訊きたいんだが、そのコミット前のテストというのは、
> 単体テストのレベルのこと？
単体テストレベルというのがTDDのためのUnitTestという意味なら、それ以上のテスト（品質保証の
ためのテスト）もだいたい同時期に書くよ（網羅はしないけど）。
183 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 12:43:10.48 ID:bvFHzGSt.net]: >>182
>Redの状態でcommitする意義がわからない

commitをまとめるのは容易いけど、分割するのは大変だから、ちょこちょこcommitするようにしてる。
切りが良い時に、rebaseで整理する。
だから、コミットするタイミングでいちいち意義なんか求めないなぁ。
184 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 13:12:55.04 ID:K0epweTJ.net]: >>183
それ、逆に言うと、「テスト＋プロダクトコード」のひとかたまりのcommitを分割したいことがあるということ？
185 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 13:20:27.64 ID:K0epweTJ.net]: 例えば、blog.developwithpassion.com/2006/05/05/tdd-by-example-money/ の最初のコードで、
これは二つのケースが入ってるから最初に書くテストコードが

[TestFixture]
public class MoneyTest
{
　　[Test]
　　public void ShouldBeAbleToCreateMoney()
　　{
　　　　Money money = new Money(20.00);
　　　　Assert.AreEqual(20.00,money.Amount);
　　　　Assert.AreEqual(2000,money.Cents);
　　}
}

だったとする。
もちろん、これだとビルドできないけど、これをcommitしたくなるってこと？
186 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 15:16:24.29 ID:bvFHzGSt.net]: >>184
いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。
>>185
うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。
作業ブランチのコミット履歴は作業履歴も兼ねさせてるから。
187 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 15:28:22.05 ID:lQxKZL5c.net]: 正直いろいろ考えずに、トピックブランチをちゃんと細分化して
コミットはマージの時に--squashで叩き込めばそれでいい気がしてきた。
188 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 15:35:27.18 ID:K0epweTJ.net]: >>186
> いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。
俺の疑問もいまいち伝わってない気がする。
細かくcommitするのが疑問なんじゃなくて、TDDでいるRed状態でcommitしたいのが何故なのかということ。

> うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。
いけないとは言ってないよ。
なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。
どっちにしろ、あとでrebaseするのは確定なんだし。
189 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 15:55:20.52 ID:K0epweTJ.net]: 知らない人がいると思うのでTDDの説明をしておくと、Red -> Greenというのは
実装完了じゃなくて、テストがパスするためだけの仮実装完了状態。

>>185の例だと、
public class Money
{
　　public int Cents;
　　public double Amount

　　public Money(double amount)
　　{
　　　Amount = 20.0;
　　　Cents = 2000;
　　}
}
でGreen。
190 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 17:10:54.61 ID:bvFHzGSt.net]: >>188
>なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。
Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。

そもそもcommitするのを待った方がいい理由が分からない。
特にgit初心者に対してはbranchやcommitの概念に慣れさせる意味も込めて、頻繁なcommitとrebaseでも整理をさせた方が良いと思う。
191 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 18:10:53.70 ID:K0epweTJ.net]: >>190
> Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。
なんか繰り返しになるのでこのレスでこの流れを終わるけど、本当に定義できたかどうかは、
ビルドして実行するまでわからない。typoとかあるかもしれないし。

だから、俺的には、区切りがいいとは思えない。

> そもそもcommitするのを待った方がいい理由が分からない。
これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。

まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。
192 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 22:07:51.77 ID:bvFHzGSt.net]: >>191
>> そもそもcommitするのを待った方がいい理由が分からない。
>これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。

commitするのに意味が必要かどうか、って所が相違点な気がするから平行線だろうね。

>まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。
commitしちゃいけない、って意見では無くて、commitする意味が分からないって意見のようなんで、ガイドライン的には関係無さそうなんで、これで終わりでいいだろうね。

とにかく、元々の話はcommit hookで強制するかどうかの話なんだから、強制する気が無いなら、好きにすれば良いで終わる話だしね。
193 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 14:37:57.96 ID:5jcTfYer.net]: 読んでて思ったんだが、TDDやってない人は>>185のコードで一区切り付くと思うだろうけど、TDDやってると、
185のコードを書き始めてから数分以内に、テストコード編集・コンパイル・テスト実行・コード編集を頻繁に
繰り返すから、>>185じゃ全然区切りじゃないんだ。

まあ、ローカルcommitの粒度は、個々人がひとまとまりだと思う単位でってことにつきると思う。
開発スタイルやスキルによって、なにがひとかたまりなのかは人それぞれだってことで。
194 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 21:27:06.35 ID:9BfiFT/T.net]: TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ？
195 名前：デフォルトの名無しさん [2015/07/08(水) 21:31:23.47 ID:Y+kE74C9.net]: 人それぞれだってことで。
196 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 22:49:53.35 ID:uBhtmoLk.net]: 作ってすぐ実行する前提だからペアプロでも人が変わる余地はあまりないな
197 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 10:37:39.93 ID:SLWTmnwe.net]: >>194
> TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ？
TDDのテストコードは、プロダクトコードを書くための手段だから、同じ人がやるのが普通。
というか、違う人が書くなんて話を聞いたことがない。
198 名前：デフォルトの名無しさん [2015/07/09(木) 12:43:45.27 ID:Vp2Vvxuo.net]: 他人が書かないとかこの機能はどういう入出力あるかわかりましぇーんって言ってることと同意だぞ。
199 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 15:11:30.39 ID:w4uEPqNZ.net]: これも同じ人がテスト作っちゃってるし
https://github.com/git/git/commit/6a364ced497e407ab3ffb2554d4ef2c78f801832
文句言ってきたほうがいいと思うよ
200 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 18:20:13.62 ID:IBLBW75h.net]: >>199
なんでそんな事が分かる？
ローカルではテスト担当の幼女がやってるかもよ。
201 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 19:26:07.25 ID:w4uEPqNZ.net]: >>200
Signed-off-by: Karsten Blees <blees@dcon.de>
これはこのコードを寄贈しますという意味。
複数の人が関わっている場合はContributions-byで追記したりする。
最後のはJunioさんがgit am -sした時のもの。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef