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

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


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

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

そしてガイドラインを言う時は、ちゃんと理由も書きましょう。
上司が言ったから絶対なんだ！今までそれでやってきたからそれでいいんだ！
みたいなのは理由ではありません。
2 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:53.40 ID:5CuOmznL.net]: 少しだけガイドライン考えてみた

・一つのコミットで複数の修正を行わない
理由後からそのコミットを見た時何を修正したのかがわからなくなるから

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

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

と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。
3 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:24:21.46 ID:5CuOmznL.net]: >>585
> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」

いないだろｗ

あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。

物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。

コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。

そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。

このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
4 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:24:51.14 ID:5CuOmznL.net]: 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。

俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。

つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね
5 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 14:58:24.31 ID:iOpTlduD.net]: まともなGUIマダー？
6 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 15:29:21.05 ID:+aAn4ks1.net]: Visual Studio内蔵のGitのインターフェースは最初わけわからなかった
7 名前：デフォルトの名無しさん [2015/06/07(日) 15:30:09.05 ID:o+m9rMyT.net]: 　　　　　　M.ﾊ从人ﾉヽ
　　　　　　ｲﾘ　　　　　　ﾉﾘ,, 　　　　「ウンコはトイレでしろ」
　　　　　ﾒ　＿,,,,,,,,,,,,,,,,,,,_　.K 　　　こういう凝り固まった脳みその奴って出世できなさそうだよな
　　　　　ﾒ　i　　　　　　　 7 .K 　　　こんなバカがウンコしたい時にトイレ探し回ってるの見ると爆笑もんだわ
　　　　　ﾖ .y -一　　ー- !,　f 　　　トイレなんてただ座ってウンコをするための部屋にすぎないんだよ
　　　　　r! .!. ｨtｧ　　 tｧx .!.¥ 　　　　喉乾いたら何が何でも喫茶店入らなきゃいけないって訳じゃないだろ
.　　　　　!,Y　　　　　　　 f .! 　　　　探せば自販機もあるしコンビニもある
.　　　　　] 　　､.`ー' .,　 .├' 　　　喫茶店も座って落ち着いて飲み物を飲む部屋にすぎない
.　　　　　 !,　　￣￣　　 .ﾊ　　　　つまりウンコしたくなったらトイレを必死で探す奴は選択肢を考えられない馬鹿
　　　　　　/ゝ,　　　　　,ノ　ヽ,
　　　　／/.　 i｀ﾞ'''''''''"´ /　　|＼,＿_,,,,,,
　　⌒　 /　　 ',　　　　 /.　　　|　　　　　ヽ
8 名前：デフォルトの名無しさん [2015/06/07(日) 15:43:30.20 ID:uZ5MlZ27.net]: 運用で対処するより、Gitそのものが良くなる方がいいんじゃないかな？(´･ω･｀)
9 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:22:05.50 ID:5CuOmznL.net]: >>8
Gitの適切な運用方法を語るスレだよ。

「Gitをよりよく使うための運用ガイドライン」にすればよかったかな。

Gitに問題があるって話じゃない。
Gitのコマンド体系はもう少し改良の余地があるとは思うが
機能自体には問題ないよ。

Gitは運用方法（フロー）をがっちり決めているわけじゃなくて、
git-flowとかgithub-flowとか細かいフローがあるが、
それでも基本的な考え方というのはある。

使いにくいと思ったら、使い方が悪いと考えた方がいい。
10 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:23:04.79 ID:5CuOmznL.net]: >>5 >>6
すれ違い。そういう雑談はこっち。

Git 12(c)2ch.net
peace.2ch.net/test/read.cgi/tech/1427085313/

ここはgit-flowやgithub-flowと言った
gitを使った運用方法を語るスレ。
11 名前：デフォルトの名無しさん [2015/06/07(日) 16:33:06.80 ID:uZ5MlZ27.net]: スレの主旨を適切なタイトル名として表せないような能力しかない人間が
立てたスレって…役に立つの？(´･ω･｀)
12 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:33:20.22 ID:5CuOmznL.net]: ちょっと出かけなきゃならなかったからとりあえずスレを立てたが、
テンプレ作りたいね。Pro Gitは当然として各運用フローのリンク
公式がよくわかんないんだけどこれでいいんだろうか？

・Pro Git
英語 https://git-scm.com/book/en/v2
日本語 https://git-scm.com/book/ja/v1

・git-flow
nvie.com/posts/a-successful-git-branching-model/

・github-flow
scottchacon.com/2011/08/31/github-flow.html

・gitlab-flow
https://about.gitlab.com/2014/09/29/gitlab-flow/

Qiitaのリンクを貼るのはあまりすきじゃないんだが、簡単にまとまってたので
テンプレに入れるかどうかは別として、とりあえず

Git利用時のフローはどれを使うか
qiita.com/tkhm/items/cc7855d32d640687b43c
13 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:34:58.87 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:35:55.49 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 17:32:26.76 ID:R6yntEB+.net]: 何かバグフィクスしてる時、全く関係ないけどちょっとした修正個所を見つけて思わず直してしまい、
そのまままたバグフィクス作業に戻って最後にコミットする段階になった。

>>2 に従うなら「バグフィクス」と「無関係のちょっとした修正」は分けてコミットすべきなんだが・・・

さて、どうしたものか。
16 名前：デフォルトの名無しさん [2015/06/07(日) 18:59:18.07 ID:adsRb63z.net]: >>2
なんだこの馬鹿ルールは。
17 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:09:30.35 ID:dAMefaMD.net]: まだ機能がロクにできあがってない完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど
svnみたく基本master直コミットで、切りたいときだけ適当に切る感じでやってる？
18 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:31:57.73 ID:5CuOmznL.net]: >>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を完了させる
19 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:32:23.65 ID:5CuOmznL.net]: >>16
分かったから、理由ｗ　理由ｗ
20 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 20:02:06.44 ID:5CuOmznL.net]: >>17
> svnみたく基本master直コミットで、

いやいやｗ svnでもmasterに直コミットなんかしないってｗ
（個人プロジェクトとか超小規模は除くけど）

まだsvn使ってる有名プロジェクトって何があるんだろう？
例としてtracを見つけてきたけどマージのほうが多いでしょ？
trac.edgewall.org/log/trunk

> まだ機能がロクにできあがってない完成前の作成中の段階って
疑問なんだけど、その作成中の段階のソースコードってどこにあるの？
まさかローカルのPCにあって、他の人はだれも見れない状態？

その機能を作るのに1日かからない程度の小さい修正なら、他の人が見れない状態でも
たいしてリスク無いと思うけど、数日とか数週間かかるようなものが
他の人が見れなかったらリスク高くなるよね？

作成に数日かかった大作を見せられて、それがクソコードだったとき、全部やり直しになってしまう。
だから少なくとも一日に一回はコードを他の人が見れるようにしないといけない。

そのコードは作成中なのだからmasterに入るわけがない。
ではどこに？ → その答えがブランチでしょ？

> 完成前の作成中の段階って、ブランチわける適切な粒度がよくわからないんだけど
ということで「完成前の作成中の段階」と呼べる状態があるのなら、それがブランチになるんだよ。
21 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 20:31:56.38 ID:dAMefaMD.net]: >>20
最初のほうでもみんなトピックブランチみたいなの作業ごとに切って作業してるのかなあって思って
ただ最初は1個が本当に数週かかるし、ある機能が複数人に影響するのも多いから、それをいちいち各人が自分のブランチにマージするのかって考えると
1個のブランチにみんなで直接コミットしまくったほうがよくない？とも思ってどうしてるのかなあと
22 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:04:30.29 ID: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 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:11:03.05 ID:5CuOmznL.net]: >>21
で、なんで君が「1個のブランチにみんなで直接コミットしまくったほうがよくない？」と
思っているのか、その理由はわかってる。

直接コミットをすれば、すぐに他人のコードが「1個のブランチ」に取り込まれて
他の人はそれをすぐに利用できるからいい。と思ってるはず。

逆に言えば、（トピック）ブランチを切っていれば、そのブランチが
「1個のブランチ」に取り込まれるまで時間がかかる。
それぞれの開発者が、それぞれのブランチをずっと成長させていき、
その他人のブランチを、時々取り込まないといけなくなる。と思っているはず。

それはトピックブランチの扱いを間違っているだけだよ。
トピックブランチでやる内容は凄く小さい。
トピックブランチは頻繁に「1個のブランチ」にマージされる。

みんなが直接コミットしまくるのと同じぐらいの頻度で
「1個のブランチ」にマージされるんだよ。

ちなみに「1個のブランチ」がmasterであるか、次期リリース用ブランチであるかは
gitフローなのかgithubフローなのかによって変わる。
24 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:19:06.14 ID:5CuOmznL.net]: >>21
君が抱えている問題を解決するヒントを一つ提示しよう。

ある機能を作ることになった。その機能のために1つのブランチを作る。
（ここまではsubversionでも一緒だろう）

そしてそのブランチを作っている間に、ある便利な関数を作った。
その便利な関数は、他の人も使う。

のであれば、君が作っているある機能の完成を待たずして、その便利な関数だけをマージする。
出来上がった所から取り出して、早くマージしてしまえばいいんだよ。
（こういうことがsubversionではやりにくい）

この発想ができるようになれば、中途半端なコードをマージすることもないし、
みんなで直接コミットしまくるのと同じように頻繁にコミットできて
それをするために、自分の作業履歴（コミット）を自由に入れ替えて
歴史を修正することができるgitの重要さが理解できるようになる。
25 名前：デフォルトの名無しさん [2015/06/08(月) 14:47:51.52 ID:kFqfXqDD.net]: 糞スレ終了
26 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 19:42:50.61 ID:+yUhk8xr.net]: 俺ルールを押し付けんなクズ >>1
27 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 20:36:08.82 ID:yR6yCENO.net]: やれやれ。荒らしたい奴は来なければいいのに。
なんのためにこっちに移動したのか？
28 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 23:37:37.11 ID:IKTjq6kL.net]: >>1の説明は論理的で分かりやすいです。
質問に対して、自分のガイドラインに従った場合の解決方法をちゃんと示しています。

何を重要視しているのかが明確に示されていて、それが自分に合う人にはとても参考になると思います。

>>25や >>26 などは、たぶん合わなかったのでしょう。
Git人口はとても多いので、当然そういう人も大勢いると思います。
彼らが従うガイドラインも見てみたいです。

ちなみに私は >>15 ですが、とても参考になりました。
29 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 08:21:36.47 ID:EBIaYtJo.net]: なぜグローバルなガイドラインを語らずに身勝手な自分ルールを持ち出すの？
独り言はツイッターでやってろ
30 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 08:48:52.69 ID:+d7EQhmV.net]: > なぜグローバルなガイドラインを語らずに

なにいってんの？グローバルなやり方を説明してるだけなんだが。
OSSのmasterのマージコミット（単なるコミットではなく）を見てみろよ。

マージコミットの中で、typoの修正とかありえないし
コミットの内容もその順番も明確になってる。

開発でそんな綺麗に作業なんて出来ないし、
そもそもマージ前にレビューがはいるのはやり直す必要がある場合が多いから。
そのやり直しを感じさせないぐらいに綺麗に整理されてからマージされてるんだよ。
31 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 08:59:54.69 ID:+d7EQhmV.net]: >>28
どうもどうもｗ

git歴は2年ぐらいかな。当初というかgit始める前から
可読性ならず可レビュー性を重視していたからね。

Subversion使ってる時にレビューしていて、

あれ？この修正不味くない？
あー、あとのコミットで修正されてるのかー！
みたいなのとか

いきなり一週間分の修正をまとめて持って来られたって
解読に時間掛かり過ぎる、細かく分けて持ってこいよ。
とか

これじゃレビューできるわけ無いよね。みたいなのをどうするかを考えていた。
Subversionでも出来ないことはないんだが、いちいちネットワークにつないで
何度も送信しないと行けないからストレスが溜まる。gitだとそれを素早くやれる。

それを元にいろんなOSSの履歴を見ながら、それに近いことを実現する
フローはどういったものかを考えてまとめたのがこのスレで俺が言ってることだよ。
32 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 20:11:31.07 ID:xVQhQgen.net]: >>30
一個でも良いから、具体例を一つリンクしてくれないかな？
33 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 20:23:04.85 ID:JtxCFe8d.net]: グローバルだからってどんな現場にもgit-flowを当てはめるような思考停止は
設計できないデジドカっぽくって嫌いだね
34 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 01:24:43.72 ID:7XQM9Exq.net]: >>32

gitの使い方の具体例なら、gitプロジェクトでいいでしょｗ

目指すはこんな感じのコミットログだよ。
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

「一つのファイルの修正だからって全部まとめたら何やってるのかわからんだろうが」と言われない良い例だね。
35 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 01:25:37.35 ID:7XQM9Exq.net]: >>33
どのフローであっても、ゴミコミットは入れない。
コミットは後から見てわかるように可読性が高い綺麗なものにして
マージするっていう点は全部一緒だよ。
36 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 01:34:04.91 ID:7XQM9Exq.net]: >>34はちょっとミスった。
これマージされなかったブランチかｗ
まあ綺麗に整理されてるってのは間違ってないけど。

代わりにマージされたもので複数のコミットからなるやつを持ってきたよ
https://github.com/sdsykes/fastimage/pull/27/commits

例の有名な記事にかいてあったやつだけど

Why I Won't Squash My Commits
blog.marc-andre.ca/2014/02/05/why-i-wont-squash-my-commits/

[翻訳] 私のコミットをまとめないで
qiita.com/gogotanaka/items/8c55f69120965b077737
37 名前：デフォルトの名無しさん [2015/06/13(土) 08:37:25.33 ID:P6q2Jefi.net]: つまり、誰もが「無駄かどうかを決めるのは俺様(ｷﾘｯ」て言って譲らないから
Ｇｉｔは有効に使えるツール足り得ないってことだよね？(´･ω･｀)
38 名前：デフォルトの名無しさん [2015/06/13(土) 08:41:32.10 ID:NUKk6CPY.net]: その通り
馬鹿には無理
39 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 10:00:00.52 ID:Ih37w7wT.net]: 業務用のシステムを管理するには？どういう方法が良い？
初期開発は良いとしても
本番リリースした後は
本番稼働のもの
本番でバグが発覚（複数）して対応中
改良もはいってる
とかになるとどう分けていつコミットやプッシュするべき？
40 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 10:02:40.72 ID:2dbaYd91.net]: ただ使うだけならコマンド叩くだけなんだからなんも考えんでも使える
gitの本当に難しいところは、自分のプロジェクトでどう使うか
41 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 12:33:55.09 ID:2XvJk2DZ.net]: >>39
それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。

バグをどうリリースするかはバグの内容による。改良のリリースも同じ。

緊急で出さなきゃいけないものは緊急で出す。
そういうのは見つかった段階ですぐに対応しなきゃいけないから
最新のリリース版からブランチを切って作ったブランチをリリース版にマージ。
そしてそれを開発版にもマージって流れになるだろうね。

あとはブランチ（＝バグや新機能）をリリースしたい順にマージ[*]していけばいい。

よくあることだが、新機能がバグの修正に依存しており、新機能の作成中に見つかった。
という話しなら、先にバグを直して（バグ修正ブランチを作ってマージ[*]）、
そこから新機能を作ったことに歴史を書き直せば良い。

[*] の部分だがどこにマージするかは方針と内容次第。
すぐにmasterにマージすることもあるし「次期バージョン」という考え方を
しているのなら次期バージョンブランチを作って、そっちにマージしていって
リリース時にmasterにマージを行う。
42 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 12:40:50.27 ID:2XvJk2DZ.net]: ただし大型新機能の開発が複数並行で進んでおり、両方が同じ部分を修正する
可能性が有る場合、大量のコンフリクトが起きる可能性があるので注意する必要がある。

これを避けるために新機能が完成するまで新機能の内容を"全て"マージしない
という考え方を変える必要がある。

多くの場合、新機能の開発の中には、既存バグの修正やリファクタリング
モデルや汎用ライブラリなどの機能追加（仕様変更ではなく）が含まれる。

これらは先にリリースしても問題ないはず。全てマージしないのではなく一部だけマージする。

だから新機能の開発を行っていたとしても、そのなかで先にリリースできるものはリリースしておく
（次期バージョンブランチがあるのならそっちにマージ。次期バージョンブランチと新機能ブランチは別ね）

こうすることでいち早く大型新機能開発はコンフリクトが起きかねない部分を知ることができるし、
相手の開発した部分を利用することも可能になるから、同じものをそれぞれで作ってしまう無駄も省ける

大型新機能開発を行っていたとしても、小さな開発とリリースという形に変更していくことは可能なんだよ。
43 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 12:44:26.69 ID:2XvJk2DZ.net]: 自己レス

> それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。

この話につながっていなかったｗ

まあわかるとは思うけど、このように開発の順番とマージやリリースの順番を
自由に入れ替えるってことは、それぞれのコミットが意味のある単位で
細かくまとまってなきゃいけないんだよ。

無関係の修正が一つのコミットに混じっていたり、
関係あるコミットが複数に分かれていたりしたら
それを見つけるのが大変になる。

ちゃんとコミットが分かれていれば、開発した順番ではなく
望む形に入れ替えたりすることがしやすくなる。
44 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 16:39:52.58 ID:2dbaYd91.net]: コミットを細かくってのは、簡単なようでいざやると相当難しいんだよな
これがすっきりできれば後はどんなフローにも載せられるんだろうが…
45 名前：デフォルトの名無しさん [2015/06/13(土) 18:45:02.69 ID:5sBiyJnB.net]: 一生バージョン管理やってろw
46 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 19:15:52.26 ID:2XvJk2DZ.net]: >>44
たしかにね。最初はちょっと難しかった。
コード修正中に関係ないことをついついやってしまうしｗ

そこは慣れだよ。意識してコミットを小さくするようにしていけばいい。
まず覚えるべきなのは、git add -pだね。
これができると一つのファイルの中の一部分だけコミットできる。

あとはコミットの順番は後から並び替えられるし、まとめることもできるので
順番は気にせずにほんとうに小さくコミットを作ること。
そして後からまとめて綺麗にしようと考えずに、常に片付けながら作業（開発）すること。
後からまとめてコミットを綺麗にしようと思って、そこで何したか忘れるんだよｗ

大きな開発を複数人でスムーズに行うには、共通のソースコードへの修正の
反映作業が重要だからね。大きな開発も小さく修正していくことで管理可能になる。

それを実際にやってるのを見れるのがgithubとかなんで（まともなプロジェクトの）
リポジトリを参考にするといいよ。
47 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 19:44:46.87 ID:Ih37w7wT.net]: >>46
まともと思える物を紹介して
参考にしたい
48 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 19:51:47.81 ID:2XvJk2DZ.net]: >>47
だからgitだってｗ
gitを一番うまく使ってるのは
gitプロジェクトに決まってるでしょｗ
49 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 21:26:31.06 ID:ZkFtP6do.net]: >>1 のスタンスで詳しく書かれた Git の書籍はないですか。
洋書でも構いません。
50 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 21:28:47.45 ID:ZkFtP6do.net]: >>49
紛らわしいので言い直します。

>>1 の人のような考え方を詳しく解説した書籍はないでしょうか。
洋書でも構いません。
51 名前：1 mailto:sage [2015/06/13(土) 22:30:36.68 ID:2XvJk2DZ.net]: >>49
残念ながら知らない。日本の本に関しては、最近出た2,3冊は内容を確認してないけど、
それ以前のものに関してはgitの使い方ぐらいだったな。それはそれで最初のうちは
役に立つんだけど。海外の本に関しては、読んでないので知らない。

代わりに日本と海外（アメリカ）の考え方の違いの話をするよ。
よく言われていることだけど、海外はパッケージの導入を積極的に行うけど、
日本は独自で作ったりパッケージをカスタマイズすることを望む。

この考え方の違いというのは、日本は自分のやり方を通そうとするということ。
日本の文化だと、アプリにがあれもこれもなんでも出来るようになってしまう。
それは一見便利なように見えるけど、業務を改善（＝変えていく）ことにはつながらない。
やり方を変えずにツールを変えるだけだから生産性は上がらない。

海外のソフトウェアっていうのは、業務を一番効率的にやれるのはどういうものか？
という考えを形にしたものなんだ。もちろんその考え方はいろいろあって正解とは限らないけど、
少なくともソフトウェアっていうのは、開発者が想定した正しい使い方っていうのがあるんだよ。

つまり俺の考え方というのは、ツールの正しい使い方というのを学習していくことでできたもの。
ツールにはできること、できないことってのがあるけれど、思いつくまま実装されたのではなく、
正しい使い方をするのに、必須だから追加した機能であり、邪魔だから追加しないと考える。

例えばgitには歴史を改ざんできる機能があるでしょ？これは正しく使うのに必須だから。
ファイルをロックして他人が編集できないようにする機能はないでしょ？
それは正しく使うのに邪魔だからあえて搭載しないことを選んでいる。

この開発者の考えに、自分の考えが適合してくると、「こんな機能があったほうがいいんじゃないか？」って
思ったものが次期バージョンに搭載されたり、議論が行われていたりする。

考え方が合わない最初のうちは、なんでこうなってるんだ？使いにくい！って思うかもしれないけど
そうではなく意味があってやってることだと考え、何故そうなっているかを考えていくといいよ。
52 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 22:43:28.86 ID:2XvJk2DZ.net]: >>49
もう一つgitよりの話をすると、gitは誰が何故作ったのかを考えればわかると思うよ。
リーナスがソフトウェアを開発するために作ったよね？

そう、開発者のものなんだ。
開発の進捗を知るためのマネージャーのツールでもないし
ソフトウェアのロストを怖がる管理者のツールでもない。

ソフトウェアの開発、しかもそれを多くの人が関係するってことは
正しい修正であるかどうかを判断するには、ソースコードを読まないといけない。

頭数を揃えてテストしたって、正しい修正であるかなんてわからない。
どっかの金もってる大会社じゃないんだから、頭数自体揃えられないけどｗ

そういう文化にとって「テスト」とは誰でも（一人でも）テストの実行を再現可能な
テストコードであり、そのテストコードが正しいかどうかは、読んで判断するもの。

それ以外できっこないんだから。これは現実。

そこまでわかれば、あとは何が必要かがわかる。必要なのはコードが読みやすい
コミットであり、必要なツールは読みやすいコミットを作ることが出来るもの
そういう考えでgitが必要とされ生み出された。あとはそのgitの正しい使い方を理解していくだけだよ。

ただ一つだけ俺がラッキーだったのは、gitを知る以前から、読みやすいコミットの重要性を理解していたことかな。
完成されたソースコードだけじゃなくて、修正の内容とその過程自体もわかりやすいことが重要であると。
だから俺にとっては、gitは俺が考えた理想を実現するツールだったね。
53 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 09:57:57.81 ID:wRqn8b2I.net]: 後からコミットログは簡単にまとめられて、逆に分割は困難なことを考えると
上書き保存するたびに即コミットぐらいでやるほうがいいのかなあ
54 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 10:12:42.73 ID:d62hq9+6.net]: 休憩や今日の終わりの度にコミット？
動かないコミットは嫌だな
55 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:12:44.05 ID:gLTCEjdN.net]: git って ID:2XvJk2DZ みたいな信者が沸くところが嫌なんだよね
理想に最も近いとか言うならまだわかるけど、理想を実現したとかちょっと気持ち悪い
56 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:38:15.57 ID:M4xMa8us.net]: >>53
それでもいいぐらいだよ。ただコミットを整理せずに
放置しておくと何したのか忘れるので整理しながら作業した方がいい。

分割は面倒だけど困難というわけでもない。
やり方は色々あるけど、rebase -iの途中で分割作業をするから
（つまりある作業中に別の作業をするようなもん）
少し慣れが必要だけどね。

>>54
masterに入れるのは動くコミットに決まってるでしょｗ
トピックブランチなどは最終的に消すものなのだからどうでもいい。

誰が作ったそのルール？コミットはどんなものでも
動くようにしろとか、変な自己ルールに縛られすぎだよｗ

理由があるからルールができる。理由を説明できないような
ルールを作らない方がいいね。

>>55
うん。それで？
なにか間違っているとか、もっといい案があるなら
どんどん言っていいんだよ？
57 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 11:58:20.38 ID:d62hq9+6.net]: >>56
ならあんたのルールをここで公開してくれよ
採用考えるわ
58 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:02:28.86 ID:M4xMa8us.net]: >>57
1からずーっと書いてきてる。
読みなおしてくれ。
59 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:08:41.21 ID:d62hq9+6.net]: >>58
ずーっとってお前の発言は識別出来んわ
コミットしてくれー
だとコミットの使い方が違うか
60 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:10:30.52 ID:M4xMa8us.net]: >>59

既に>>2で具体的に書いてるじゃないか？
61 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:11:32.71 ID:M4xMa8us.net]: >>59
「コミットを意味があるように綺麗にしておけ」とは言っているが
その中で「コミット」という単語しか見えないのか？
62 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:14:40.91 ID:d62hq9+6.net]: >>60
おいおい1からずっと書いてるから読めって
2がまとめかよ
しかもあれで具体的だなんて
ちゃんと仕事で複数人で活用してる人？
一人とか小さなものでやってるだけ？
なら、お前が書けと言われても作れていないから書けない、悪いがな
63 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:18:45.44 ID:d62hq9+6.net]: もしかして、このスレって
自称優秀なPG様が作っているスレ集の１つだったか？
64 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:18:58.06 ID:mvvCE6hZ.net]: 長文自分語り
しかも中身はオレオレ規約
きめぇ
65 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:26:04.87 ID:M4xMa8us.net]: >>62

2がまとめじゃなくて、2が基本てな原則だよｗ
その後は>>2の補足をしたり、もっと具体的に踏み込んだ説明をしている。

あれで具体的って、お前やっぱり>>2しか見てないじゃないかｗ
だからちゃんと1から読めって言ってるんだが。

> ちゃんと仕事で複数人で活用してる人？
当たり前だろｗ逆に一人でやるなら適当にやればいいだろ。

自分の書いたコードだったらコミットが汚くてもわかるんだよ。
でも他人の書いたコードのコミットが汚かったらわからないだろ？

レビューしてくださいって来たコードが、何百行もある大作1コミットだったら
レビューなんてできるわけないし、小さく分かれていても複数のコミットで
同じ行を修正していたりしたら、無駄なレビューをすることになる。

レビューするためには、ソースコードを綺麗にするだけじゃなく
コミットの内容も綺麗である必要がある

俺の話は複数人だからこそ必要な話をしてるんだが。
多くの人、それぞれスキルは違うし、悪意がある人迄いる可能性がある
オープンソースを見てみなさいよ。
適当なコミットはレビューできないから、そういうのはマージされないよ。

知った人間ばかりの会社内のやり方とはわけが違う。
会社内だとコードのが意味不明でも上司だからとか、あの人なら大丈夫だからとか
よくわからないけど、動いてるみたいだからいいんじゃね？
コミットが汚くてもろくにレビューもせずに適当マージしてるでしょ？

俺の意見は最初から一貫して、レビューが可能なように綺麗なコミットにしろって話をしてる。
66 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:27:55.94 ID:d62hq9+6.net]: >>65
59へ戻る
67 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:29:08.27 ID:M4xMa8us.net]: >>64
それで？

そんなものよりもっといい案が有るなら
それを言ってくれよ。

自分の意見を言わない奴に
発言する権利はないよ。
ミーティングと一緒。

ミーティングで誰かの意見に対して
「あなたの提案の内容に関してですが、
あなたの発言がキモいです。」
とか言ったら嘲笑ｗ
68 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:29:28.83 ID:M4xMa8us.net]: >>66
どうぞ戻ってくださいｗ

はい、つぎ。
69 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:30:36.40 ID:M4xMa8us.net]: gitのコマンドはわかるんだけど
gitをどのように使っていけばいいか悩んでいる人
相談に乗りますよー。
70 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:32:34.02 ID:d62hq9+6.net]: やっぱりよく見るパターンだったな
自分語りのために無駄スレ作ってないで
ちゃんと会社の人とルール共有しろよ
71 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:34:05.28 ID:M4xMa8us.net]: >>70
会社に人と共有しているルールというか
考え方を書いているだけですが？

それであなたの考え方は？
それがないとあんたはただの荒らしでしかないよ。
72 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:36:23.99 ID:d62hq9+6.net]: 話し合いにも討論にも雑談にさえならないのは目に見えてるから遠慮しとく
73 名前：デフォルトの名無しさん mailto:sage [2015/06/14(日) 12:37:48.19 ID:ByqCHqi5.net]: そういやうちの会社にはいないけど、
よく聞くじゃん？

上の立場の人が、でてきた意見を何の理由もなく否定する人。

きっと自分の考えを書かずに否定する人って
上の立場になったら、そういう人になるんだろうなって思った。

ドラマや小説で悪役として描かれる
そういう上司。
74 名前：書込しすぎたからID変えたって書くの忘れた mailto:sage [2015/06/14(日) 12:39:12.98 ID:ByqCHqi5.net]: >>72
バイバイｗ

俺にしてみれば、お前をあぼーんしたのと同じだから
それがお互いにいい結果。

意見がないならもう来ないでね。
意見があるのなら来ていいですよ～ｗ
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