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

1 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:08.66 ID:5CuOmznL.net] gitのコミットをより意味があるようにするためのガイドライン作成スレです。 なぜコミットはあるのか？ コミットが残っていることで 何の役に立つのかをよく考えましょう。 そしてガイドラインを言う時は、ちゃんと理由も書きましょう。 上司が言ったから絶対なんだ！今までそれでやってきたからそれでいいんだ！ みたいなのは理由ではありません。 75 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:43:40.24 ID:jf78czBd.net] >>67 すごく良い発言があるよ 「あなたの提案の内容に関してですが、 あなたの発言がキモいです。」 とか言ったら嘲笑ｗ だよなー でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」 だな 76 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:45:15.73 ID:ByqCHqi5.net] >>75 > でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」 わろたｗ ２ちゃんねるだからいいとして、 そんなの会社でやったら即刻クビだろｗ ホントこいつ発現する意味ないわーｗ 77 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:55:28.35 ID:d62hq9+6.net] >>74 おまえだれ？ 少し前に指摘したことさえ忘れたの？ 78 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:01:59.00 ID:ByqCHqi5.net] 少し前に指摘した人だってことをわかってるのに、 誰って聞いてるのはなんなんだろうなｗ そんなのどうでもいいだろう？ ここにはgitに関する意見を書けよ。 79 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:03:37.00 ID:l6qAkUnh.net] >>54 >動かないコミット 開発ブランチは分けろω 80 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:08:29.35 ID:d62hq9+6.net] >>79 こまめなコミットって意見あったけら言ったんだが 開発ブランチなら、動かないコミットも許す？ 開発ブランチは個人ごと？ローカルコミットだから人に迷惑はかけない？ マージしたら凄いゴミコミットの山では？ など疑問は多い 81 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:13:55.53 ID:ByqCHqi5.net] >>80 少しは考えたほうがいいよ。 なぜブランチはあるのか？ なぜ動く必要があるのか？ 開発ブランチは個人ごとである必要があるかないか 何をしたら人に迷惑で何が迷惑でないか 疑問があるのなら、他の人はどうやっているかを考えればいい。 世の中にサンプルはいくらでもある。 前にも答えたけどgit自体のリポジトリを見るとか。 有名プロジェクトであれば、そこがやっているやり方には 何かしらの理由がある。 疑問が多いってことは、その疑問に対して 自分で何も考えてない証拠だよ 82 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:15:57.16 ID:d62hq9+6.net] >>81 お前は黙っててくれるかな 83 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:16:43.89 ID:ByqCHqi5.net] >>82 いやです♪ 84 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:17:27.34 ID:ByqCHqi5.net] ちなみに>>80の疑問に関して言えば 俺は既に答えが出てる。 85 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 13:44:31.97 ID:ByqCHqi5.net] d62hq9+6はどうやら俺にレスして欲しくないようだし、 他の人の意見も聞きたいから>>80に答えるのは 明日ぐらいにしようかな。IDが変わってからｗ 86 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 15:53:01.11 ID:kgtEwFOS.net] >>34 githubの画面からはよく分からなかったから、ようやくcloneしたけど、mergeコミットと単なるコミットってどういう意味で呼び分けてるの？ 87 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 16:10:14.38 ID:eC56/Xbq.net] > mergeコミットと単なるコミットってどういう意味で呼び分けてるの？ 呼び分けるも何も、 マージコミットと単なるコミットは別物だけど？ https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%AE%E5%9F%BA%E6%9C%AC > 単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から > 新たなスナップショットを作成し、それを指す新しいコミットを自動作成します (図 3-17 を参照ください)。 > これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。 88 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 16:12:36.55 ID:eC56/Xbq.net] >>86 明らかに違うものとしてgitで管理されていることを示すために te2u.hatenablog.jp/entry/2015/03/24/233447 > この状態でrebaseを行うときに-iオプションだけでは > マージコミットは含まれない。マージコミットがあるときは > -pオプションをつけて実行すると > 指定した範囲のマージコミットが含まれる。 このように、rebase -iコマンドには マージコミットという特別なコミットを 含めるか含めないかのオプションが有る 89 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 20:28:40.57 ID:2Vz7+5/W.net] >>30で単なるコミットではなくマージコミットを見ろって言ってるじゃん。 普通の使い方なら、そもそもマージコミットで個別の修正はあり得ないよね？ 単なるコミット同士をマージしたものなんだから。 90 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 21:12:29.91 ID:eC56/Xbq.net] >>89 あぁ、その話か。 マージコミットには、どのコミットとどのコミットを マージしたのかって情報が含まれるんだよ。 「単なるコミット同士をマージしたもの」という言い方が、 何か意味を勘違いしている気がするが、コミットには歴史の情報も含まれている。 （つまりAとBコミット番号が同じなら、過去も同じであるということ） つまり、masterにbranch（のHEADのコミット）をマージするってことは、 マージコミットの中にはbranchの複数のコミット情報が含まれてることを意味する >>30で言ってる「マージコミットの中」というのは、 マージコミットでマージしたブランチの複数のコミットを見ろって話。 それはブランチのコミット内容を意味する。 人によってはmasterに直接コミットを追加することもあって マージコミットを使ってないコミットにはtypo修正とかあり得る。 （typo修正だけのブランチをffマージするのと同じ） だからこのコミットを見てもブランチが綺麗に整理されてマージしているってことに気がつかない。 マージコミットの中の複数のコミットを見ることで、ブランチに含まれる コミットは綺麗に整理してからマージされているってことがわかるって話。 91 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 12:22:13.27 ID:QV1BHlUK.net] やっぱり、マージコミットにはマージしたブランチの複数のコミットが含まれる、っていい方が分からんな。 githubは確かにそう見えるが、実際にはマージコミットは二つの親コミットをもつコミットだろう？ githubはpull request形式だから、マージ先ブランチとマージ元ブランチを明確に区別出来て、マージコミットをマージ元ブランチの複数のコミット、という意味に出来るのかな？ 92 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 12:25:00.72 ID:QV1BHlUK.net] まあ、要するに、単なるコミットっていうのは、githubのmasterブランチ上で表示されるマージコミットでないコミットってことね。 93 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 18:51:40.59 ID:Vn1MoMzT.net] >>91 今masterブランチの話をしてるんだよ？ マージ先ブランチはmasterで マージ元ブランチはmasterから枝分かれした ブランチであることは明らかでしょう？ master ↓ A │＼ branchA ↓ ↓ B　 a ↓ ↓ C　 b ↓ ↓ D　 c │／ ★ ↓ ： ★のマージコミットには、Dとcのコミットが記録されているだけだが、 cはbからの修正、bはaからの修正、aはAから枝分かれしたものって ことははっきりわかるんだから、★はmasterにbranchAを マージした結果できたものであると考えるのは自然でしょう？ 多分君がわかってないのは、★にはDとcというコミットが記録されているが、 それだけだ。cの前がbであるかどうかはわからないし、いつ枝分かれしたかも わからないって考えてるんじゃない？ そういうことはありえないよ。 94 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 19:09:32.17 ID:QV1BHlUK.net] ブランチ AのHEADがコミットcで、masterのHEADがコミットDのときに、ブランチAにmasterをマージする。マージコミット☆が出来る。 そのあと、masterがブランチAをマージすると、ffになってmasterのHEADが☆になる。 さて、このときマージコミットに含まれるコミットはa,b,cなのか？それともB,C,Dなのか？ 95 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 19:29:30.20 ID:Vn1MoMzT.net] ffになったらマージコミットはないよ？ 確実にマージコミットを作りたいなら （通常masterへのマージではマージコミットを作る。 なぜならマージしたという情報を残すため） --no-ffオプションを付ける 96 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 20:40:45.17 ID:QV1BHlUK.net] masterのHEADの☆はマージコミットだよ 97 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 20:46:14.81 ID:TKCLtNo1.net] >>95 +1 98 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 22:48:37.43 ID:Vn1MoMzT.net] >>96 言ったでしょう？ masterへのマージでは通常 --no-ffをつけるって。 だから>>94のような状態には通常ならないんだよ。 99 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:07:27.61 ID:tRPgSWCN.net] 相変わらずウルセーバカがいるな 100 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 23:27:33.58 ID:Vn1MoMzT.net] 運用ガイドラインの一つとして、masterへのマージは原則として --no-ffをつけるってのも必要かな。 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した時のもの。 202 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 19:57:50.51 ID:ymwHunw+.net] プログラムコードが文章で書いてるタイプの糞仕様書を作るくらいなら Spec作ってくれてるほうが意味はありそうだな 203 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 20:59:25.15 ID:IBLBW75h.net] >>201 幼女は名前を出したく無いのかもしれないし 204 名前：デフォルトの名無しさん mailto:sage [2015/07/09(木) 23:10:56.06 ID:w4uEPqNZ.net] このスレもうだめだな 205 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 00:05:50.44 ID:J6ZPTH7V.net] さすがにOSSで「俺テスト書いたから誰か実装して」ってのはないだろう。 206 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 11:38:16.56 ID:eTiXJwcJ.net] 普通のプロダクトでもないから 207 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 12:14:06.28 ID:0KQmgFVg.net] TDDでなければ良くあること 208 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 12:37:40.36 ID:eTiXJwcJ.net] >>207 君の周りでは良くあることかもしれないが、普通はそうないよ 大抵は、開発者自身による開発者テストと、開発者自身による後付けのテスト ところによっては、第三者による後付けのテスト これくらい 209 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 12:58:03.35 ID:rsWVLm23.net] 君の周りではそうないことかもしれないが、普通は良くあること。 210 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 12:59:10.97 ID:eTiXJwcJ.net] >>209 そういう手法でも、そうやってるというブログでもいいけど、いくつか引っ張ってみせろ 211 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 14:19:58.30 ID:0KQmgFVg.net] >>210 そうは言っても、別に興味はないんでしょう？ 誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。 gitはそういう使い方も許容するんだからさ。 212 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 14:38:11.38 ID:eTiXJwcJ.net] >>211 > 誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。 俺の周り：その他多数 じゃなくて、 君の周り：その他多数 だって認めてくれればそれでいいよ > gitはそういう使い方も許容するんだからさ。 ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな 213 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 17:43:45.37 ID:0KQmgFVg.net] >>212 >君の周り：その他多数 >だって認めてくれればそれでいいよ 認めるよ。 >> gitはそういう使い方も許容するんだからさ。 >ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな * B氏が実装を書いてブランチとして公開する * ソースコードレビューする * B氏が修正する * A氏がテストを書き、テストを実施する * B氏の修正を随時取り込む 運用ってほどじゃないな。 むしろ、なんでGITが特定の開発方法しか許容しないと思うのか？ 214 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 17:54:37.91 ID:eTiXJwcJ.net] >>213 それ、第三者による後付けのテストじゃん それはよくある 俺が、それはないって言ってるのは>>205 > 俺テスト書いたから誰か実装して 上の方でも、TDDで第三者がテスト書く的なこと言ってる奴もいたし 215 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 18:39:16.09 ID:0KQmgFVg.net] 第三者？登場人物は二人しか出てないけど。 まあ、TDDでなければよくある、って書いてあるんだけど、それは見落としてたわけね。 216 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 18:41:21.19 ID:eTiXJwcJ.net] >>215 自分以外の誰かは第三者じゃないんですか？ とかいうのはどうでもいいんだけど、 君が書いたのは「俺がコード書いたから誰かテスト書いて」ってことでしょ 俺がないって言ってるのは「俺がテスト書いたから誰かコード書いて」だ 違いわかんないの？ 217 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 18:55:25.64 ID:/TIw0VBH.net] >俺がテスト書いたから誰かコード書いて あるよ 218 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 19:35:38.61 ID:i0TWAaKD.net] コンパイルエラーくんのあたりから変な奴が増えたな、実際は一人かもしれないけど 事例を引用してこないのは無視した方がいいと思うぞ 219 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 19:50:33.80 ID:n6HS4jkV.net] >>213 俺がテスト書くから君が実装してね じゃダメかね？ 220 名前：デフォルトの名無しさん mailto:sage [2015/07/13(月) 10:31:31.19 ID:sRi+Sfog.net] >>219 > 俺がテスト書くから君が実装してね > じゃダメかね？ 実装する俺がテスト書くのが効率的、というのが普通。 それ以外には、テストを書くのもままならない初心者が実装する場合か、自動受け入れテストを 事前に書く場合くらいしか思いつかない。 221 名前：デフォルトの名無しさん mailto:sage [2015/12/24(木) 00:53:04.29 ID:VDgCwlJn.net] >>220 ちょっと横道だが… 実装した人間がテストを書くのが効率的なのは間違いないと思うけど、勘違いによる確率を下げるためには、実装した人間とは別の人間によるテストも有効だぞ 222 名前：デフォルトの名無しさん mailto:sage [2015/12/24(木) 10:27:35.59 ID:+bsSlAyH.net] >>221 この話は>>194から始まる「TDDでも他人がテスト書くこともある」という話で、そうする人が いるかもしれないが、普通はプロダクトコードを書いた人がTDDのテストを書く方が効率が いいという話。 223 名前：デフォルトの名無しさん [2016/01/09(土) 17:39:45.67 ID:QRpimApV.net] sourcetreeでgitを使っているんだけど、pullしようとすると if you trust this host, enter "y" to add the key to PuTTY's cache というメッセージが出て止まってしまう ここでyが押せればいいんだけど、SourceTreeはyを押してくれないので どうしたらよいでしょうか！ 224 名前：デフォルトの名無しさん mailto:sage [2016/01/11(月) 17:00:06.48 ID:I0GTrlSH.net] SSH の RSA Host key を自分で桶 225 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 20:57:49.79 ID:WOTwLsqM.net] 結局、GitってPull Requestをうまいこと実現するためのツールなんかな 226 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 10:29:52.37 ID:mkuLwhRZ.net] GitとGithubを混同してないか？ 227 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 19:15:50.35 ID:14BXXOjm.net] >>226 コードについてのレビューは一切やらず、マージも各自が勝手にやるって前提でGit動かしてたんだけどさ Pull Request的な承認フローを組み込まないなら、トピックブランチ切ったり、コミットを履歴いじって細かくまとめても、しんどいわりに対価がなんもないなあって masterなりdeveloptなりに、チケット番号書いたコミットを直に叩き込んでいったほうが、変に分離されてないから横断的な変更もやりやすいし 228 名前：デフォルトの名無しさん [2016/05/01(日) 14:36:36.34 ID:tKi6j9CT.net] 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？ Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません お 229 名前：デフォルトの名無しさん mailto:age [2016/09/25(日) 13:42:44.81 ID:0J+83ZC2.net] ge 230 名前：デフォルトの名無しさん [2017/10/24(火) 12:11:19.77 ID:QsylRaIJ.net] SourceTreeで、実行属性やパーミッションを確認する方法を教えてください 231 名前：デフォルトの名無しさん [2017/10/24(火) 17:59:49.42 ID:c4pQ4iLG.net] 右クリック 232 名前：デフォルトの名無しさん mailto:sega [2017/11/10(金) 11:08:50.86 ID:Au/LCYKx.net] プログラムの文字コードはEUC-JP でもコミットログはUTF8で書きたい というとき、どういう設定をすれば一番トラブルが少ない？ 233 名前：デフォルトの名無しさん [2017/11/11(土) 14:26:49.51 ID:ZUnF3Lay.net] なにもしない 234 名前：デフォルトの名無しさん [2017/12/30(土) 22:51:30.14 ID:DzO+KqCk.net] コンフリクトっていつ起きるんですか？ ・自分の作業ディレクトリに最新コミットをpullしてくる ・自分が作業して作業ディレクトリの内容が変わる ・誰かがリモートへその人のコミットをpushする。 ・自分がコミットしたいので先にpullする 　→誰かが進めたコミットがローカルブランチに反映される。 (このときにコンフリクト?) ・自分がpullしたのでaddする (このときにコンフリクト?) ・自分がaddしたのでコミットする (このときにコンフリクト?) ・自分がコミットしたのでプッシュする。 (このときにコンフリクト?) ・自分がプッシュ後念のため再度pullする 235 名前：デフォルトの名無しさん mailto:sage [2018/02/16(金) 06:39:41.43 ID:W1XJdyx1.net] ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が３分の２を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 236 名前：デフォルトの名無しさん [2018/05/23(水) 20:54:44.80 ID:Au5e7VGg.net] 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』 0DSS1 237 名前：デフォルトの名無しさん [2018/07/05(木) 00:59:07.23 ID:RfoszcD2.net] NNA 238 名前：デフォルトの名無しさん [2020/01/09(木) 20:23:33.80 ID:1uKbRjup.net] macbookのターミナルでgitにコマンド入力してるんだけど これってセーブとかしなくて良いの？ 良いとしたらどうしてですか？ 239 名前：238 [2020/01/09(木) 21:10:43.63 ID:1uKbRjup.net] 日本語が変だからやり直し macbookのターミナルにgitのコマンドを入力してますが、これってセーブとかしなくて大丈夫ですか？ 大丈夫な場合はどうしてですか？ 教えてください偉い人！ 240 名前：デフォルトの名無しさん mailto:sage [2020/01/10(金) 14:02:14.42 ID:t5T0L8NN.net] >>239 何をセーブする話です？ (エディタなどの)アプリケーションでのメモリー内での変更を、ファイルに保存するセーブなら、必要です。 アプリケーション内からgitコマンドを操作できるものは、gitコマンドを実行する前に自動でセーブされるはずです。 変更したファイルをリポジトリにセーブしなくていいのか？という意味ならcommitがセーブに相当します。 241 名前：デフォルトの名無しさん [2020/12/29(火) 01:12:42.70 ID:qxevuYQ38] 大学で学ぶ物理を板書１枚にまとめてみた https://www.youtube.com/watch?v=naBcXoq4aOI 物理の研究分野を板書１枚にまとめてみた https://www.youtube.com/watch?v=4W-pWuXUaZQ 理学部と工学部の違いとは？ https://www.youtube.com/watch?v=eJH4nKU6mJA&t=80s 大学と大学院の違い https://www.youtube.com/watch?v=xBKAEvTegN8 高校と大学の積分は決定的に違う？微分積分学の基本定理は実はすごい！ https://www.youtube.com/watch?v=V9i_zlbssbs&t=475s 数学にはどんな研究分野がある？数学の世界地図を一枚に描いて紹介してみた！ https://www.youtube.com/watch?v=fK_JGVti5y8 242 名前：デフォルトの名無しさん [2021/03/31(水) 18:08:33.14 ID:YXPC705mg] 2年間で23億円を調達。22歳の社長が語る“スタートアップ起業” https://superceo.jp/tokusyu/manga/100736 誰もがオリジナルアプリを作れる時代へ。スタートアップ支援に尽力してきた起業家の原動力とは https://fukuoka.startupnews.jp/post/nappstechnologies/ アプリの視聴率がわかる　高専卒起業家の独創力 https://www.nikkei.com/article/DGXMZO46695580Y9A620C1000000/ １万人の若者を支援！インターンが日本を変えるかも！？　glowshipの若き創業者・足立卓也氏インタビュー https://sogyotecho.jp/glowship-adachi-interview/ 起業で成功するキャリア形成の仕方とは？ 元プロサッカー選手で起業家の鈴木啓祐氏に聞いた https://sogyotecho.jp/career-development/ 年収3,000万超え!?個人開発で儲かっている海外コミュニティサイト5選！ https://note.com/taishikato/n/n7809a8ed3ffc 自分の視野は「世の中の0.001%」と自覚せよ。ビジネスチャンスを掴む4つの習慣 https://headlines.yahoo.co.jp/hl?a=20200511-00010001-srnijugo-life 人はこうすれば“ハマる”、源流はゲーマー視点の「幸せ」 https://project.nikkeibp.co.jp/behealth/atcl/feature/00005/012100006/ 243 名前：デフォルトの名無しさん mailto:sage [2021/07/22(木) 14:28:47.71 ID:9Ov2SxzN.net] gitを良くするためにはMicrosoftの関与をシャットアウトしないとダメ 244 名前：デフォルトの名無しさん [2022/03/18(金) 19:33:41.03 ID:smNc+iFX.net] du -sh .git どうして? 245 名前：デフォルトの名無しさん [2022/12/25(日) 16:05:51.51 ID:5e2c53xzU] しっかし世界最惡の腐敗利権組織自民党の覇権主義岸田文雄はよくもここまて゛白々しい寝言ほさ゛き続けられるよな ウクライナか゛攻撃されたのは軍事費ＧＤΡ比４％超でΝΑｔＯにまて゛加盟しようとして脅威視されたのが原因だろ 北朝鮮の軍拡は曰本に原爆落とした世界最悪のならず者國家らか゛かつてない頻度て゛軍事演習た゛なんた゛と挑發してるのか゛原因だし クソシナの台湾ヘの執着は元々同し゛国で自国民か゛大勢居住してるからだろ ウクラヰナも口シア民か゛大勢居住してるわけで．こうした事情を無視して日本が侵略されるから軍拡するぞだの飛躍にも程があるわ クソシナや口シアを非難する奴は．沖縄が独立宣言しても住民の意思だと賛成して自閉隊を送り込むとか当然反対するんだよな？ クソシナか゛どこぞの離れ小島て゛どうたらこうたらてめえらの生活に何の関係もねえだろ そんな離れ小島のために年間云兆圓もの税金を投入する価値があるとて゛も思ってるなら、思ってるやつから年云兆円徴収してやっとけ力ス 創価学會員は、何百万人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まて゛出てる世界最惡の殺人腐敗組織公明党を 池田センセ─か゛囗をきけて容認するとか本氣て゛思ってるとしたら侮辱にもほどか゛あるぞ！ ｈＴтρｓ：／／ｉ，ｉｍｇｕｒ，сｏｍ／hnli1ga.jpeg 246 名前：デフォルトの名無しさん [2023/07/15(土) 18:23:09.55 ID:bGpTfifD.net] .git-version が細かいトラブルの原因 うざい 247 名前：デフォルトの名無しさん [2023/11/06(月) 17:57:30.14 ID:j+54AM7Bx] 第ニのエ儿ピーダ確定の価格下落しまくり半導体の次はAIに税金2000億とか天下り税金泥棒無能公務員には反吐が出るな 世界最惡の脱炭素拒否テ囗国家に送られる化石賞連続受賞して世界中から非難されなか゛ら憲法13条2５条29条と公然と無視して力による━方的な 現状変更によってクソ航空機倍増、閑静な住宅地から都心まで数珠つなぎで鉄道の３0倍以上もの莫大な温室効果ガスまき散らして騒音まみれ 静音か゛生命線の知的産業壊滅させて天下り賄賂癒着してるナマポ集団NTтだの不治痛だのと税金泥棒のネ夕にしてるだけなのがバレハ゛レ ポンコツ技術後進国を脱却する気などサラサラないのはクソ航空機の陸域飛行禁止しないことからも明らかだろ 都心から離れすぎない地に飛行禁止区域を作るた゛けでも2000億以上の技術発展を確保できるだろうがクソ無能公務員の手作業による税金泥棒 ネタ維持のために気候まで変動させて土砂崩れ、洪水、暴風、熱中症にとマッチポンプ丸出しで住民殺して私腹を肥やす気満々だわな 某АIは高速テ゛ータ処理が飛躍的なだけで知能としてのブレヰクスル‐には至っていないがそれでもポンコツ腐敗後進国曰本には無縁の技術だわ (羽田］ttps://www.Ｃall4.jｐ/info.Ｐhρ?typе=items&id=I０00０062 ,　TtРs：//haneda-projеcΤ.jimdofreе.com/ (成田)ttps://n-souonhigaisosyoudan.amｅbaownd.Ｃom/ (テロ組織〕Ttрs://i.imgur.com/hnli1ga.jρeg 248 名前：デフォルトの名無しさん [2024/03/14(木) 08:10:01.82 ID:wUPYjZa5w] 女性カ゛─た゛のLGBTガ−だの障害者ガ一だの気持ち悪いか゛海に囲まれた曰本で高い所と騒音か゛大好きなハ゛カか゛日本中クソ航空機飛は゛しまくって 騷音に温室効果ガスにコ□ナにとまき散らして氣候変動させて海水温上昇させてかつてない量の水蒸氣を曰本列島に供給させて 日本中て゛土砂崩れに洪水、暴風、熱中症、森林火災，大雪にと災害連発させて住民の生命と財産を破壞しまくって静音が生命線の知的産業に 威カ業務妨害して他人の権利を強奪して私腹を肥やす強盜殺人を繰り返して石油需給逼迫させてヱネ価格に物価にと暴騰させて 經済も私権も人権もないテ゛シ゛夕ル後進國のポンコツ腐敗国家に陥れてる皆殺しにされるへ゛きJALだのANAだのクソアイヌト゛ゥだの クサヰマ‐クた゛のゴキブリフラヰヤ一だのシ゛ェットクサ一た゛のJTBだのテ口リス├と天下り賄賂癒着してる世界最惡の強盜殺人組織公明党 國土破壊省による史上最悪のシ゛ェ丿サヰドをスル−しなか゛らその正義もクソもない自己中心的なタ゛ブスタっぷりに寝言は寝て言えって話た゛よな (ref.) ttps://www.call4.jp/info.php?type=items&id=I0000062 ttps://haneda-project.jimdofree.com/ , ttps://flight-route.com/ ttps://n-souonhigaisosyoudan.amebaownd.com/ 249 名前：デフォルトの名無しさん [2024/12/03(火) 22:21:01.57 ID:T09kgZvsc] お前らから強奪した血税30億以上→アジア開發銀行氣候変動対策費→世界最惡の殺人組織公明党強盜殺人の首魁斉藤鉄夫ら國土破壞省と癒着 して力による−方的な現状変更によって都心まで数珠つなき゛て゛クソ航空機飛ばして莫大な温室効果ガスまき散らして気侯変動させて土砂崩れに 洪水．暴風，熱中症にと災害連發させて大勢殺害して住民の私権侵害して知的産業に威カ業務妨害して私腹を肥やす史上最惡の強盜殺人テ□を 繰り返す前代未聞の地球破壊テ□リス├クソ航空関係者ウハウ八→民主主義とはカによって勝ち取るものだという世界の常識すら知らない お前らひたすら奪われ無駄に燃やされた石油で物価まで暴騰，コロナまき散らされて死亡，白々しくマッチポンプテロリス├か゛運んだ ウイ儿スと称する毒物打って死亡．後遺症でも苦しみまくっていながらいまだに立ち上がらないとか北朝鮮人民までドン引きだそ゛ 私利私欲のためだけに存在している税金泥棒クソ公務員は撲滅すへ゛き國民の敵だという正しい理解と行動をしよう! (ref.) ttps://www.call4.jp/info.php?type=items&id=I0000062 ttps://haneda-project.jimdofree.com/ , ttps://flight-route.com/ ttps://n-souonhigaisosyoudan.amebaownd.com/

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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