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

Gitをより良くするた� ..

2:デフォルトの名無しさん
15/06/07 13:23:53.40 5CuOmznL.net
少しだけガイドライン考えてみた

・一つのコミットで複数の修正を行わない
理由後からそのコミットを見た時何を修正したのかがわからなくなるから
・一つの修正を複数のコミットにわけない（分かれていればまとめる）
理由後からそのコミットを見た時何を修正したのかがわからなくなるから
例外リリースしてしまったコミットはまとめることは出来ない。

いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。

と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。

3:デフォルトの名無しさん
15/06/07 13:24:21.46 5CuOmznL.net
>>585
> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
いないだろｗ
あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。
物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。
コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。
そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。
このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない

4:デフォルトの名無しさん
15/06/07 13:24:51.14 5CuOmznL.net
念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。
俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。
つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね

5:デフォルトの名無しさん
15/06/07 14:58:24.31 iOpTlduD.net
まともなGUIマダー？

6:デフォルトの名無しさん
15/06/07 15:29:21.05 +aAn4ks1.net
Visual Studio内蔵のGitのインターフェースは最初わけわからなかった

7:デフォルトの名無しさん
15/06/07 15:30:09.05 o+m9rMyT.net
　　　　　　M.ﾊ从人ﾉヽ
　　　　　　ｲﾘ　　　　　　ﾉﾘ,, 　　　　「ウンコはトイレでしろ」
　　　　　ﾒ　＿,,,,,,,,,,,,,,,,,,,_　.K 　　　こういう凝り固まった脳みその奴って出世できなさそうだよな
　　　　　ﾒ　i　　　　　　　 7 .K 　　　こんなバカがウンコしたい時にトイレ探し回ってるの見ると爆笑もんだわ
　　　　　ﾖ .y -一　　ー- !,　f 　　　トイレなんてただ座ってウンコをするための部屋にすぎないんだよ
　　　　　r! .!. ｨtｧ　　 tｧx .!.¥ 　　　　喉乾いたら何が何でも喫茶店入らなきゃいけないって訳じゃないだろ
.　　　　　!,Y　　　　　　　 f .! 　　　　探せば自販機もあるしコンビニもある
.　　　　　] 　　､.`ー' .,　 .├' 　　　喫茶店も座って落ち着いて飲み物を飲む部屋にすぎない
.　　　　　 !,　　￣￣　　 .ﾊ　　　　つまりウンコしたくなったらトイレを必死で探す奴は選択肢を考えられない馬鹿
　　　　　　/ゝ,　　　　　,ノ　ヽ,
　　　　／/.　 i｀ﾞ'''''''''"´ /　　|＼,＿_,,,,,,
　　⌒　 /　　 ',　　　　 /.　　　|　　　　　ヽ

8:デフォルトの名無しさん
15/06/07 15:43:30.20 uZ5MlZ27.net
運用で対処するより、Gitそのものが良くなる方がいいんじゃないかな？(´･ω･｀)

9:デフォルトの名無しさん
15/06/07 16:22:05.50 5CuOmznL.net
>>8
Gitの適切な運用方法を語るスレだよ。
「Gitをよりよく使うための運用ガイドライン」にすればよかったかな。
Gitに問題があるって話じゃない。
Gitのコマンド体系はもう少し改良の余地があるとは思うが
機能自体には問題ないよ。
Gitは運用方法（フロー）をがっちり決めているわけじゃなくて、
git-flowとかgithub-flowとか細かいフローがあるが、
それでも基本的な考え方というのはある。
使いにくいと思ったら、使い方が悪いと考えた方がいい。

10:デフォルトの名無しさん
15/06/07 16:23:04.79 5CuOmznL.net
>>5 >>6
すれ違い。そういう雑談はこっち。
Git 12(c)2ch.net
ｽﾚﾘﾝｸ(tech板)
ここはgit-flowやgithub-flowと言った
gitを使った運用方法を語るスレ。

11:デフォルトの名無しさん
15/06/07 16:33:06.80 uZ5MlZ27.net
スレの主旨を適切なタイトル名として表せないような能力しかない人間が
立てたスレって…役に立つの？(´･ω･｀)

12:デフォルトの名無しさん
15/06/07 16:33:20.22 5CuOmznL.net
ちょっと出かけなきゃならなかったからとりあえずスレを立てたが、
テンプレ作りたいね。Pro Gitは当然として各運用フローのリンク
公式がよくわかんないんだけどこれでいいんだろうか？
・Pro Git
英語 URLﾘﾝｸ(git-scm.com)
日本語 URLﾘﾝｸ(git-scm.com)
・git-flow
URLﾘﾝｸ(nvie.com)
・github-flow
URLﾘﾝｸ(scottchacon.com)
・gitlab-flow
URLﾘﾝｸ(about.gitlab.com)

Qiitaのリンクを貼るのはあまりすきじゃないんだが、簡単にまとまってたので
テンプレに入れるかどうかは別として、とりあえず
Git利用時のフローはどれを使うか
URLﾘﾝｸ(qiita.com)

13:デフォルトの名無しさん
15/06/07 16:34:58.87 5CuOmznL.net
そしてスレ盛るために転載（笑）
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と比べると
　　・ブランチ間の移動や、複数ブランチへのマージの発生量が多くなりがち
　　・一定期間終了した後に全ブランチの遷移などを俯瞰すると開発の様子がわかりやすくて良いかもしれない
　　・一方で、開発中は開発者の負担が少し多くなるかもしれない

14:デフォルトの名無しさん
15/06/07 16:35:55.49 5CuOmznL.net
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へ反映

15:デフォルトの名無しさん
15/06/07 17:32:26.76 R6yntEB+.net
何かバグフィクスしてる時、全く関係ないけどちょっとした修正個所を見つけて思わず直してしまい、
そのまままたバグフィクス作業に戻って最後にコミットする段階になった。
>>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・
さて、どうしたものか。

16:デフォルトの名無しさん
15/06/07 18:59:18.07 adsRb63z.net
>>2
なんだこの馬鹿ルールは。

17:デフォルトの名無しさん
15/06/07 19:09:30.35 dAMefaMD.net
まだ機能がロクにできあがってない完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど
svnみたく基本master直コミットで、切りたいときだけ適当に切る感じでやってる？

18:デフォルトの名無しさん
15/06/07 19:31:57.73 5CuOmznL.net
>>15
> >>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・
それは当然分けてコミットするべきだよ。
実際の開発でもよくある話で、スペースでインデントするという
規約なのに間違えてタブになっていたりね。
そういうのがバグフィックスに含まれていると、本当にしたかった
バグフィックスのコードは何なのかわからなくなってしまう。
別コミットにした上で、バグフィックスとは分けてマージしてしまうのがいい。
本当に「ちょっとした修正」であればバグフィックスと違って、
レビューはほぼ不要でマージできるはずだからね。

で、聞きたいのはコミットを分割する方法？
Pro gitにも書いてあるけどこんな感じだよ。
コミットの分割
URLﾘﾝｸ(git-scm.com)コミットの分割
1. git rebase -i で edit を指定して修正したいコミットで止める
2. git reset HEAD^ で修正したいコミットを未コミット状態に戻す
3. ちょっとした修正だけコミットする（git add -p などを使って）
4. バグフィックスをコミットする
5. git rebase --continueでrebaseを完了させる

19:デフォルトの名無しさん
15/06/07 19:32:23.65 5CuOmznL.net
>>16
分かったから、理由ｗ　理由ｗ

20:デフォルトの名無しさん
15/06/07 20:02:06.44 5CuOmznL.net
>>17
> svnみたく基本master直コミットで、
いやいやｗ svnでもmasterに直コミットなんかしないってｗ
（個人プロジェクトとか超小規模は除くけど）
まだsvn使ってる有名プロジェクトって何があるんだろう？
例としてtracを見つけてきたけどマージのほうが多いでしょ？
URLﾘﾝｸ(trac.edgewall.org)

> まだ機能がロクにできあがってない完成前の作成中の段階って
疑問なんだけど、その作成中の段階のソースコードってどこにあるの？
まさかローカルのPCにあって、他の人はだれも見れない状態？
その機能を作るのに1日かからない程度の小さい修正なら、他の人が見れない状態でも
たいしてリスク無いと思うけど、数日とか数週間かかるようなものが
他の人が見れなかったらリスク高くなるよね？
作成に数日かかった大作を見せられて、それがクソコードだったとき、全部やり直しになってしまう。
だから少なくとも一日に一回はコードを他の人が見れるようにしないといけない。
そのコードは作成中なのだからmasterに入るわけがない。
ではどこに？ → その答えがブランチでしょ？
> 完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど
ということで「完成前の作成中の段階」と呼べる状態があるのなら、それがブランチになるんだよ。

21:デフォルトの名無しさん
15/06/07 20:31:56.38 dAMefaMD.net
>>20
最初のほうでもみんなトピックブランチみたいなの作業ごとに切って作業してるのかなあって思って
ただ最初は1個が本当に数週かかるし、ある機能が複数人に影響するのも多いから、それをいちいち各人が自分のブランチにマージするのかって考えると
1個のブランチにみんなで直接コミットしまくったほうがよくない？とも思ってどうしてるのかなあと

22:デフォルトの名無しさん
15/06/07 21:04:30.29 5CuOmznL.net
>>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)のコードが必要なのだから、見たいはずだよね？
でもブランチを作らなければそれができない。

23:デフォルトの名無しさん
15/06/07 21:11:03.05 5CuOmznL.net
>>21
で、なんで君が「1個のブランチにみんなで直接コミットしまくったほうがよくない？」と
思っているのか、その理由はわかってる。
直接コミットをすれば、すぐに他人のコードが「1個のブランチ」に取り込まれて
他の人はそれをすぐに利用できるからいい。と思ってるはず。
逆に言えば、（トピック）ブランチを切っていれば、そのブランチが
「1個のブランチ」に取り込まれるまで時間がかかる。
それぞれの開発者が、それぞれのブランチをずっと成長させていき、
その他人のブランチを、時々取り込まないといけなくなる。と思っているはず。

それはトピックブランチの扱いを間違っているだけだよ。
トピックブランチでやる内容は凄く小さい。
トピックブランチは頻繁に「1個のブランチ」にマージされる。
みんなが直接コミットしまくるのと同じぐらいの頻度で
「1個のブランチ」にマージされるんだよ。

ちなみに「1個のブランチ」がmasterであるか、次期リリース用ブランチであるかは
gitフローなのかgithubフローなのかによって変わる。

24:デフォルトの名無しさん
15/06/07 21:19:06.14 5CuOmznL.net
>>21
君が抱えている問題を解決するヒントを一つ提示しよう。
ある機能を作ることになった。その機能のために1つのブランチを作る。
（ここまではsubversionでも一緒だろう）
そしてそのブランチを作っている間に、ある便利な関数を作った。
その便利な関数は、他の人も使う。
のであれば、君が作っているある機能の完成を待たずして、その便利な関数だけをマージする。
出来上がった所から取り出して、早くマージしてしまえばいいんだよ。
（こういうことがsubversionではやりにくい）

この発想ができるようになれば、中途半端なコードをマージすることもないし、
みんなで直接コミットしまくるのと同じように頻繁にコミットできて
それをするために、自分の作業履歴（コミット）を自由に入れ替えて
歴史を修正することができるgitの重要さが理解できるようになる。

25:デフォルトの名無しさん
15/06/08 14:47:51.52 kFqfXqDD.net
糞スレ終了

26:デフォルトの名無しさん
15/06/08 19:42:50.61 +yUhk8xr.net
俺ルールを押し付けんなクズ >>1

27:デフォルトの名無しさん
15/06/08 20:36:08.82 yR6yCENO.net
やれやれ。荒らしたい奴は来なければいいのに。
なんのためにこっちに移動したのか？

28:デフォルトの名無しさん
15/06/08 23:37:37.11 IKTjq6kL.net
>>1の説明は論理的で分かりやすいです。
質問に対して、自分のガイドラインに従った場合の解決方法をちゃんと示しています。
何を重要視しているのかが明確に示されていて、それが自分に合う人にはとても参考になると思います。
>>25や >>26 などは、たぶん合わなかったのでしょう。
Git人口はとても多いので、当然そういう人も大勢いると思います。
彼らが従うガイドラインも見てみたいです。

ちなみに私は >>15 ですが、とても参考になりました。

29:デフォルトの名無しさん
15/06/09 08:21:36.47 EBIaYtJo.net
なぜグローバルなガイドラインを語らずに身勝手な自分ルールを持ち出すの？
独り言はツイッターでやってろ

30:デフォルトの名無しさん
15/06/09 08:48:52.69 +d7EQhmV.net
> なぜグローバルなガイドラインを語らずに
なにいってんの？グローバルなやり方を説明してるだけなんだが。
OSSのmasterのマージコミット（単なるコミットではなく）を見てみろよ。
マージコミットの中で、typoの修正とかありえないし
コミットの内容もその順番も明確になってる。
開発でそんな綺麗に作業なんて出来ないし、
そもそもマージ前にレビューがはいるのはやり直す必要がある場合が多いから。
そのやり直しを感じさせないぐらいに綺麗に整理されてからマージされてるんだよ。

31:デフォルトの名無しさん
15/06/09 08:59:54.69 +d7EQhmV.net
>>28
どうもどうもｗ
git歴は2年ぐらいかな。当初というかgit始める前から
可読性ならず可レビュー性を重視していたからね。
Subversion使ってる時にレビューしていて、
あれ？この修正不味くない？
あー、あとのコミットで修正されてるのかー！
みたいなのとか
いきなり一週間分の修正をまとめて持って来られたって
解読に時間掛かり過ぎる、細かく分けて持ってこいよ。
とか
これじゃレビューできるわけ無いよね。みたいなのをどうするかを考えていた。
Subversionでも出来ないことはないんだが、いちいちネットワークにつないで
何度も送信しないと行けないからストレスが溜まる。gitだとそれを素早くやれる。
それを元にいろんなOSSの履歴を見ながら、それに近いことを実現する
フローはどういったものかを考えてまとめたのがこのスレで俺が言ってることだよ。

32:デフォルトの名無しさん
15/06/09 20:11:31.07 xVQhQgen.net
>>30
一個でも良いから、具体例を一つリンクしてくれないかな？

33:デフォルトの名無しさん
15/06/09 20:23:04.85 JtxCFe8d.net
グローバルだからってどんな現場にもgit-flowを当てはめるような思考停止は
設計できないデジドカっぽくって嫌いだね

34:デフォルトの名無しさん
15/06/10 01:24:43.72 7XQM9Exq.net
>>32
gitの使い方の具体例なら、gitプロジェクトでいいでしょｗ
目指すはこんな感じのコミットログだよ。
URLﾘﾝｸ(github.com)
masterにマージされるのは、無駄のないきれいなコミット。

あとは、マージされたPull requestsの方をみればいいんじゃないかな？
URLﾘﾝｸ(github.com)
マージを許可されるブランチというのは、どうブランチであるべきかってのがわかる。
だいたいは小さな修正でコミットも一つだけど、複数のコミットからなるブランチもある。

これなんか1つのファイルに対して18個のコミットで修正しているけど、
それぞれのコミットが、ちゃんとタイトル通りの内容で少しずつ修正されており
何をしたのかわかる可読性の高いブランチになってる。
URLﾘﾝｸ(github.com)
「一つのファイルの修正だからって全部まとめたら何やってるのかわからんだろうが」と言われない良い例だね。

35:デフォルトの名無しさん
15/06/10 01:25:37.35 7XQM9Exq.net
>>33
どのフローであっても、ゴミコミットは入れない。
コミットは後から見てわかるように可読性が高い綺麗なものにして
マージするっていう点は全部一緒だよ。

36:デフォルトの名無しさん
15/06/10 01:34:04.91 7XQM9Exq.net
>>34はちょっとミスった。
これマージされなかったブランチかｗ
まあ綺麗に整理されてるってのは間違ってないけど。
代わりにマージされたもので複数のコミットからなるやつを持ってきたよ
URLﾘﾝｸ(github.com)

例の有名な記事にかいてあったやつだけど
Why I Won't Squash My Commits
URLﾘﾝｸ(blog.marc-andre.ca)
[翻訳] 私のコミットをまとめないで
URLﾘﾝｸ(qiita.com)

37:デフォルトの名無しさん
15/06/13 08:37:25.33 P6q2Jefi.net
つまり、誰もが「無駄かどうかを決めるのは俺様(ｷﾘｯ」て言って譲らないから
Ｇｉｔは有効に使えるツール足り得ないってことだよね？(´･ω･｀)

38:デフォルトの名無しさん
15/06/13 08:41:32.10 NUKk6CPY.net
その通り
馬鹿には無理

39:デフォルトの名無しさん
15/06/13 10:00:00.52 Ih37w7wT.net
業務用のシステムを管理するには？どういう方法が良い？
初期開発は良いとしても
本番リリースした後は
本番稼働のもの
本番でバグが発覚（複数）して対応中
改良もはいってる
とかになるとどう分けていつコミットやプッシュするべき？

40:デフォルトの名無しさん
15/06/13 10:02:40.72 2dbaYd91.net
ただ使うだけならコマンド叩くだけなんだからなんも考えんでも使える
gitの本当に難しいところは、自分のプロジェクトでどう使うか

41:デフォルトの名無しさん
15/06/13 12:33:55.09 2XvJk2DZ.net
>>39
それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。
バグをどうリリースするかはバグの内容による。改良のリリースも同じ。
緊急で出さなきゃいけないものは緊急で出す。
そういうのは見つかった段階ですぐに対応しなきゃいけないから
最新のリリース版からブランチを切って作ったブランチをリリース版にマージ。
そしてそれを開発版にもマージって流れになるだろうね。
あとはブランチ（＝バグや新機能）をリリースしたい順にマージ[*]していけばいい。
よくあることだが、新機能がバグの修正に依存しており、新機能の作成中に見つかった。
という話しなら、先にバグを直して（バグ修正ブランチを作ってマージ[*]）、
そこから新機能を作ったことに歴史を書き直せば良い。
[*] の部分だがどこにマージするかは方針と内容次第。
すぐにmasterにマージすることもあるし「次期バージョン」という考え方を
しているのなら次期バージョンブランチを作って、そっちにマージしていって
リリース時にmasterにマージを行う。

42:デフォルトの名無しさん
15/06/13 12:40:50.27 2XvJk2DZ.net
ただし大型新機能の開発が複数並行で進んでおり、両方が同じ部分を修正する
可能性が有る場合、大量のコンフリクトが起きる可能性があるので注意する必要がある。
これを避けるために新機能が完成するまで新機能の内容を"全て"マージしない
という考え方を変える必要がある。
多くの場合、新機能の開発の中には、既存バグの修正やリファクタリング
モデルや汎用ライブラリなどの機能追加（仕様変更ではなく）が含まれる。
これらは先にリリースしても問題ないはず。全てマージしないのではなく一部だけマージする。
だから新機能の開発を行っていたとしても、そのなかで先にリリースできるものはリリースしておく
（次期バージョンブランチがあるのならそっちにマージ。次期バージョンブランチと新機能ブランチは別ね）
こうすることでいち早く大型新機能開発はコンフリクトが起きかねない部分を知ることができるし、
相手の開発した部分を利用することも可能になるから、同じものをそれぞれで作ってしまう無駄も省ける
大型新機能開発を行っていたとしても、小さな開発とリリースという形に変更していくことは可能なんだよ。

43:デフォルトの名無しさん
15/06/13 12:44:26.69 2XvJk2DZ.net
自己レス
> それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。
この話につながっていなかったｗ
まあわかるとは思うけど、このように開発の順番とマージやリリースの順番を
自由に入れ替えるってことは、それぞれのコミットが意味のある単位で
細かくまとまってなきゃいけないんだよ。
無関係の修正が一つのコミットに混じっていたり、
関係あるコミットが複数に分かれていたりしたら
それを見つけるのが大変になる。
ちゃんとコミットが分かれていれば、開発した順番ではなく
望む形に入れ替えたりすることがしやすくなる。

44:デフォルトの名無しさん
15/06/13 16:39:52.58 2dbaYd91.net
コミットを細かくってのは、簡単なようでいざやると相当難しいんだよな
これがすっきりできれば後はどんなフローにも載せられるんだろうが…

45:デフォルトの名無しさん
15/06/13 18:45:02.69 5sBiyJnB.net
一生バージョン管理やってろw

46:デフォルトの名無しさん
15/06/13 19:15:52.26 2XvJk2DZ.net
>>44
たしかにね。最初はちょっと難しかった。
コード修正中に関係ないことをついついやってしまうしｗ
そこは慣れだよ。意識してコミットを小さくするようにしていけばいい。
まず覚えるべきなのは、git add -pだね。
これができると一つのファイルの中の一部分だけコミットできる。
あとはコミットの順番は後から並び替えられるし、まとめることもできるので
順番は気にせずにほんとうに小さくコミットを作ること。
そして後からまとめて綺麗にしようと考えずに、常に片付けながら作業（開発）すること。
後からまとめてコミットを綺麗にしようと思って、そこで何したか忘れるんだよｗ
大きな開発を複数人でスムーズに行うには、共通のソースコードへの修正の
反映作業が重要だからね。大きな開発も小さく修正していくことで管理可能になる。
それを実際にやってるのを見れるのがgithubとかなんで（まともなプロジェクトの）
リポジトリを参考にするといいよ。

47:デフォルトの名無しさん
15/06/13 19:44:46.87 Ih37w7wT.net
>>46
まともと思える物を紹介して
参考にしたい

48:デフォルトの名無しさん
15/06/13 19:51:47.81 2XvJk2DZ.net
>>47
だからgitだってｗ
gitを一番うまく使ってるのは
gitプロジェクトに決まってるでしょｗ

49:デフォルトの名無しさん
15/06/13 21:26:31.06 ZkFtP6do.net
>>1 のスタンスで詳しく書かれた Git の書籍はないですか。
洋書でも構いません。

50:デフォルトの名無しさん
15/06/13 21:28:47.45 ZkFtP6do.net
>>49
紛らわしいので言い直します。
>>1 の人のような考え方を詳しく解説した書籍はないでしょうか。
洋書でも構いません。

51:1
15/06/13 22:30:36.68 2XvJk2DZ.net
>>49
残念ながら知らない。日本の本に関しては、最近出た2,3冊は内容を確認してないけど、
それ以前のものに関してはgitの使い方ぐらいだったな。それはそれで最初のうちは
役に立つんだけど。海外の本に関しては、読んでないので知らない。

代わりに日本と海外（アメリカ）の考え方の違いの話をするよ。
よく言われていることだけど、海外はパッケージの導入を積極的に行うけど、
日本は独自で作ったりパッケージをカスタマイズすることを望む。
この考え方の違いというのは、日本は自分のやり方を通そうとするということ。
日本の文化だと、アプリにがあれもこれもなんでも出来るようになってしまう。
それは一見便利なように見えるけど、業務を改善（＝変えていく）ことにはつながらない。
やり方を変えずにツールを変えるだけだから生産性は上がらない。
海外のソフトウェアっていうのは、業務を一番効率的にやれるのはどういうものか？
という考えを形にしたものなんだ。もちろんその考え方はいろいろあって正解とは限らないけど、
少なくともソフトウェアっていうのは、開発者が想定した正しい使い方っていうのがあるんだよ。
つまり俺の考え方というのは、ツールの正しい使い方というのを学習していくことでできたもの。
ツールにはできること、できないことってのがあるけれど、思いつくまま実装されたのではなく、
正しい使い方をするのに、必須だから追加した機能であり、邪魔だから追加しないと考える。
例えばgitには歴史を改ざんできる機能があるでしょ？これは正しく使うのに必須だから。
ファイルをロックして他人が編集できないようにする機能はないでしょ？
それは正しく使うのに邪魔だからあえて搭載しないことを選んでいる。
この開発者の考えに、自分の考えが適合してくると、「こんな機能があったほうがいいんじゃないか？」って
思ったものが次期バージョンに搭載されたり、議論が行われていたりする。
考え方が合わない最初のうちは、なんでこうなってるんだ？使いにくい！って思うかもしれないけど
そうではなく意味があってやってることだと考え、何故そうなっているかを考えていくといいよ。

52:デフォルトの名無しさん
15/06/13 22:43:28.86 2XvJk2DZ.net
>>49
もう一つgitよりの話をすると、gitは誰が何故作ったのかを考えればわかると思うよ。
リーナスがソフトウェアを開発するために作ったよね？
そう、開発者のものなんだ。
開発の進捗を知るためのマネージャーのツールでもないし
ソフトウェアのロストを怖がる管理者のツールでもない。
ソフトウェアの開発、しかもそれを多くの人が関係するってことは
正しい修正であるかどうかを判断するには、ソースコードを読まないといけない。
頭数を揃えてテストしたって、正しい修正であるかなんてわからない。
どっかの金もってる大会社じゃないんだから、頭数自体揃えられないけどｗ
そういう文化にとって「テスト」とは誰でも（一人でも）テストの実行を再現可能な
テストコードであり、そのテストコードが正しいかどうかは、読んで判断するもの。
それ以外できっこないんだから。これは現実。
そこまでわかれば、あとは何が必要かがわかる。必要なのはコードが読みやすい
コミットであり、必要なツールは読みやすいコミットを作ることが出来るもの
そういう考えでgitが必要とされ生み出された。あとはそのgitの正しい使い方を理解していくだけだよ。
ただ一つだけ俺がラッキーだったのは、gitを知る以前から、読みやすいコミットの重要性を理解していたことかな。
完成されたソースコードだけじゃなくて、修正の内容とその過程自体もわかりやすいことが重要であると。
だから俺にとっては、gitは俺が考えた理想を実現するツールだったね。

53:デフォルトの名無しさん
15/06/14 09:57:57.81 wRqn8b2I.net
後からコミットログは簡単にまとめられて、逆に分割は困難なことを考えると
上書き保存するたびに即コミットぐらいでやるほうがいいのかなあ

54:デフォルトの名無しさん
15/06/14 10:12:42.73 d62hq9+6.net
休憩や今日の終わりの度にコミット？
動かないコミットは嫌だな

55:デフォルトの名無しさん
15/06/14 11:12:44.05 gLTCEjdN.net
git って ID:2XvJk2DZ みたいな信者が沸くところが嫌なんだよね
理想に最も近いとか言うならまだわかるけど、理想を実現したとかちょっと気持ち悪い

56:デフォルトの名無しさん
15/06/14 11:38:15.57 M4xMa8us.net
>>53
それでもいいぐらいだよ。ただコミットを整理せずに
放置しておくと何したのか忘れるので整理しながら作業した方がいい。
分割は面倒だけど困難というわけでもない。
やり方は色々あるけど、rebase -iの途中で分割作業をするから
（つまりある作業中に別の作業をするようなもん）
少し慣れが必要だけどね。

>>54
masterに入れるのは動くコミットに決まってるでしょｗ
トピックブランチなどは最終的に消すものなのだからどうでもいい。
誰が作ったそのルール？コミットはどんなものでも
動くようにしろとか、変な自己ルールに縛られすぎだよｗ
理由があるからルールができる。理由を説明できないような
ルールを作らない方がいいね。
>>55
うん。それで？
なにか間違っているとか、もっといい案があるなら
どんどん言っていいんだよ？

57:デフォルトの名無しさん
15/06/14 11:58:20.38 d62hq9+6.net
>>56
ならあんたのルールをここで公開してくれよ
採用考えるわ

58:デフォルトの名無しさん
15/06/14 12:02:28.86 M4xMa8us.net
>>57
1からずーっと書いてきてる。
読みなおしてくれ。

59:デフォルトの名無しさん
15/06/14 12:08:41.21 d62hq9+6.net
>>58
ずーっとってお前の発言は識別出来んわ
コミットしてくれー
だとコミットの使い方が違うか

60:デフォルトの名無しさん
15/06/14 12:10:30.52 M4xMa8us.net
>>59
既に>>2で具体的に書いてるじゃないか？

61:デフォルトの名無しさん
15/06/14 12:11:32.71 M4xMa8us.net
>>59
「コミットを意味があるように綺麗にしておけ」とは言っているが
その中で「コミット」という単語しか見えないのか？

62:デフォルトの名無しさん
15/06/14 12:14:40.91 d62hq9+6.net
>>60
おいおい1からずっと書いてるから読めって
2がまとめかよ
しかもあれで具体的だなんて
ちゃんと仕事で複数人で活用してる人？
一人とか小さなものでやってるだけ？
なら、お前が書けと言われても作れていないから書けない、悪いがな

63:デフォルトの名無しさん
15/06/14 12:18:45.44 d62hq9+6.net
もしかして、このスレって
自称優秀なPG様が作っているスレ集の１つだったか？

64:デフォルトの名無しさん
15/06/14 12:18:58.06 mvvCE6hZ.net
長文自分語り
しかも中身はオレオレ規約
きめぇ

65:デフォルトの名無しさん
15/06/14 12:26:04.87 M4xMa8us.net
>>62
2がまとめじゃなくて、2が基本てな原則だよｗ
その後は>>2の補足をしたり、もっと具体的に踏み込んだ説明をしている。
あれで具体的って、お前やっぱり>>2しか見てないじゃないかｗ
だからちゃんと1から読めって言ってるんだが。
> ちゃんと仕事で複数人で活用してる人？
当たり前だろｗ逆に一人でやるなら適当にやればいいだろ。
自分の書いたコードだったらコミットが汚くてもわかるんだよ。
でも他人の書いたコードのコミットが汚かったらわからないだろ？
レビューしてくださいって来たコードが、何百行もある大作1コミットだったら
レビューなんてできるわけないし、小さく分かれていても複数のコミットで
同じ行を修正していたりしたら、無駄なレビューをすることになる。
レビューするためには、ソースコードを綺麗にするだけじゃなく
コミットの内容も綺麗である必要がある
俺の話は複数人だからこそ必要な話をしてるんだが。
多くの人、それぞれスキルは違うし、悪意がある人迄いる可能性がある
オープンソースを見てみなさいよ。
適当なコミットはレビューできないから、そういうのはマージされないよ。
知った人間ばかりの会社内のやり方とはわけが違う。
会社内だとコードのが意味不明でも上司だからとか、あの人なら大丈夫だからとか
よくわからないけど、動いてるみたいだからいいんじゃね？
コミットが汚くてもろくにレビューもせずに適当マージしてるでしょ？
俺の意見は最初から一貫して、レビューが可能なように綺麗なコミットにしろって話をしてる。

66:デフォルトの名無しさん
15/06/14 12:27:55.94 d62hq9+6.net
>>65
59へ戻る

67:デフォルトの名無しさん
15/06/14 12:29:08.27 M4xMa8us.net
>>64
それで？
そんなものよりもっといい案が有るなら
それを言ってくれよ。
自分の意見を言わない奴に
発言する権利はないよ。
ミーティングと一緒。
ミーティングで誰かの意見に対して
「あなたの提案の内容に関してですが、
あなたの発言がキモいです。」
とか言ったら嘲笑ｗ

68:デフォルトの名無しさん
15/06/14 12:29:28.83 M4xMa8us.net
>>66
どうぞ戻ってくださいｗ
はい、つぎ。

69:デフォルトの名無しさん
15/06/14 12:30:36.40 M4xMa8us.net
gitのコマンドはわかるんだけど
gitをどのように使っていけばいいか悩んでいる人
相談に乗りますよー。

70:デフォルトの名無しさん
15/06/14 12:32:34.02 d62hq9+6.net
やっぱりよく見るパターンだったな
自分語りのために無駄スレ作ってないで
ちゃんと会社の人とルール共有しろよ

71:デフォルトの名無しさん
15/06/14 12:34:05.28 M4xMa8us.net
>>70
会社に人と共有しているルールというか
考え方を書いているだけですが？
それであなたの考え方は？
それがないとあんたはただの荒らしでしかないよ。

72:デフォルトの名無しさん
15/06/14 12:36:23.99 d62hq9+6.net
話し合いにも討論にも雑談にさえならないのは目に見えてるから遠慮しとく

73:デフォルトの名無しさん
15/06/14 12:37:48.19 ByqCHqi5.net
そういやうちの会社にはいないけど、
よく聞くじゃん？
上の立場の人が、でてきた意見を何の理由もなく否定する人。
きっと自分の考えを書かずに否定する人って
上の立場になったら、そういう人になるんだろうなって思った。
ドラマや小説で悪役として描かれる
そういう上司。

74:書込しすぎたからID変えたって書くの忘れた
15/06/14 12:39:12.98 ByqCHqi5.net
>>72
バイバイｗ
俺にしてみれば、お前をあぼーんしたのと同じだから
それがお互いにいい結果。
意見がないならもう来ないでね。
意見があるのなら来ていいですよ～ｗ

75:デフォルトの名無しさん
15/06/14 12:43:40.24 jf78czBd.net
>>67
すごく良い発言があるよ
「あなたの提案の内容に関してですが、
あなたの発言がキモいです。」
とか言ったら嘲笑ｗ
だよなー
でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」
だな

76:デフォルトの名無しさん
15/06/14 12:45:15.73 ByqCHqi5.net
>>75
> でも今は、「あなたの発言に関してですが、発言内容以前にあなたそのものがキモイです」
わろたｗ
２ちゃんねるだからいいとして、
そんなの会社でやったら即刻クビだろｗ
ホントこいつ発現する意味ないわーｗ

77:デフォルトの名無しさん
15/06/14 12:55:28.35 d62hq9+6.net
>>74
おまえだれ？
少し前に指摘したことさえ忘れたの？

78:デフォルトの名無しさん
15/06/14 13:01:59.00 ByqCHqi5.net
少し前に指摘した人だってことをわかってるのに、
誰って聞いてるのはなんなんだろうなｗ
そんなのどうでもいいだろう？
ここにはgitに関する意見を書けよ。

79:デフォルトの名無しさん
15/06/14 13:03:37.00 l6qAkUnh.net
>>54
>動かないコミット
開発ブランチは分けろω

80:デフォルトの名無しさん
15/06/14 13:08:29.35 d62hq9+6.net
>>79
こまめなコミットって意見あったけら言ったんだが
開発ブランチなら、動かないコミットも許す？
開発ブランチは個人ごと？ローカルコミットだから人に迷惑はかけない？
マージしたら凄いゴミコミットの山では？
など疑問は多い

81:デフォルトの名無しさん
15/06/14 13:13:55.53 ByqCHqi5.net
>>80
少しは考えたほうがいいよ。
なぜブランチはあるのか？
なぜ動く必要があるのか？
開発ブランチは個人ごとである必要があるかないか
何をしたら人に迷惑で何が迷惑でないか
疑問があるのなら、他の人はどうやっているかを考えればいい。
世の中にサンプルはいくらでもある。
前にも答えたけどgit自体のリポジトリを見るとか。
有名プロジェクトであれば、そこがやっているやり方には
何かしらの理由がある。
疑問が多いってことは、その疑問に対して
自分で何も考えてない証拠だよ

82:デフォルトの名無しさん
15/06/14 13:15:57.16 d62hq9+6.net
>>81
お前は黙っててくれるかな

83:デフォルトの名無しさん
15/06/14 13:16:43.89 ByqCHqi5.net
>>82
いやです♪

84:デフォルトの名無しさん
15/06/14 13:17:27.34 ByqCHqi5.net
ちなみに>>80の疑問に関して言えば
俺は既に答えが出てる。

85:デフォルトの名無しさん
15/06/14 13:44:31.97 ByqCHqi5.net
d62hq9+6はどうやら俺にレスして欲しくないようだし、
他の人の意見も聞きたいから>>80に答えるのは
明日ぐらいにしようかな。IDが変わってからｗ

86:デフォルトの名無しさん
15/06/14 15:53:01.11 kgtEwFOS.net
>>34
githubの画面からはよく分からなかったから、ようやくcloneしたけど、mergeコミットと単なるコミットってどういう意味で呼び分けてるの？

87:デフォルトの名無しさん
15/06/14 16:10:14.38 eC56/Xbq.net
> mergeコミットと単なるコミットってどういう意味で呼び分けてるの？
呼び分けるも何も、
マージコミットと単なるコミットは別物だけど？
URLﾘﾝｸ(git-scm.com)
> 単にブランチのポインタを先に進めるのではなく、Git はこの三方向のマージ結果から
> 新たなスナップショットを作成し、それを指す新しいコミットを自動作成します (図 3-17 を参照ください)。
> これはマージコミットと呼ばれ、複数の親を持つ特別なコミットとなります。

88:デフォルトの名無しさん
15/06/14 16:12:36.55 eC56/Xbq.net
>>86
明らかに違うものとしてgitで管理されていることを示すために
URLﾘﾝｸ(te2u.hatenablog.jp)
> この状態でrebaseを行うときに-iオプションだけでは
> マージコミットは含まれない。マージコミットがあるときは
> -pオプションをつけて実行すると
> 指定した範囲のマージコミットが含まれる。

このように、rebase -iコマンドには
マージコミットという特別なコミットを
含めるか含めないかのオプションが有る

89:デフォルトの名無しさん
15/06/14 20:28:40.57 2Vz7+5/W.net
>>30で単なるコミットではなくマージコミットを見ろって言ってるじゃん。
普通の使い方なら、そもそもマージコミットで個別の修正はあり得ないよね？
単なるコミット同士をマージしたものなんだから。

90:デフォルトの名無しさん
15/06/14 21:12:29.91 eC56/Xbq.net
>>89
あぁ、その話か。
マージコミットには、どのコミットとどのコミットを
マージしたのかって情報が含まれるんだよ。
「単なるコミット同士をマージしたもの」という言い方が、
何か意味を勘違いしている気がするが、コミットには歴史の情報も含まれている。
（つまりAとBコミット番号が同じなら、過去も同じであるということ）
つまり、masterにbranch（のHEADのコミット）をマージするってことは、
マージコミットの中にはbranchの複数のコミット情報が含まれてることを意味する
>>30で言ってる「マージコミットの中」というのは、
マージコミットでマージしたブランチの複数のコミットを見ろって話。
それはブランチのコミット内容を意味する。
人によってはmasterに直接コミットを追加することもあって
マージコミットを使ってないコミットにはtypo修正とかあり得る。
（typo修正だけのブランチをffマージするのと同じ）
だからこのコミットを見てもブランチが綺麗に整理されてマージしているってことに気がつかない。
マージコミットの中の複数のコミットを見ることで、ブランチに含まれる
コミットは綺麗に整理してからマージされているってことがわかるって話。

91:デフォルトの名無しさん
15/06/15 12:22:13.27 QV1BHlUK.net
やっぱり、マージコミットにはマージしたブランチの複数のコミットが含まれる、っていい方が分からんな。
githubは確かにそう見えるが、実際にはマージコミットは二つの親コミットをもつコミットだろう？
githubはpull request形式だから、マージ先ブランチとマージ元ブランチを明確に区別出来て、マージコミットをマージ元ブランチの複数のコミット、という意味に出来るのかな？

92:デフォルトの名無しさん
15/06/15 12:25:00.72 QV1BHlUK.net
まあ、要するに、単なるコミットっていうのは、githubのmasterブランチ上で表示されるマージコミットでないコミットってことね。

93:デフォルトの名無しさん
15/06/15 18:51:40.59 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:デフォルトの名無しさん
15/06/15 19:09:32.17 QV1BHlUK.net
ブランチ AのHEADがコミットcで、masterのHEADがコミットDのときに、ブランチAにmasterをマージする。マージコミット☆が出来る。
そのあと、masterがブランチAをマージすると、ffになってmasterのHEADが☆になる。
さて、このときマージコミットに含まれるコミットはa,b,cなのか？それともB,C,Dなのか？

95:デフォルトの名無しさん
15/06/15 19:29:30.20 Vn1MoMzT.net
ffになったらマージコミットはないよ？
確実にマージコミットを作りたいなら
（通常masterへのマージではマージコミットを作る。
なぜならマージしたという情報を残すため）
--no-ffオプションを付ける

96:デフォルトの名無しさん
15/06/15 20:40:45.17 QV1BHlUK.net
masterのHEADの☆はマージコミットだよ

97:デフォルトの名無しさん
15/06/15 20:46:14.81 TKCLtNo1.net
>>95
+1

98:デフォルトの名無しさん
15/06/15 22:48:37.43 Vn1MoMzT.net
>>96
言ったでしょう？
masterへのマージでは通常
--no-ffをつけるって。
だから>>94のような状態には通常ならないんだよ。

99:デフォルトの名無しさん
15/06/15 23:07:27.61 tRPgSWCN.net
相変わらずウルセーバカがいるな

100:デフォルトの名無しさん
15/06/15 23:27:33.58 Vn1MoMzT.net
運用ガイドラインの一つとして、masterへのマージは原則として
--no-ffをつけるってのも必要かな。

101:デフォルトの名無しさん
15/06/15 23:43:18.36 QV1BHlUK.net
>>98
--no-ffすればマージコミットになるのは当たり前だし、
>>95ではffになったらって前提でマージコミットにはならないって言ってるし、
>>90ではffマージもあり得る話としているから、イマイチgitの仕組みを理解してない人なのか、github前提で話をしている人なのかの区別が付かなかったんだ。
今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
それともgithubのpull requestの運用だと--no-ffを原則にしなくても問題ないの？

102:デフォルトの名無しさん
15/06/16 02:44:17.56 In84evFv.net
githubのpull requestの運用だと--no-ff勝手につけてくれるな

103:デフォルトの名無しさん
15/06/16 12:14:12.79 tnRZvA/G.net
>>101
> 今さら--no-ffをルールにすべきか？なんて言ってるけど、git自体は--no-ffが原則なの？
いつも思うんだけど、単純なルールを欲しがるよね。
関係ないけど、ちょうどこんな記事を読んだんだよ。
アジャイルの破綻―原因、そして新たな提案
URLﾘﾝｸ(postd.cc)
> あなたが新しいプログラミング言語や技術、または開発手法などの新しいスキルを初めて学ぼうとする時、
> 経験やメンタルモデル、”調査と順応”といった抽象概念に対応する能力を持ち合わせていません。
> これらの能力は、より経験を重ねた熟練者だけが持ち合わせているものです
>
> 初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。
> 例えば、「これが起こったら、あれをする」といったようなルールです。
> ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、
> 初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、
> 凝り固まったやり方になってしまいます。
何も考えたくないから、簡単なルールを求める。
そうじゃなくてちゃんと考えようよ。
俺は「マージするときは必ず--no-ffをつける」なんて言ってないからね？
まず一つ「masterへのマージ」と言った。そして「原則として」と言った。
原則として
URLﾘﾝｸ(www.weblio.jp)
> 例外が許容される場合があるという意味合いを含むことがある。
殆どの場合masterのへのマージは--no-ffになっており、それを参考にしろという話
何にでも例外はあって>>94はその例外。その例外を持って来られても
大半のmasterへの、”masterへの” マージは--no-ffになってるんだから、それ見ればわかるでしょ。

104:デフォルトの名無しさん
15/06/16 12:19:15.57 tnRZvA/G.net
>>102
> githubのpull requestの運用だと--no-ff勝手につけてくれるな
そうなんだよね。基本的にmasterへのマージは--no-ffになるから
そんなの基本的な話だと思っていた。
そしたら、masterへのマージでffになる例を持って来られたから、
今さら（masterへのマージに）--no-ffをルールにすべきか？
って話をせざるを得なくなったんだよ。>>101
俺としては当たり前すぎの話だったので省略してしまった部分。

次ページ