Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
gitのコミットをより意味があるようにするためのガイドライン作成スレです。 なぜコミットはあるのか? コミットが残っていることで 何の役に立つのかをよく考えましょう。 そしてガイドラインを言う時は、ちゃんと理由も書きましょう。 上司が言ったから絶対なんだ!今までそれでやってきたからそれでいいんだ! みたいなのは理由ではありません。 少しだけガイドライン考えてみた ・一つのコミットで複数の修正を行わない 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから ・一つの修正を複数のコミットにわけない(分かれていればまとめる) 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから 例外 リリースしてしまったコミットはまとめることは出来ない。 いま気づいたが、この「リリース」っていう概念が重要だな。 どの時点でリリースになるのかはそれぞれだろうが master、もしくは共有ブランチににマージされた時点がリリースだと考える。 と考えると、やはり>>569 の例ははマージ機能を使ってない時点で 一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。 >>585 > >>541 と>>545 のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」 いないだろw あぁ、なんで共有ブランチにpushしたコミットは 編集したらだめなのかを書いていなかったね。 物事は単純で、他人の役に立つことをしましょう、 他人の迷惑になることはうやめましょう。これだけだよ。 コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。 これは他人の役に立つこと。 そして共有ブランチを修正したらだめというのは、他の人も その共有ブランチから派生して修正しているので、その派生元が変わると 今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。 これは他人の迷惑になること。 このように俺のガイドラインにはちゃんと理由がある。 反対のガイドラインを作りたいなら、その理由をいうことだけ。 でないと俺の意見に対抗できない 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。 俺が言ってる共有ブランチっていうのは、 他の人がそのブランチから作業をする、 または他の人がそのブランチにマージすると という目的で作られたブランチのこと。 つまり他の人が参照しているだけならば 共有ブランチとは言わない。 参照しているだけならば、そのブランチが変わっても 他の人の作業のじゃまにはならないからね Visual Studio内蔵のGitのインターフェースは最初わけわからなかった M.ハ从人ノヽ イリ ノリ,, 「ウンコはトイレでしろ」 メ _,,,,,,,,,,,,,,,,,,,_ .K こういう凝り固まった脳みその奴って出世できなさそうだよな メ i 7 .K こんなバカがウンコしたい時にトイレ探し回ってるの見ると爆笑もんだわ ヨ .y -一 ー- !, f トイレなんてただ座ってウンコをするための部屋にすぎないんだよ r! .!. ィtァ tァx .!.¥ 喉乾いたら何が何でも喫茶店入らなきゃいけないって訳じゃないだろ . !,Y f .! 探せば自販機もあるしコンビニもある . ] 、.`ー' ., .├' 喫茶店も座って落ち着いて飲み物を飲む部屋にすぎない . !,  ̄ ̄ .ハ つまりウンコしたくなったらトイレを必死で探す奴は選択肢を考えられない馬鹿 /ゝ, ,ノ ヽ, //. i`゙'''''''''"´ / |\,__,,,,,, ⌒ / ', /. | ヽ 運用で対処するより、Gitそのものが良くなる方がいいんじゃないかな?(´・ω・`) >>8 Gitの適切な運用方法を語るスレだよ。 「Gitをよりよく使うための運用ガイドライン」にすればよかったかな。 Gitに問題があるって話じゃない。 Gitのコマンド体系はもう少し改良の余地があるとは思うが 機能自体には問題ないよ。 Gitは運用方法(フロー)をがっちり決めているわけじゃなくて、 git-flowとかgithub-flowとか細かいフローがあるが、 それでも基本的な考え方というのはある。 使いにくいと思ったら、使い方が悪いと考えた方がいい。 >>5 >>6 すれ違い。そういう雑談はこっち。 Git 12(c)2ch.net http://peace.2ch.net/test/read.cgi/tech/1427085313/ ここはgit-flowやgithub-flowと言った gitを使った運用方法を語るスレ。 スレの主旨を適切なタイトル名として表せないような能力しかない人間が 立てたスレって…役に立つの?(´・ω・`) そしてスレ盛るために転載(笑) Git Flow ・使用するブランチ ・master マイルストーン用のブランチ ・develop 開発用のブランチ ・feature 機能追加用 ・(hot)fix 不具合修正用 ・release リリース準備用 ・Git Flowの良さ ・fix(不具合)の数が一目瞭然 ・masterを見ればマイルストーンの遷移が一目瞭然 ・参考:git-flowとプロジェクトの運営 ・Git Flowのまずさ ・ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない ・hotfixブランチをdevelop, master共に反映しなければならない点が面倒 ・参考:【翻訳】GitLab flowから学ぶワークフローの実践内、Git-flowとその問題点 ・参考:GitLab Flow ・GitHub Flowと比べると ・ブランチ間の移動や、複数ブランチへのマージの発生量が多くなりがち ・一定期間終了した後に全ブランチの遷移などを俯瞰すると開発の様子がわかりやすくて良いかもしれない ・一方で、開発中は開発者の負担が少し多くなるかもしれない GitHub Flow ・使用するブランチ ・master 開発用のブランチ、masterはテスト済で本番環境へのデプロイ可能 ・topic 機能追加用/不具合修正用のブランチ ・Git Flow、GitLab Flowと比べた特徴的な点 ・masterは常にデプロイ可能という前提 ・リリースはmaster更新の都度頻繁に、といったイメージ ・参考:GitHub Flow ・参考:GitLab7.1.1でGitHub Flowを実践してみた! GitLab Flow ・使用するブランチ ・master 開発用のブランチ ・topic 機能追加用/不具合修正用のブランチ ・production テスト済で本番環境へのデプロイ可能なブランチ(自動テストの対象にしたりする) ・release リリース準備用 ・GitLab Flowでのfix(不具合修正)の扱い ・masterから修正用のトピックブランチを切る ・修正内容を実装後、Merge Request(Pull Request) ・masterにマージ(トピックブランチは削除) ・cherry-pickでfix部分のみをreleaseへ反映 何かバグフィクスしてる時、全く関係ないけどちょっとした修正個所を見つけて思わず直してしまい、 そのまままたバグフィクス作業に戻って最後にコミットする段階になった。 >>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・ さて、どうしたものか。 まだ機能がロクにできあがってない完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど svnみたく基本master直コミットで、切りたいときだけ適当に切る感じでやってる? >>15 > >>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・ それは当然分けてコミットするべきだよ。 実際の開発でもよくある話で、スペースでインデントするという 規約なのに間違えてタブになっていたりね。 そういうのがバグフィックスに含まれていると、本当にしたかった バグフィックスのコードは何なのかわからなくなってしまう。 別コミットにした上で、バグフィックスとは分けてマージしてしまうのがいい。 本当に「ちょっとした修正」であればバグフィックスと違って、 レビューはほぼ不要でマージできるはずだからね。 で、聞きたいのはコミットを分割する方法? Pro gitにも書いてあるけどこんな感じだよ。 コミットの分割 https://git-scm.com/book/ja/v1/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88# コミットの分割 1. git rebase -i で edit を指定して修正したいコミットで止める 2. git reset HEAD^ で修正したいコミットを未コミット状態に戻す 3. ちょっとした修正だけコミットする(git add -p などを使って) 4. バグフィックスをコミットする 5. git rebase --continueでrebaseを完了させる >>17 > svnみたく基本master直コミットで、 いやいやw svnでもmasterに直コミットなんかしないってw (個人プロジェクトとか超小規模は除くけど) まだsvn使ってる有名プロジェクトって何があるんだろう? 例としてtracを見つけてきたけどマージのほうが多いでしょ? http://trac.edgewall.org/log/trunk > まだ機能がロクにできあがってない完成前の作成中の段階って 疑問なんだけど、その作成中の段階のソースコードってどこにあるの? まさかローカルのPCにあって、他の人はだれも見れない状態? その機能を作るのに1日かからない程度の小さい修正なら、他の人が見れない状態でも たいしてリスク無いと思うけど、数日とか数週間かかるようなものが 他の人が見れなかったらリスク高くなるよね? 作成に数日かかった大作を見せられて、それがクソコードだったとき、全部やり直しになってしまう。 だから少なくとも一日に一回はコードを他の人が見れるようにしないといけない。 そのコードは作成中なのだからmasterに入るわけがない。 ではどこに? → その答えがブランチでしょ? > 完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど ということで「完成前の作成中の段階」と呼べる状態があるのなら、それがブランチになるんだよ。 >>20 最初のほうでもみんなトピックブランチみたいなの作業ごとに切って作業してるのかなあって思って ただ最初は1個が本当に数週かかるし、ある機能が複数人に影響するのも多いから、それをいちいち各人が自分のブランチにマージするのかって考えると 1個のブランチにみんなで直接コミットしまくったほうがよくない?とも思ってどうしてるのかなあと >>21 > 1個のブランチにみんなで直接コミットしまくったほうがよくない?とも思ってどうしてるのかなあと (トピック)ブランチを作らないって話をしているんだよね? 1個のブランチにみんなで直接コミットしたら、問題が解決するのはなぜ? みんなで仕事をしているのであれば、並行で作業が進む。 (1) -> (2) -> (3) ときて、二人の人が (3) から初めて、(4a) と (4b) というコミットを作る。 この時、早く完成した人(仮に4aとする)だけが、(4)にできる。(4b)はそのままコミットできない。 ブランチを作らないならば、(4b)は(4)を元にrebaseしてからじゃないとコミットできないし、 (4b)の人が(4a)のコードが必要ならば、やっぱりrebaseが必要。 で、ここでブランチを作るならば、 (1) -> (2) -> (3)ときて、二人の人が (3) から初めて、(4a) と (4b) というブランチを作る。 この時、早く完成した人(仮に4aとする)だけが、(4)としてマージできる。 (4b)はそのままじゃマージできないから、rebaseしてからマージする。 気づいた? やっていることは全く同じなんだよ。 違いがあるのはブランチを作れば作業途中であってもpushして 今開発中のブランチコードを他の人に見せることが可能。 (4b)は(4a)のコードが必要なのだから、見たいはずだよね? でもブランチを作らなければそれができない。 >>21 で、なんで君が「1個のブランチにみんなで直接コミットしまくったほうがよくない?」と 思っているのか、その理由はわかってる。 直接コミットをすれば、すぐに他人のコードが「1個のブランチ」に取り込まれて 他の人はそれをすぐに利用できるからいい。と思ってるはず。 逆に言えば、(トピック)ブランチを切っていれば、そのブランチが 「1個のブランチ」に取り込まれるまで時間がかかる。 それぞれの開発者が、それぞれのブランチをずっと成長させていき、 その他人のブランチを、時々取り込まないといけなくなる。と思っているはず。 それはトピックブランチの扱いを間違っているだけだよ。 トピックブランチでやる内容は凄く小さい。 トピックブランチは頻繁に「1個のブランチ」にマージされる。 みんなが直接コミットしまくるのと同じぐらいの頻度で 「1個のブランチ」にマージされるんだよ。 ちなみに「1個のブランチ」がmasterであるか、次期リリース用ブランチであるかは gitフローなのかgithubフローなのかによって変わる。 >>21 君が抱えている問題を解決するヒントを一つ提示しよう。 ある機能を作ることになった。その機能のために1つのブランチを作る。 (ここまではsubversionでも一緒だろう) そしてそのブランチを作っている間に、ある便利な関数を作った。 その便利な関数は、他の人も使う。 のであれば、君が作っているある機能の完成を待たずして、その便利な関数だけをマージする。 出来上がった所から取り出して、早くマージしてしまえばいいんだよ。 (こういうことがsubversionではやりにくい) この発想ができるようになれば、中途半端なコードをマージすることもないし、 みんなで直接コミットしまくるのと同じように頻繁にコミットできて それをするために、自分の作業履歴(コミット)を自由に入れ替えて 歴史を修正することができるgitの重要さが理解できるようになる。 やれやれ。荒らしたい奴は来なければいいのに。 なんのためにこっちに移動したのか? >>1 の説明は論理的で分かりやすいです。 質問に対して、自分のガイドラインに従った場合の解決方法をちゃんと示しています。 何を重要視しているのかが明確に示されていて、それが自分に合う人にはとても参考になると思います。 >>25 や >>26 などは、たぶん合わなかったのでしょう。 Git人口はとても多いので、当然そういう人も大勢いると思います。 彼らが従うガイドラインも見てみたいです。 ちなみに私は >>15 ですが、とても参考になりました。 なぜグローバルなガイドラインを語らずに身勝手な自分ルールを持ち出すの? 独り言はツイッターでやってろ > なぜグローバルなガイドラインを語らずに なにいってんの? グローバルなやり方を説明してるだけなんだが。 OSSのmasterのマージコミット(単なるコミットではなく)を見てみろよ。 マージコミットの中で、typoの修正とかありえないし コミットの内容もその順番も明確になってる。 開発でそんな綺麗に作業なんて出来ないし、 そもそもマージ前にレビューがはいるのはやり直す必要がある場合が多いから。 そのやり直しを感じさせないぐらいに綺麗に整理されてからマージされてるんだよ。 >>28 どうもどうもw git歴は2年ぐらいかな。当初というかgit始める前から 可読性ならず可レビュー性を重視していたからね。 Subversion使ってる時にレビューしていて、 あれ?この修正不味くない? あー、あとのコミットで修正されてるのかー! みたいなのとか いきなり一週間分の修正をまとめて持って来られたって 解読に時間掛かり過ぎる、細かく分けて持ってこいよ。 とか これじゃレビューできるわけ無いよね。みたいなのをどうするかを考えていた。 Subversionでも出来ないことはないんだが、いちいちネットワークにつないで 何度も送信しないと行けないからストレスが溜まる。gitだとそれを素早くやれる。 それを元にいろんなOSSの履歴を見ながら、それに近いことを実現する フローはどういったものかを考えてまとめたのがこのスレで俺が言ってることだよ。 >>30 一個でも良いから、具体例を一つリンクしてくれないかな? グローバルだからってどんな現場にもgit-flowを当てはめるような思考停止は 設計できないデジドカっぽくって嫌いだね >>32 gitの使い方の具体例なら、gitプロジェクトでいいでしょw 目指すはこんな感じのコミットログだよ。 https://github.com/git/git/commits/master masterにマージされるのは、無駄のないきれいなコミット。 あとは、マージされたPull requestsの方をみればいいんじゃないかな? https://github.com/git/git/pulls?q=is%3Apr+is%3Aclosed マージを許可されるブランチというのは、どうブランチであるべきかってのがわかる。 だいたいは小さな修正でコミットも一つだけど、複数のコミットからなるブランチもある。 これなんか1つのファイルに対して18個のコミットで修正しているけど、 それぞれのコミットが、ちゃんとタイトル通りの内容で少しずつ修正されており 何をしたのかわかる可読性の高いブランチになってる。 https://github.com/git/git/pull/54/commits 「一つのファイルの修正だからって全部まとめたら何やってるのかわからんだろうが」と言われない良い例だね。 >>33 どのフローであっても、ゴミコミットは入れない。 コミットは後から見てわかるように可読性が高い綺麗なものにして マージするっていう点は全部一緒だよ。 つまり、誰もが「無駄かどうかを決めるのは俺様(キリッ」て言って譲らないから Gitは有効に使えるツール足り得ないってことだよね?(´・ω・`) 業務用のシステムを管理するには?どういう方法が良い? 初期開発は良いとしても 本番リリースした後は 本番稼働のもの 本番でバグが発覚(複数)して対応中 改良もはいってる とかになるとどう分けていつコミットやプッシュするべき? ただ使うだけならコマンド叩くだけなんだからなんも考えんでも使える gitの本当に難しいところは、自分のプロジェクトでどう使うか >>39 それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。 バグをどうリリースするかはバグの内容による。改良のリリースも同じ。 緊急で出さなきゃいけないものは緊急で出す。 そういうのは見つかった段階ですぐに対応しなきゃいけないから 最新のリリース版からブランチを切って作ったブランチをリリース版にマージ。 そしてそれを開発版にもマージって流れになるだろうね。 あとはブランチ(=バグや新機能)をリリースしたい順にマージ[*]していけばいい。 よくあることだが、新機能がバグの修正に依存しており、新機能の作成中に見つかった。 という話しなら、先にバグを直して(バグ修正ブランチを作ってマージ[*])、 そこから新機能を作ったことに歴史を書き直せば良い。 [*] の部分だがどこにマージするかは方針と内容次第。 すぐにmasterにマージすることもあるし「次期バージョン」という考え方を しているのなら次期バージョンブランチを作って、そっちにマージしていって リリース時にmasterにマージを行う。 ただし大型新機能の開発が複数並行で進んでおり、両方が同じ部分を修正する 可能性が有る場合、大量のコンフリクトが起きる可能性があるので注意する必要がある。 これを避けるために新機能が完成するまで新機能の内容を"全て"マージしない という考え方を変える必要がある。 多くの場合、新機能の開発の中には、既存バグの修正やリファクタリング モデルや汎用ライブラリなどの機能追加(仕様変更ではなく)が含まれる。 これらは先にリリースしても問題ないはず。全てマージしないのではなく一部だけマージする。 だから新機能の開発を行っていたとしても、そのなかで先にリリースできるものはリリースしておく (次期バージョンブランチがあるのならそっちにマージ。次期バージョンブランチと新機能ブランチは別ね) こうすることでいち早く大型新機能開発はコンフリクトが起きかねない部分を知ることができるし、 相手の開発した部分を利用することも可能になるから、同じものをそれぞれで作ってしまう無駄も省ける 大型新機能開発を行っていたとしても、小さな開発とリリースという形に変更していくことは可能なんだよ。 自己レス > それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。 この話につながっていなかったw まあわかるとは思うけど、このように開発の順番とマージやリリースの順番を 自由に入れ替えるってことは、それぞれのコミットが意味のある単位で 細かくまとまってなきゃいけないんだよ。 無関係の修正が一つのコミットに混じっていたり、 関係あるコミットが複数に分かれていたりしたら それを見つけるのが大変になる。 ちゃんとコミットが分かれていれば、開発した順番ではなく 望む形に入れ替えたりすることがしやすくなる。 コミットを細かくってのは、簡単なようでいざやると相当難しいんだよな これがすっきりできれば後はどんなフローにも載せられるんだろうが… >>44 たしかにね。最初はちょっと難しかった。 コード修正中に関係ないことをついついやってしまうしw そこは慣れだよ。意識してコミットを小さくするようにしていけばいい。 まず覚えるべきなのは、git add -pだね。 これができると一つのファイルの中の一部分だけコミットできる。 あとはコミットの順番は後から並び替えられるし、まとめることもできるので 順番は気にせずにほんとうに小さくコミットを作ること。 そして後からまとめて綺麗にしようと考えずに、常に片付けながら作業(開発)すること。 後からまとめてコミットを綺麗にしようと思って、そこで何したか忘れるんだよw 大きな開発を複数人でスムーズに行うには、共通のソースコードへの修正の 反映作業が重要だからね。大きな開発も小さく修正していくことで管理可能になる。 それを実際にやってるのを見れるのがgithubとかなんで(まともなプロジェクトの) リポジトリを参考にするといいよ。 >>46 まともと思える物を紹介して 参考にしたい >>47 だからgitだってw gitを一番うまく使ってるのは gitプロジェクトに決まってるでしょw >>1 のスタンスで詳しく書かれた Git の書籍はないですか。 洋書でも構いません。 >>49 紛らわしいので言い直します。 >>1 の人のような考え方を詳しく解説した書籍はないでしょうか。 洋書でも構いません。 >>49 残念ながら知らない。日本の本に関しては、最近出た2,3冊は内容を確認してないけど、 それ以前のものに関してはgitの使い方ぐらいだったな。それはそれで最初のうちは 役に立つんだけど。海外の本に関しては、読んでないので知らない。 代わりに日本と海外(アメリカ)の考え方の違いの話をするよ。 よく言われていることだけど、海外はパッケージの導入を積極的に行うけど、 日本は独自で作ったりパッケージをカスタマイズすることを望む。 この考え方の違いというのは、日本は自分のやり方を通そうとするということ。 日本の文化だと、アプリにがあれもこれもなんでも出来るようになってしまう。 それは一見便利なように見えるけど、業務を改善(=変えていく)ことにはつながらない。 やり方を変えずにツールを変えるだけだから生産性は上がらない。 海外のソフトウェアっていうのは、業務を一番効率的にやれるのはどういうものか? という考えを形にしたものなんだ。もちろんその考え方はいろいろあって正解とは限らないけど、 少なくともソフトウェアっていうのは、開発者が想定した正しい使い方っていうのがあるんだよ。 つまり俺の考え方というのは、ツールの正しい使い方というのを学習していくことでできたもの。 ツールにはできること、できないことってのがあるけれど、思いつくまま実装されたのではなく、 正しい使い方をするのに、必須だから追加した機能であり、邪魔だから追加しないと考える。 例えばgitには歴史を改ざんできる機能があるでしょ? これは正しく使うのに必須だから。 ファイルをロックして他人が編集できないようにする機能はないでしょ? それは正しく使うのに邪魔だからあえて搭載しないことを選んでいる。 この開発者の考えに、自分の考えが適合してくると、「こんな機能があったほうがいいんじゃないか?」って 思ったものが次期バージョンに搭載されたり、議論が行われていたりする。 考え方が合わない最初のうちは、なんでこうなってるんだ?使いにくい!って思うかもしれないけど そうではなく意味があってやってることだと考え、何故そうなっているかを考えていくといいよ。 >>49 もう一つgitよりの話をすると、gitは誰が何故作ったのかを考えればわかると思うよ。 リーナスがソフトウェアを開発するために作ったよね? そう、開発者のものなんだ。 開発の進捗を知るためのマネージャーのツールでもないし ソフトウェアのロストを怖がる管理者のツールでもない。 ソフトウェアの開発、しかもそれを多くの人が関係するってことは 正しい修正であるかどうかを判断するには、ソースコードを読まないといけない。 頭数を揃えてテストしたって、正しい修正であるかなんてわからない。 どっかの金もってる大会社じゃないんだから、頭数自体揃えられないけどw そういう文化にとって「テスト」とは誰でも(一人でも)テストの実行を再現可能な テストコードであり、そのテストコードが正しいかどうかは、読んで判断するもの。 それ以外できっこないんだから。これは現実。 そこまでわかれば、あとは何が必要かがわかる。必要なのはコードが読みやすい コミットであり、必要なツールは読みやすいコミットを作ることが出来るもの そういう考えでgitが必要とされ生み出された。あとはそのgitの正しい使い方を理解していくだけだよ。 ただ一つだけ俺がラッキーだったのは、gitを知る以前から、読みやすいコミットの重要性を理解していたことかな。 完成されたソースコードだけじゃなくて、修正の内容とその過程自体もわかりやすいことが重要であると。 だから俺にとっては、gitは俺が考えた理想を実現するツールだったね。 後からコミットログは簡単にまとめられて、逆に分割は困難なことを考えると 上書き保存するたびに即コミットぐらいでやるほうがいいのかなあ 休憩や今日の終わりの度にコミット? 動かないコミットは嫌だな git って ID:2XvJk2DZ みたいな信者が沸くところが嫌なんだよね 理想に最も近いとか言うならまだわかるけど、理想を実現したとかちょっと気持ち悪い >>53 それでもいいぐらいだよ。ただコミットを整理せずに 放置しておくと何したのか忘れるので整理しながら作業した方がいい。 分割は面倒だけど困難というわけでもない。 やり方は色々あるけど、rebase -iの途中で分割作業をするから (つまりある作業中に別の作業をするようなもん) 少し慣れが必要だけどね。 >>54 masterに入れるのは動くコミットに決まってるでしょw トピックブランチなどは最終的に消すものなのだからどうでもいい。 誰が作ったそのルール? コミットはどんなものでも 動くようにしろとか、変な自己ルールに縛られすぎだよw 理由があるからルールができる。理由を説明できないような ルールを作らない方がいいね。 >>55 うん。それで? なにか間違っているとか、もっといい案があるなら どんどん言っていいんだよ? >>56 ならあんたのルールをここで公開してくれよ 採用考えるわ >>57 1からずーっと書いてきてる。 読みなおしてくれ。 >>58 ずーっとってお前の発言は識別出来んわ コミットしてくれー だとコミットの使い方が違うか >>59 既に>>2 で具体的に書いてるじゃないか? >>59 「コミットを意味があるように綺麗にしておけ」とは言っているが その中で「コミット」という単語しか見えないのか? >>60 おいおい1からずっと書いてるから読めって 2がまとめかよ しかもあれで具体的だなんて ちゃんと仕事で複数人で活用してる人? 一人とか小さなものでやってるだけ? なら、お前が書けと言われても作れていないから書けない、悪いがな もしかして、このスレって 自称優秀なPG様が作っているスレ集の1つだったか? >>62 2がまとめじゃなくて、2が基本てな原則だよw その後は>>2 の補足をしたり、もっと具体的に踏み込んだ説明をしている。 あれで具体的って、お前やっぱり>>2 しか見てないじゃないかw だからちゃんと1から読めって言ってるんだが。 > ちゃんと仕事で複数人で活用してる人? 当たり前だろw 逆に一人でやるなら適当にやればいいだろ。 自分の書いたコードだったらコミットが汚くてもわかるんだよ。 でも他人の書いたコードのコミットが汚かったらわからないだろ? レビューしてくださいって来たコードが、何百行もある大作1コミットだったら レビューなんてできるわけないし、小さく分かれていても複数のコミットで 同じ行を修正していたりしたら、無駄なレビューをすることになる。 レビューするためには、ソースコードを綺麗にするだけじゃなく コミットの内容も綺麗である必要がある 俺の話は複数人だからこそ必要な話をしてるんだが。 多くの人、それぞれスキルは違うし、悪意がある人迄いる可能性がある オープンソースを見てみなさいよ。 適当なコミットはレビューできないから、そういうのはマージされないよ。 知った人間ばかりの会社内のやり方とはわけが違う。 会社内だとコードのが意味不明でも上司だからとか、あの人なら大丈夫だからとか よくわからないけど、動いてるみたいだからいいんじゃね? コミットが汚くてもろくにレビューもせずに適当マージしてるでしょ? 俺の意見は最初から一貫して、レビューが可能なように綺麗なコミットにしろって話をしてる。 >>64 それで? そんなものよりもっといい案が有るなら それを言ってくれよ。 自分の意見を言わない奴に 発言する権利はないよ。 ミーティングと一緒。 ミーティングで誰かの意見に対して 「あなたの提案の内容に関してですが、 あなたの発言がキモいです。」 とか言ったら嘲笑w gitのコマンドはわかるんだけど gitをどのように使っていけばいいか悩んでいる人 相談に乗りますよー。 やっぱりよく見るパターンだったな 自分語りのために無駄スレ作ってないで ちゃんと会社の人とルール共有しろよ >>70 会社に人と共有しているルールというか 考え方を書いているだけですが? それであなたの考え方は? それがないとあんたはただの荒らしでしかないよ。 話し合いにも討論にも雑談にさえならないのは目に見えてるから遠慮しとく そういやうちの会社にはいないけど、 よく聞くじゃん? 上の立場の人が、でてきた意見を何の理由もなく否定する人。 きっと自分の考えを書かずに否定する人って 上の立場になったら、そういう人になるんだろうなって思った。 ドラマや小説で悪役として描かれる そういう上司。 >>72 バイバイw 俺にしてみれば、お前をあぼーんしたのと同じだから それがお互いにいい結果。 意見がないならもう来ないでね。 意見があるのなら来ていいですよ〜w >>67 すごく良い発言があるよ 「あなたの提案の内容に関してですが、 あなたの発言がキモいです。」 とか言ったら嘲笑w だよなー でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」 だな >>75 > でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」 わろたw 2ちゃんねるだからいいとして、 そんなの会社でやったら即刻クビだろw ホントこいつ発現する意味ないわーw >>74 おまえだれ? 少し前に指摘したことさえ忘れたの? 少し前に指摘した人だってことをわかってるのに、 誰って聞いてるのはなんなんだろうなw そんなのどうでもいいだろう? ここにはgitに関する意見を書けよ。 >>54 >動かないコミット 開発ブランチは分けろω >>79 こまめなコミットって意見あったけら言ったんだが 開発ブランチなら、動かないコミットも許す? 開発ブランチは個人ごと?ローカルコミットだから人に迷惑はかけない? マージしたら凄いゴミコミットの山では? など疑問は多い >>80 少しは考えたほうがいいよ。 なぜブランチはあるのか? なぜ動く必要があるのか? 開発ブランチは個人ごとである必要があるかないか 何をしたら人に迷惑で何が迷惑でないか 疑問があるのなら、他の人はどうやっているかを考えればいい。 世の中にサンプルはいくらでもある。 前にも答えたけどgit自体のリポジトリを見るとか。 有名プロジェクトであれば、そこがやっているやり方には 何かしらの理由がある。 疑問が多いってことは、その疑問に対して 自分で何も考えてない証拠だよ ちなみに>>80 の疑問に関して言えば 俺は既に答えが出てる。 d62hq9+6はどうやら俺にレスして欲しくないようだし、 他の人の意見も聞きたいから>>80 に答えるのは 明日ぐらいにしようかな。IDが変わってからw >>34 githubの画面からはよく分からなかったから、ようやくcloneしたけど、mergeコミットと単なるコミットってどういう意味で呼び分けてるの? > 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 を参照ください)。 > これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。 >>86 明らかに違うものとしてgitで管理されていることを示すために http://te2u.hatenablog.jp/entry/2015/03/24/233447 > この状態でrebaseを行うときに-iオプションだけでは > マージコミットは含まれない。マージコミットがあるときは > -pオプションをつけて実行すると > 指定した範囲のマージコミットが含まれる。 このように、rebase -iコマンドには マージコミットという特別なコミットを 含めるか含めないかのオプションが有る >>30 で単なるコミットではなくマージコミットを見ろって言ってるじゃん。 普通の使い方なら、そもそもマージコミットで個別の修正はあり得ないよね? 単なるコミット同士をマージしたものなんだから。 >>89 あぁ、その話か。 マージコミットには、どのコミットとどのコミットを マージしたのかって情報が含まれるんだよ。 「単なるコミット同士をマージしたもの」という言い方が、 何か意味を勘違いしている気がするが、コミットには歴史の情報も含まれている。 (つまりAとBコミット番号が同じなら、過去も同じであるということ) つまり、masterにbranch(のHEADのコミット)をマージするってことは、 マージコミットの中にはbranchの複数のコミット情報が含まれてることを意味する >>30 で言ってる「マージコミットの中」というのは、 マージコミットでマージしたブランチの複数のコミットを見ろって話。 それはブランチのコミット内容を意味する。 人によってはmasterに直接コミットを追加することもあって マージコミットを使ってないコミットにはtypo修正とかあり得る。 (typo修正だけのブランチをffマージするのと同じ) だからこのコミットを見てもブランチが綺麗に整理されてマージしているってことに気がつかない。 マージコミットの中の複数のコミットを見ることで、ブランチに含まれる コミットは綺麗に整理してからマージされているってことがわかるって話。 やっぱり、マージコミットにはマージしたブランチの複数のコミットが含まれる、っていい方が分からんな。 githubは確かにそう見えるが、実際にはマージコミットは二つの親コミットをもつコミットだろう? githubはpull request形式だから、マージ先ブランチとマージ元ブランチを明確に区別出来て、マージコミットをマージ元ブランチの複数のコミット、という意味に出来るのかな? まあ、要するに、単なるコミットっていうのは、githubのmasterブランチ上で表示されるマージコミットでないコミットってことね。 >>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であるかどうかはわからないし、いつ枝分かれしたかも わからないって考えてるんじゃない? そういうことはありえないよ。 ブランチ AのHEADがコミットcで、masterのHEADがコミットDのときに、ブランチAにmasterをマージする。マージコミット☆が出来る。 そのあと、masterがブランチAをマージすると、ffになってmasterのHEADが☆になる。 さて、このときマージコミットに含まれるコミットはa,b,cなのか?それともB,C,Dなのか? ffになったらマージコミットはないよ? 確実にマージコミットを作りたいなら (通常masterへのマージではマージコミットを作る。 なぜならマージしたという情報を残すため) --no-ffオプションを付ける >>96 言ったでしょう? masterへのマージでは通常 --no-ffをつけるって。 だから>>94 のような状態には通常ならないんだよ。 運用ガイドラインの一つとして、masterへのマージは原則として --no-ffをつけるってのも必要かな。 >>98 --no-ffすればマージコミットになるのは当たり前だし、 >>95 ではffになったらって前提でマージコミットにはならないって言ってるし、 >>90 ではffマージもあり得る話としているから、イマイチgitの仕組みを理解してない人なのか、github前提で話をしている人なのかの区別が付かなかったんだ。 今さら--no-ffをルールにすべきか?なんて言ってるけど、git自体は--no-ffが原則なの? それともgithubのpull requestの運用だと--no-ffを原則にしなくても問題ないの? githubのpull requestの運用だと--no-ff勝手につけてくれるな >>101 > 今さら--no-ffをルールにすべきか?なんて言ってるけど、git自体は--no-ffが原則なの? いつも思うんだけど、単純なルールを欲しがるよね。 関係ないけど、ちょうどこんな記事を読んだんだよ。 アジャイルの破綻―原因、そして新たな提案 http://postd.cc/the-failure-of-agile/ > あなたが新しいプログラミング言語や技術、または開発手法などの新しいスキルを初めて学ぼうとする時、 > 経験やメンタルモデル、”調査と順応”といった抽象概念に対応する能力を持ち合わせていません。 > これらの能力は、より経験を重ねた熟練者だけが持ち合わせているものです > > 初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。 > 例えば、「これが起こったら、あれをする」といったようなルールです。 > ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、 > 初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、 > 凝り固まったやり方になってしまいます。 何も考えたくないから、簡単なルールを求める。 そうじゃなくてちゃんと考えようよ。 俺は「マージするときは必ず--no-ffをつける」なんて言ってないからね? まず一つ「masterへのマージ」と言った。そして「原則として」と言った。 原則として http://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になってるんだから、それ見ればわかるでしょ。 >>102 > githubのpull requestの運用だと--no-ff勝手につけてくれるな そうなんだよね。基本的にmasterへのマージは--no-ffになるから そんなの基本的な話だと思っていた。 そしたら、masterへのマージでffになる例を持って来られたから、 今さら(masterへのマージに)--no-ffをルールにすべきか? って話をせざるを得なくなったんだよ。>>101 俺としては当たり前すぎの話だったので省略してしまった部分。 うん、やっぱりgithub前提なんだね。 masterへのマージは--no-ffが基本だと思ってるってことは、masterへはrebase+ffで変更を取り込まない方が良いって思ってるってことだ。 それは何でだ? githubを前提にしないでコマンドラインだけで運用した場合は、マージコミットが増えることはログの煩雑化を進める気がする。 やっぱり、運用ガイドラインにはgitをサポートするツールに何を使用するか、というのも条件に含めないといけないと思う。 >>105 github前提でもなんでもなくて、一般的な話だよ。 理由もそこに書いてあるとおり。 どうやら俺が説明すると、それは変なやり方だって思い込んでるのか いちいち調べもせずに絡んできてるようだから、他人が説明した理由を紹介することにする http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html > --no-ff フラグは、たとえマージがfast-forwardで実行できるとしても、 > 新しいコミットオブジェクトを作成する。これは、履歴にフィーチャーブランチが > 存在したという情報を失うのを避けるのと、機能の追加に使った全ての > コミットをひとまとめにしておける。比べてみよう: > 右の場合、ある機能を実装したコミットオブジェクトをGitの履歴から見つけられない > ――あなたは全てのコミットログメッセージを手動で見なければならなくなるだろう。 > 機能の全て(例えば、一連のコミット)を revert しなきゃいけないなら、右の状況では > 本当に頭を痛くさせる。だがもし --no-ff フラグを使用したなら、簡単に終わるのだ。 > > 確かに、これだとより多くの(空の)コミットオブジェクトを作成するはめになるが、 > そこから得られるものはコストよりずっと大きい。 で、マージコミットでコミットを纏めるって考えは、コミットを意味のある単位で纏めるって話と繋がっていて、 githubなどのオープンソース開発モデルだと、マージコミットをpull request単位に出来て相性が良いと思うんだよね。 じゃあ、常にこのモデルが優れてるかという点については議論の価値があると思う。 4、5人の少人数開発で一つの意味あるコミットの大きさが小さい開発の場合は、コミット一つにつき一つのマージコミットが出来てそのログに書かれた内容が同じってことになる。 だったら、せっかく一つ一つのコミットを読み易く分割してるんだから、rebaseモデルで、masterを出来るだけ一本線に保つという考え方の方が、bisectが有効に働きやすいというようなことがあるかもしれない。 gitのgitを見ると、ブランチをマージしたってコミットはたくさんあるけど 普通のマージコミットみたいに、ブランチの中にあったはずのコミットはログに出てないね すっきりしてていいから真似したいんだけど、--no-ff使って作ったもんなのかな >>108 > これは、git flowモデル前提だね どこに書いてるのさw 「git flowモデル前提と知っている」ということなら 「git flowモデル以外では違うと知っている」はず。 ならば、違うフローでは、--no-ffをつけていないということを 具体例を上げて示すべきでは? >>110 これがgithubの機能として当たり前なのかどうかが分からないんだよね。 例えば、gitのコミットログをsourcetreeで見ると、とんでもなく並行してブランチが存在するように見える。 もし、sourcetreeのようにしかログを参照してなかッタトしたら、もっとブランチの分岐点を制御する運用にしようと考えるんじゃないかな? >>111 A successful Git branching modelのことを、git flowモデルとも言うんじゃないの? http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html このモデルでも--no-ffを原則にしてるから一般的なんだということをしめしたかったのかと思ったんだけど。 --no-ffを使わない、というgit運用モデルがあるかどうかは知らないなあ。 と、いうより、githubとgit flowのモデル以外に明文化されたgit運用モデルを知らない。 rebaseを主体としてmasterを出来るだけシンプルに保つ運用モデルがあっても良いとは思うんだけど、ちょっと調べた限りでは見つからなかった。 他にも知っているモデルがあったら、>>107 のように紹介してくれたら有り難いんだけど。 勘違いしてたんだけど、git自体が使用しているワークフローとgithubが想定しているワークフローとgithub flowというワークフローは全部違うみたいだね。 ・git開発のワークフロー http://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自体と同様に特にワークフローを定義せずに利用者に任せるスタンスなのかもしれない。 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をつけるということがわかった。 つけないものはあるのか? >>115 >>114 で貼ったgit自身の開発モデルでは--no-ffは付けないみたいだね。 gitworkflowにも書いてないし、gitのmasterブランチにもmergeコミットではないコミットも含まれている。 例えば、0e8771fなんてffされたmergeに見えないか? そもそもpatchで取り込むことも想定されてるから、mergeの時だけ--no-ffを前提にすることは無意味だと思う。 スレタイは Gitをより良く使うための〜 にするべきだったな ぶっちゃけコミットログを綺麗にするのって 綺麗にするために払う時間コストに比べたらどうでもよくね? コミットログメッセージの書き方についての話題が無いけど、>>1 的にはどうなの? ルールや提案、アドバイスなんか無いの? そういえばコミットログは暗黙の了解な書き方があったね。 1行目:題名 2行目:空行 3行目以降:詳細説明 format-patchすると1行目から空行までを切り取られてSubjectにされるので 空行を入れずにたくさん書くと、なかなか面倒な事になった。 問題となるのはタイトル文。 アプリを作っているのなら、開発者ではなくそのアプリを主語にした文を書くという流儀があるね。 (ただし、主語そのものは省略する) 開発者がやったことではなく、アプリができるようになったこと、とか。 運用のスレができたのはいいことだがわしには難しすぎる とりあえず、テストのことを考えてみた。 こういうガイドラインはどうかな? ・どのコミットもコンパイル & 実行可能であることが好ましい どのコミットもコンパイル可能であることを保つと、rebaseやcherry-pickに制限が発生する気がするな。 あと、コミットを分かりやすい単位で分割する、とい指針と矛盾するときもあると思う。 ・コンパイルが通らなくても構わないコミットを他と区別つくようにする 例えば、コミットA〜Dは変更内容の分かりやすさのために分割しているが、順序入れ替えや途中適用が出来ないことを示す記法を使用するとか。 >>126 それはコミット同士の依存関係であってコンパイル可能かどうかとは関係ない。 A>B>Cという歴史があってBで実装された関数をCで使っているのなら コンパイル不能なコミットを許可したとしても問題は解決できない。 コンパイル可能なコミットにする事というのは A A>B A>B>C 各歴史のHEADでコンパイルできる状態になっていますという事だよ。 ごめん、何を言いたいかわからない。 各コミットをコンパイル可能にしておくのも、結構難しいって問題を出したつもりだけど、そっちが問題と考えてるのは何? コンパイルが通らないバージョンがコミットされてるなんて、気持ち悪くて嫌だ。 気持ち悪いのは主観 作業用ブランチなら好きにしなはれ そっか、ビルド可能(あるいはテストパス)を区切りにしない人もいるんだ。 というか、前回コンパイル可能から再びコンパイル可能までに書くコード量が違うのかな? あるいは、ビルドにめっちゃ時間がかかるから、頻繁にビルドできないとかなのかな。 >>129 コンパイル、実行可能にしておくのは当たり前で、そういうのは理由にならないって事 全てのコミットがコンパイル可能になっていなければgit bisectが使えない 実際gitのソースコードでもv2.4.5からHEAD~1500くらいまで 全部コンパイルしてもコンパイルエラーになることはない。 git bisectみたいにgitの機能として実装されているのだから gitを使う人にとっては全てのコミットをコンパイル、実行可能にしておくのは 当たり前で、難しいことではないという認識なんだよ。 developmentブランチ的な共有品に、ビルドすらコケるようなのを上げるのは 人の仕事を止めるから考えるまでもなく当然ダメだろう >>134 だから、何の理由にならないかって所を聞いてるんだけど? 共有ブランチ上のどのコミットに着目してもコンパイル可能であるべきで、それは分かりやすいコミット分割に優先するって話かな? つまり、コンパイル不能な途中経過をコミットするぐらいならsquashした方がマシ、と。 >>135 例えば、mater→A→B→Cというコミットのあるブランチをpull request受けた場合、マージする側はA,Bのそれぞれでコンパイル確認をしてからマージするべきだと思うかい? それともCまでか?または、マージコミットに対してだけで良いと思うか? 自動実行テストがある場合はどうだ、それぞれで実施すべきか? >>136 だから履歴を遡っての問題分析を難しくしてしまうのと git bisectが使えなくなるのが問題。 コンパイル実行可能なのもコミットのわかり易さもどっちも必須条件 コンパイル出来ないけど分かりやすいって具体的にどんな例? オープンソースのリポジトリにそんな例ある? 日時ビルドでコケましたってのが事故としてはありえても それを理由に、開き直って機能しないってわかってるブランチpull requestしていいことにはならんだろ 発覚した時点で最優先でに修正することになるだろうし revertでもresetでもなんでもいいんだけど、変更を破棄したくなったときに、どのcommitが コンパイル可能なものなのかわからんという状況は困らないのかな。 >>138 オープンソースの例ではないが、業務上でありそうなものとしてはモジュール毎に担当者が決まっていて 1) 共通APIに機能を追加するために引数追加 2) それを使用している他のモジュールで引数追加に対応 で、1と2で担当者が違うから別々のコミットにしたい場合とか。 merge --no-ff必須にしておけば、mergeコミットは必ずコンパイルもテストも通る、って運用は可能だと思う。 pushする前にはコンパイル確認必須、とした場合も、masterブランチにコンパイル不可なコミットが混ざる可能性があるが、動作保証を自動テストで担保している場合はそれほど困らないんじゃないかな? テストの方は全コミットで動作保証できることを期待してないだろうし、コンパイルに通らない事はテストに失敗したとみなせば同じ事だし。 >>143 ないな。新しいAPIを追加して前のものは残す。 新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。 そんなガチガチの縦割り組織ならリポジトリも別にするべきだ。 >>144 そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。 過去バージョンのアップデートリリースが作りにくくなる。 >>145 >>>143 >ないな。新しいAPIを追加して前のものは残す。 >新しいAPIに乗り換えるよう通達して、参照がなくなったところで削除する。 各コミットのコンパイル可能を保証するために、その手順を踏むことが望ましいという主張だね。 俺だったら引数追加するたびにAPI名を変更するぐらいなら、squashでまとめるか、常にコンパイル可能を諦める方を選ぶな。 >>144 >そんな事してもcherry-pickで拾ったら不完全なものを取り込んでしまう。 cherry-pickが完全に取り込めるかは、そのときのHEADがコンパイル可能かどうかとは関係ないよね。 新APIを追加するコミット無しに、新APIを使うコミットは適用しても、コンパイル出来ないよ。 >>147 cherry-pickの結果コンパイルは出来なくても意味のない単位で分割するよりは 必要な修正がまとまっている分、不完全なものになる可能性はずっと低くなる 例えば、Aに前処理とBに本処理がコミットが分かれていて Bのみを拾った場合、理解不能な挙動をを起こすことになる。 コンパイルエラーになるならまだ良いほうで、 偶然コンパイルが通った場合は余計なデバッグに時間を費やすことになる。 いやだから、cherry-pickの結果、コンパイル通らなくても構わないのであれば、そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても、意味のある単位で分割されてれば阻害要因にならないよね。 >>143 の例のようなモジュール単位でコミットを分ける、というのも意味のある分かりやすい単位だけど、複数のコミットの一部しか適用していない状態だと全体のコンパイルが通らないという弊害がある。 ガイドラインとして、それを許容するか否か、ということが論点のつもりだけど。 また、それを許容しない場合は、rebaseしたときに、手を入れた各コミットの段階ごとにコンパイル確認が必要になる。 全コミットでコンパイル保証をするというのは、その手間を払う価値があるか否か、というのも論点になる。 Gitではコミットって、見せる前にちぎってくっつけて書き換えるもんだから 粒度小さければ後はどうでもいいよな SVN時代のコミットの話は、動かないブランチをメインにマージしていいか?のほうが近そう >>149 >そのコミットが元々のブランチ上でHEADだったときにコンパイルが通ってなかったとしても 誤解を招く表現な気がしたので訂正。 >そのコミットを指定してcheckoutしたときにコンパイルが通らないとしても >>149 意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。 これは阻害要因じゃないのか? rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。 そんなに手間だろうか? >>153 多分、bisectは使ったことないから実感ないんだと思うよ。 逆の視点で言えば、全てのcommitが意味ある単位でビルド可能で、望ましくはテストOKなら、 gitの恩恵の全てを受けることができると言える。 >>153 >意味のある単位で分割されててもコンパイル出来なかったらbisectできないだろう。 >これは阻害要因じゃないのか? 確かにbisect使ったことないけど、コンパイル出来ないと何が困るの? そのコミットをskipするなり、無視するスクリプトにするなり出来そうだけど。 git bisectのマニュアルにはその例が載ってるよね。 http://www8.atwiki.jp/_pub/git_jp/git-manual-jp/Documentation/git-bisect.html >rebaseの各コミットをコンパイル確認したいのならその範囲をbisectすればいい。 >そんなに手間だろうか? ごめん、こっちは全然分からない。 bisectは二分探索だと思ってたけど、ある範囲のコミットを全チェックすることも出来るの? そして実際にそうすることをガイドラインに組み込むべきだと思う? gitのpost-commit hookは使ってないのかな? 各コミットが、少なくともビルド可能であることを条件にしとくと、post-commit hookも 利用価値が出てくるのでは。 >>154 post-commit hookで何をしたいのかな? コンパイル確認じゃないよね? コンパイルできなかったものはスルーすれば良いだけだよね どうみても >>157 > post-commit hookで何をしたいのかな? それは、post commit hookなんか、誰にとっても不要だって言いたいのかな? >>158 > コンパイルできなかったものはスルーすれば良いだけだよね > どうみても 意図しないエラーと、そうでないものを区別できないよね。 自動的に何かをするときは、意図しないものを検知したいときがほとんど。 クリーンビルドしても問題がないかとか、全テストを実行するとか、静的解析をするとか。 >>159 いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど? まさか、post-commit hookでコンパイル確認させるつもりじゃないよね? >>161 > いや、あるコミットがビルド可能なこととpost-commit hookに何の関係があると思っているのかを聞いてるんだけど? post-commit hookの前提が、 ・ビルド可能かどうかもわからないもの ・ビルド可能なのが前提 ・ビルド可能だし、テストもパスしているのが前提 それぞれで、できることが違うよね。 それと、コミットが、 ・ビルド可能なのが前提 ・ビルド可能だし、テストもパスしているのが前提 にすると、pre-commit hookでやれることもでてくる。 >>155 スキップは例外的にコンパイルエラーが出てしまう場合にも bisectを継続できるようにするための機能であって、常時使うような方法じゃないよ。 コンパイルエラーでスキップしたコミットがあると、当然中身はテストされないので 正確なエラー発生位置がわからなくなってしまう。 結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、 コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。 bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ した事にすればいい。結果的に全部のコミットがコンパイルされる。 git bisect run sh -c ‘make; exit 125’ 勢いで簡単にできるように書いてしまったが、本来の使い方じゃないね。 >>162 だから、何をやらせようとしてるんだよ。 commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。 そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。前提を満たすかどうかのチェックをさせるならまだ分かるけど、それにしたって0.1秒以内に終わる程度の処理しかさせたくないな。 >>165 > だから、何をやらせようとしてるんだよ。 別に何をやってもいいと思うけど。 ローカルな開発環境で、マニュアルで実行していることや、各種タスクランナーにやらせてるようなことを、 commitをhookして自動実行させるのが目的。 > commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。 ひょっとして、数分に一回くらいの頻度でコミットしてるのかな? 1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。 > そもそも、hook側にどんなコミットされるかの前提を持たしたらダメだろ。 前提があるからやる意味がある。 「ビルド可能」なことが前提だとしたら、ビルドをやらせて本当にビルド可能なことをチェックするのも良い。 ローカルな開発環境ではビルドできたけど、リポジトリから取得してビルドするとビルドできないなんて 間抜けなことがなくなる(そして、これはたまに発生する)。 「テストをパスすること」が前提なら、テストを実行させるのも良い。 これも、ローカルな開発環境だとパスするが、そうでないとエラーになるとかありがち。 >>164 >結局スキップされたコミットをエラーの範囲にあるかどうかを確認し、 >コンパイルエラーを直しながら手動で確認する羽目になる。それはbisectの本筋じゃない。 そこが、bisectの経験が無くて分からないんだけど、bisectの結果、最後にコンパイル出来てテストも通るコミットと、その次のコンパイル出来てテストに通らないコミット位置が分かるんじゃないの? その間にあるコミットはコンパイルは出来ないかもしれないけど、分かりやすい単位で分割されているから、バグを特定しやすい気がするんだけど。 >bisectで各コミットをコンパイルするならmakeした上でコミットを全部スキップ >した事にすればいい。結果的に全部のコミットがコンパイルされる。 なるほど、こちらはためになった。 全スキップさせれば、全探索になるのか。 >>166 >> commit hookに相当重い作業をやらせる想定に思えて、役に立つイメージが全く湧いてこないんだけど。 >ひょっとして、数分に一回くらいの頻度でコミットしてるのかな? 作業中は数分間隔でコミットするね。 1日に均しても数回だろうけど。 >1日数回のcommitで、それぞれ数秒程度で終わるなら俺は気にならないけど。 1日数回なら、commit hookに任せずに、自分でコマンド叩くよ。 commitの度に自動ビルド、自動テストなんて、こっちの環境じゃとても耐えられない。 ガイドラインの前提には出来ないな。 hoge-commmit hookが自分にとって役に立たないものかどうかと、commitはビルド可能な ものにしたほうがいいかどうかは別問題。 普通に開発してると、ビルドOKかテストOKが作業の区切りになって、そのときコミットするから、 ビルド不可なものをコミットする人の気持ちもわからないし、デメリットもわからない。 ただ一つ言えるのは、俺はローカルリポジトリのcommit hookは使ってないが、それでも ビルドが通らないものをコミットしようとは思わない。 普通に考えると、ローカルであれこれやりたいときに、どれがちょうど区切りがいいのかわからん 状態だと、作業に支障がありそうだと思う。 commit hookと関係なくビルド不可なコミットを行うケースが想定できないって主張ね。 元々全てのコミットをビルド可能にするかどうかは、最終的に共有ブランチ上に残るコミットについての話だから、個々人が一時的にビルド不可なコミットを行おうがどうでも良かったんだよね。 ただし、commit hookにてビルド可能かどうかを確認することになると、個々人の作業ブランチが影響を受けるから、ガイドラインにするには適当じゃないと考えてる。 作業ブランチ上でビルド不可かも知れないコミットを作る例として、 ・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース ・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース ・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース ・家に帰るので、念のためコミットしておくケース とかが、あった。 上にも書いたように、この状況は最終的にrebaseで解消されるから、 ・分かりやすいコミット分割とコミット毎のコンパイル保障/試験動作保障が両立できない場合にどうするべきか? という、当初の議題とは関係無いんだ。 >>172 俺の感覚だと、 > ・作業途中でブランチを切り替えたい場合のstash替わりにしてるケース いや、stashしろよ > ・ビルド出来ない環境で編集して、ビルド出来る環境へpushするケース 特殊ケースだね > ・ビルドに時間がかかりビルド出来るマシンが限られてるので占有させたくないケース 差分ビルドできない言語は特殊ケース > ・家に帰るので、念のためコミットしておくケース 意味がわからない IDEがgitと統合されてるか、コマンドラインで開発するけど、ビルド・実行可というのが、俺の考える普通。 TDDは確信を得ながら開発を進めていく手法なんだけど、ローカルのcommitが全てビルド可能 (またはテストOK)にしながら開発を進めるのも、同じようなメンタリティな気がする。 俺がローカルであろうと「壊れたcommit」をしたくないのは、そういうことかもしれない。 >>174 別にそのメンタリティを否定するわけじゃ無いけど、gitの運用ガイドラインに入れるわけにはいかんよね。 gitはビルドに時間が掛かる言語では使うな、ってわけにはいかんでしょ。 >>174 ちなみに、TDDで通らないテストの時点ではまだコミットしない? >>176 > ちなみに、TDDで通らないテストの時点ではまだコミットしない? 俺がやってるのはTDD的なものなんだけど、コードと前後してテストを書く場合は、テストが通らないと commitはしないよ。 というか、テストが通らないコードのcommitに、なんの意味があるのかわからない・・・。 いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。 つまり、コミットするときは、すべてのテストが通ってからなのかな? 俺とはコミット頻度がだいぶちがうね。 >>177 便乗して俺も訊きたいんだが、そのコミット前のテストというのは、 単体テストのレベルのこと? つまり、関数一つ作って、その関数の単体テストだけをして、 テストに通ってからコミットという話? (当然、テストを作るのは関数を作る前だが) それとも、今実装している機能に関係した部分の自動機能テストも通ってからコミットするの? 前者なら分かる、俺も同じだから。 >>178 > いや、まだ実装してないから、通らないテストコードだけのコミットをしないのかな、と。 テストもその後リファクタリングするかもしれないから、テストだけ書いてcommitするというのはしない。 ・テストを書く(コードが先の場合もある) ・コードをテストがパスするまで実装 ・テストに改良点があれば改良する ・commit という流れ。 百歩譲ってテストコードをcommitするとしても、TDDで言うRed->Greenの状態でcommitすると思う。 Redの状態でcommitする意義がわからない。 >> 179 > 便乗して俺も訊きたいんだが、そのコミット前のテストというのは、 > 単体テストのレベルのこと? 単体テストレベルというのがTDDのためのUnitTestという意味なら、それ以上のテスト(品質保証の ためのテスト)もだいたい同時期に書くよ(網羅はしないけど)。 >>182 >Redの状態でcommitする意義がわからない commitをまとめるのは容易いけど、分割するのは大変だから、ちょこちょこcommitするようにしてる。 切りが良い時に、rebaseで整理する。 だから、コミットするタイミングでいちいち意義なんか求めないなぁ。 >>183 それ、逆に言うと、「テスト+プロダクトコード」のひとかたまりのcommitを分割したいことがあるということ? 例えば、http://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したくなるってこと? >>184 いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。 >>185 うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。 作業ブランチのコミット履歴は作業履歴も兼ねさせてるから。 正直いろいろ考えずに、トピックブランチをちゃんと細分化して コミットはマージの時に--squashで叩き込めばそれでいい気がしてきた。 >>186 > いまいち伝わってない気がするけど、コミットをどの粒度で整理するかを後から(公開するまでに)考えるようにしたいから、細かくコミットするってこと。 俺の疑問もいまいち伝わってない気がする。 細かくcommitするのが疑問なんじゃなくて、TDDでいるRed状態でcommitしたいのが何故なのかということ。 > うん。面倒でサボるときもあるだろうけど、この段階でコミットしてはいけない、ってルールは許容出来ない。 いけないとは言ってないよ。 なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。 どっちにしろ、あとでrebaseするのは確定なんだし。 知らない人がいると思うのでTDDの説明をしておくと、Red -> Greenというのは 実装完了じゃなくて、テストがパスするためだけの仮実装完了状態。 >>185 の例だと、 public class Money { public int Cents; public double Amount public Money(double amount) { Amount = 20.0; Cents = 2000; } } でGreen。 >>188 >なんでせめてRed -> Greenにまでもっていってからcommitしないんだろうかというのがわからない。 Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。 そもそもcommitするのを待った方がいい理由が分からない。 特にgit初心者に対してはbranchやcommitの概念に慣れさせる意味も込めて、頻繁なcommitとrebaseでも整理をさせた方が良いと思う。 >>190 > Redになる試験を定義出来たってことは切りがいいでしょ。この例だとクラス名を決定したわけだ。 なんか繰り返しになるのでこのレスでこの流れを終わるけど、本当に定義できたかどうかは、 ビルドして実行するまでわからない。typoとかあるかもしれないし。 だから、俺的には、区切りがいいとは思えない。 > そもそもcommitするのを待った方がいい理由が分からない。 これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。 まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。 >>191 >> そもそもcommitするのを待った方がいい理由が分からない。 >これもうざいだろうけど、ビルドできるかどうかもわからないコードをcommitするのに意味を見いだせないから。 commitするのに意味が必要かどうか、って所が相違点な気がするから平行線だろうね。 >まぁ、いつまで会話してもお互い理解できない感じなので、俺からはこのスレで終わるね。 commitしちゃいけない、って意見では無くて、commitする意味が分からないって意見のようなんで、ガイドライン的には関係無さそうなんで、これで終わりでいいだろうね。 とにかく、元々の話はcommit hookで強制するかどうかの話なんだから、強制する気が無いなら、好きにすれば良いで終わる話だしね。 読んでて思ったんだが、TDDやってない人は>>185 のコードで一区切り付くと思うだろうけど、TDDやってると、 185のコードを書き始めてから数分以内に、テストコード編集・コンパイル・テスト実行・コード編集を頻繁に 繰り返すから、>>185 じゃ全然区切りじゃないんだ。 まあ、ローカルcommitの粒度は、個々人がひとまとまりだと思う単位でってことにつきると思う。 開発スタイルやスキルによって、なにがひとかたまりなのかは人それぞれだってことで。 TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ? 作ってすぐ実行する前提だからペアプロでも人が変わる余地はあまりないな >>194 > TDDって、仕様決めてテスト書く人とそれを実装する人が同じって前提あったっけ? TDDのテストコードは、プロダクトコードを書くための手段だから、同じ人がやるのが普通。 というか、違う人が書くなんて話を聞いたことがない。 他人が書かないとかこの機能はどういう入出力あるかわかりましぇーんって言ってることと同意だぞ。 >>199 なんでそんな事が分かる? ローカルではテスト担当の幼女がやってるかもよ。 >>200 Signed-off-by: Karsten Blees <blees@dcon.de> これはこのコードを寄贈しますという意味。 複数の人が関わっている場合はContributions-byで追記したりする。 最後のはJunioさんがgit am -sした時のもの。 プログラムコードが文章で書いてるタイプの糞仕様書を作るくらいなら Spec作ってくれてるほうが意味はありそうだな >>201 幼女は名前を出したく無いのかもしれないし さすがにOSSで「俺テスト書いたから誰か実装して」ってのはないだろう。 >>207 君の周りでは良くあることかもしれないが、普通はそうないよ 大抵は、開発者自身による開発者テストと、開発者自身による後付けのテスト ところによっては、第三者による後付けのテスト これくらい 君の周りではそうないことかもしれないが、普通は良くあること。 >>209 そういう手法でも、そうやってるというブログでもいいけど、いくつか引っ張ってみせろ >>210 そうは言っても、別に興味はないんでしょう? 誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。 gitはそういう使い方も許容するんだからさ。 >>211 > 誰かの周りで良くあることかもしれない、と認められるんなら、優劣を比べてるわけでもないんだから、それで十分でしょう。 俺の周り:その他多数 じゃなくて、 君の周り:その他多数 だって認めてくれればそれでいいよ > gitはそういう使い方も許容するんだからさ。 ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな >>212 >君の周り:その他多数 >だって認めてくれればそれでいいよ 認めるよ。 >> gitはそういう使い方も許容するんだからさ。 >ほう、じゃA氏がテストを書いてB氏がそれを実装するとき、どうやってgitを運用してるか書いてみな * B氏が実装を書いてブランチとして公開する * ソースコードレビューする * B氏が修正する * A氏がテストを書き、テストを実施する * B氏の修正を随時取り込む 運用ってほどじゃないな。 むしろ、なんでGITが特定の開発方法しか許容しないと思うのか? >>213 それ、第三者による後付けのテストじゃん それはよくある 俺が、それはないって言ってるのは>>205 > 俺テスト書いたから誰か実装して 上の方でも、TDDで第三者がテスト書く的なこと言ってる奴もいたし 第三者?登場人物は二人しか出てないけど。 まあ、TDDでなければよくある、って書いてあるんだけど、それは見落としてたわけね。 >>215 自分以外の誰かは第三者じゃないんですか? とかいうのはどうでもいいんだけど、 君が書いたのは「俺がコード書いたから誰かテスト書いて」ってことでしょ 俺がないって言ってるのは「俺がテスト書いたから誰かコード書いて」だ 違いわかんないの? コンパイルエラーくんのあたりから変な奴が増えたな、実際は一人かもしれないけど 事例を引用してこないのは無視した方がいいと思うぞ >>213 俺がテスト書くから君が実装してね じゃダメかね? >>219 > 俺がテスト書くから君が実装してね > じゃダメかね? 実装する俺がテスト書くのが効率的、というのが普通。 それ以外には、テストを書くのもままならない初心者が実装する場合か、自動受け入れテストを 事前に書く場合くらいしか思いつかない。 >>220 ちょっと横道だが… 実装した人間がテストを書くのが効率的なのは間違いないと思うけど、勘違いによる確率を下げるためには、実装した人間とは別の人間によるテストも有効だぞ >>221 この話は>>194 から始まる「TDDでも他人がテスト書くこともある」という話で、そうする人が いるかもしれないが、普通はプロダクトコードを書いた人がTDDのテストを書く方が効率が いいという話。 sourcetreeでgitを使っているんだけど、pullしようとすると if you trust this host, enter "y" to add the key to PuTTY's cache というメッセージが出て止まってしまう ここでyが押せればいいんだけど、SourceTreeはyを押してくれないので どうしたらよいでしょうか! 結局、GitってPull Requestをうまいこと実現するためのツールなんかな >>226 コードについてのレビューは一切やらず、マージも各自が勝手にやるって前提でGit動かしてたんだけどさ Pull Request的な承認フローを組み込まないなら、トピックブランチ切ったり、コミットを履歴いじって細かくまとめても、しんどいわりに対価がなんもないなあって masterなりdeveloptなりに、チケット番号書いたコミットを直に叩き込んでいったほうが、変に分離されてないから横断的な変更もやりやすいし 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか? Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません お SourceTreeで、実行属性やパーミッションを確認する方法を教えてください プログラムの文字コードはEUC-JP でもコミットログはUTF8で書きたい というとき、どういう設定をすれば一番トラブルが少ない? コンフリクトっていつ起きるんですか? ・自分の作業ディレクトリに最新コミットをpullしてくる ・自分が作業して作業ディレクトリの内容が変わる ・誰かがリモートへその人のコミットをpushする。 ・自分がコミットしたいので先にpullする →誰かが進めたコミットがローカルブランチに反映される。 (このときにコンフリクト?) ・自分がpullしたのでaddする (このときにコンフリクト?) ・自分がaddしたのでコミットする (このときにコンフリクト?) ・自分がコミットしたのでプッシュする。 (このときにコンフリクト?) ・自分がプッシュ後念のため再度pullする ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 0DSS1 macbookのターミナルでgitにコマンド入力してるんだけど これってセーブとかしなくて良いの? 良いとしたらどうしてですか? 日本語が変だからやり直し macbookのターミナルにgitのコマンドを入力してますが、これってセーブとかしなくて大丈夫ですか? 大丈夫な場合はどうしてですか? 教えてください偉い人! >>239 何をセーブする話です? (エディタなどの)アプリケーションでのメモリー内での変更を、ファイルに保存するセーブなら、必要です。 アプリケーション内からgitコマンドを操作できるものは、gitコマンドを実行する前に自動でセーブされるはずです。 変更したファイルをリポジトリにセーブしなくていいのか?という意味ならcommitがセーブに相当します。 gitを良くするためにはMicrosoftの関与をシャットアウトしないとダメ .git-version が細かいトラブルの原因 うざい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる