Git 12

1 名前：デフォルトの名無しさん mailto:ageteoff [2015/03/23(月) 13:35:13.83 ID:aBYp+bVs.net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System git-scm.com/ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 11 peace.2ch.net/test/read.cgi/tech/1416195050/ 411 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 00:34:12.47 ID:bUwhy5PJ.net] >>405は、自分が間抜けだって思われてることに気が付いてない正真正銘の間抜けらしいな >>389の洞察力はかなりのもんだ 412 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 00:47:11.22 ID:Z2wm6bTM.net] gitなんてもはや使って当たり前のツール 熱く語るようなものじゃない いまどきgit使わないのは「メモ帳でもプログラム書けますよ」と同じようなレベル 413 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 03:51:35.72 ID:NXZBxN2S.net] >>405-406 それで自分の意見は？ 他人にあーだこーだいってるんだから 俺ならこうだっていう意見ぐらいあるよな？ 414 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 03:52:09.72 ID:NXZBxN2S.net] >>405-406じゃなくて >>406-407 415 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 07:44:40.13 ID:boZKLFPs.net] >>409-410 >>392 もう少しまともな意見が言えるようになったらまたおいで 416 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 08:48:51.64 ID:NXZBxN2S.net] あー、反論できないからってｗ 図星なんだな 417 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 09:28:18.61 ID:SJ9cQ9MA.net] 中学校までしか見ないセリフで笑い取りに来るのやめろ 変なダメージ入るわ 418 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 10:32:48.57 ID:3s/cPLTB.net] 会社で使う分にはcvsで十分なんだよな 個人同士で開発するときにはgit超便利だけど 419 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 18:23:51.20 ID:/fyjA82q.net] 事務や立法には今ならgitが必須であるはずだが現実には全く使われないな。 俺は、総務にバージョン管理を、役員にMSプロジェクトを、それなりに真剣に薦めた事があったが、何も実行されなかった。 420 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 21:06:06.49 ID:K4zbhPtL.net] >>412 どのレスに反論しろって言ってるんだ？ 421 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 23:49:15.84 ID:NXZBxN2S.net] >>416 レスするなら反論しろってこと >>406、>>407、>>411、あたりだね。 レスしてるってことは、何か言いたいことがあるってこと。 でも、その言いたいことが何も書いてない。 「どのレスに対する反論しろ」っていう話じゃなくて レスするなら、自分の意見を書きなさいってこと。 422 名前：デフォルトの名無しさん mailto:sage [2015/05/07(木) 23:50:08.72 ID:NXZBxN2S.net] もちろん反論じゃなくて 賛成でもいいよ。 どちらにしろ、自分の意見が書いていないレスは ゴミ同然だろう？ 423 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:00:17.12 ID:ZHeXF73S.net] 戦犯>>416 424 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:05:38.96 ID:SsabnSp5.net] >>417 言いたいことは、「お前はマヌケだな」ってことじゃないのか？ｗ 425 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:24:24.90 ID:k44MRK8x.net] その理由が書いてないから、説得力ないですよね？ そういう話をしているの。 426 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:36:25.10 ID:SsabnSp5.net] >>407に書いてあるように見えるがｗ 427 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:54:02.88 ID:k44MRK8x.net] >>407のどこに書いてあるか、その文章を カッコつきで引用してみて。 428 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 00:56:53.00 ID:P0RHYnr3.net] で、このガキのケンカをいつまで見せられるの？ 429 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:02:15.84 ID:SsabnSp5.net] ID:k44MRK8xがgitを使うのをやめるまで 430 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:04:13.32 ID:k44MRK8x.net] はぁｗ やっぱりいちゃもんだけつけて 何も言い返してこないのね。 最近こんな奴が多いね。 ま、言い返してこないなら、 願ったり叶ったりだけど。 じゃ、次。 431 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:04:34.82 ID:ZHeXF73S.net] ここは荒れるたびに荒れ方が幼稚になっていくなあ 432 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:10:04.42 ID:k44MRK8x.net] 幼稚な奴がいるんでしょ？ 幼稚じゃなければちゃんと会話のキャッチボールができるはず。 433 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:11:40.05 ID:dtfwKzs4.net] すんません、思いっきり初歩的な質問です。これってソースコード管理となってるけど、例えば excelのブックやあるいはVBなどのプロジェクトをフォルダ単位で…とかって出来るんですか？ ソースコード管理というとなんかテキストで保存みたいに聞えるんですが バージョン管理触ったことがないんで、ちょっとお聞きしたいです 434 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:24:17.86 ID:k44MRK8x.net] gitで管理するには、バージョンとバージョンの差を 取り出す方法（つまりdiff）ができないとだめ。 excelはそれが出来ないので無理。（正確に言うと意味が無い） VBは一部にバイナリデータがあったと思うが、大部分はテキストなので可能。 （バイナリデータは保存することしかできないが） 勘違いしてはいけないのは、バージョン管理ツールは バージョンを管理するものであって、 バックアップをするためのものじゃないってこと。 バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、 その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。 特殊な形式のバイナリが標準化されれば、バージョン管理できるかもしれないが 現時点ではテキストファイルしかバージョン管理できない。 excelなんかはバージョン管理（差分を抜き出すなど）する意味が無いので 別のバックアップツールを使った方がいい。 435 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 01:27:36.31 ID:dtfwKzs4.net] 了解です。深夜にありがとうございますです 436 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 02:06:08.07 ID:ZHeXF73S.net] フォルダごとできるけど差分で管理されないので1MBのファイルを100回コミットしたら100MB消費みたいになる それでも使うのは構成管理用か管理上ソースと不可分であるときくらい 事務用でも月次年次確定データや契約書決裁書等重要書類が紛失変更されないようロックするには都合がいい バックアップファイルの管理とバックアップツールの保守が不要になる タイムマシンしたいなら無駄無駄無駄普通にバックアップソフト使え 437 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 07:14:07.27 ID:IAWQ0LFr.net] >>430 > バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、 > その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。 幼稚なオレオレ定義乙 >>429 単純に最新版管理したいとか、たまに過去バージョンを取り出したりしたいだけなら Subversion の方がいい Excel ってことはたぶん Windows だろうから TortoiseSVN インストールすればほぼ GUI で使えるし 詳しく知りたいなら続きはこちらで Subversion r15 peace.2ch.net/test/read.cgi/tech/1406967657/ 438 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 09:22:21.26 ID:samEA3DJ.net] そういう用途ならTIME MACHINEとかWindowsバックアップでいいべ 439 名前：デフォルトの名無しさん [2015/05/08(金) 09:51:36.80 ID:5NA7Syvjy] >>431 > excelなんかはバージョン管理（差分を抜き出すなど）する意味が無いので セル書換えとかカラム追加とか差分を抜き出したいことは普通にあると思うが。 440 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 09:44:23.49 ID:SsabnSp5.net] >>428 ＞幼稚な奴がいるんでしょ？ それがお前だな 441 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 11:34:00.00 ID:Yhmm5THU.net] >>434 TIME MACHINE はよく知らんからわからんけど Windows バックアップとかとは別物 一時間の間に 10回変更したら 10回バックアップとる訳じゃないでしょ 442 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 11:41:31.10 ID:samEA3DJ.net] svnだって自分でコミットしなけりゃ取れないじゃんか バックアップだって自分でトリガひける 443 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 12:19:48.40 ID:Yhmm5THU.net] そうだね、頑張ればなんでもできるよ w 444 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 12:55:19.05 ID:SsabnSp5.net] どっちもどっちという結論 445 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 19:41:28.50 ID:dtfwKzs4.net] >>433 426です。Subversionってのを調べてみます。情報多謝m(_ _)m 446 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 20:05:19.99 ID:9kJl+Khz.net] バグを埋め込んでしまった場合、コミットをまとめるとリーディング量が増えるからまとめないほうがよいという結論に達した こまかくpushするほうがよい たとえば足し算の結果を表す機能と引き算の結果を表す機能を作るとしたら２つのコミットを作れば良い この２つを１つのログにまとめるべきではないのだ 何でもかんでも１つにまとめるのがかっこいいという間違った思想を持った人間がいるので困った。 447 名前：デフォルトの名無しさん mailto:sage [2015/05/08(金) 20:18:03.21 ID:ZHeXF73S.net] 当たり前すぎる よくそれでコード書いてるな 目的ごとにブランチ切ってコミットあたり1ハンクだけで済むようにするのがベストプラクティスだ 448 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 00:45:24.25 ID:oI9IuS7a.net] >.438 > バグを埋め込んでしまった場合、コミットをまとめるとリーディング量が増えるからまとめないほうがよいという結論に達した 具体例かける？ 書けるはずだよね。書いて。 449 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 00:56:47.31 ID:bOQm//LK.net] ここの幼稚な人は、ど〜してもケンカがしたくてたまらない 450 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 00:58:05.96 ID:oI9IuS7a.net] なんだ。またいつものアイツかｗ 451 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 13:31:25.76 ID:MqwqSntJ.net] git で3件昔の履歴の内容を確認したいのでgit reset HEAD^^^しました 戻る時ってgit reflogで最新の履歴を確認してgit reset HEAD@{n}しました こういうやり方であってますか？ 452 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 13:38:29.58 ID:P/ABm+5N.net] まちがってます 453 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 13:38:44.30 ID:8PoBBRDQ.net] checkoutでおｋ 454 名前：デフォルトの名無しさん mailto:sage [2015/05/09(土) 13:41:01.09 ID:oI9IuS7a.net] >>447 tigコマンドを使う。 455 名前：443 mailto:sage [2015/05/09(土) 19:11:08.54 ID:hILIDw1n.net] checkout使うことにします tigも調べてみます 456 名前：デフォルトの名無しさん mailto:sage [2015/05/12(火) 16:17:37.50 ID:pNASC22d.net] すいませんgit checkout HEAD^^で過去に戻ってファイルを作成したり編集したんですが 元のブランチに戻りたいのですがこのままだとできません git reset --hard HEADとかgit checkout .とかして更新をなかったことにできません。 元のブランチに戻るためには更新されてない状態に戻す必要があると思うんですがどうやるのですか？ 457 名前：デフォルトの名無しさん mailto:sage [2015/05/12(火) 16:23:44.14 ID:KgdwQEvt.net] 本当に修正をなくして良いなら、git reset --hard 元のブランチ名 今度からは、修正したいときは新しくブランチを作ってからやるんだよ git checkout -b edit_branch head^^ で、修正するも捨てるも良し 458 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 08:09:17.45 ID:aOO0/Ibj.net] 今度からって今からでもできるし。 459 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 08:11:21.04 ID:aOO0/Ibj.net] got checkout ブランチ名 で普通に行けるべ。 460 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 08:43:10.59 ID:U5lm4ek9.net] 行けるかどうかは修正内容によらないか？ 461 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 12:28:03.63 ID:dw1HaLxu.net] .gitignoreの内容 * !*.txt !data/ data/.* !data/*.txt mkdir data touch data/a.txt touch data/.b.txt git init git add . これでdata/.b.txtもインデックスに追加されてしまいます .gitignoreでどういうふうに指定したら.から始まるファイルを除外できますか？ 462 名前：デフォルトの名無しさん mailto:sage [2015/05/14(木) 12:59:28.26 ID:7ksZOIpV.net] data/.b.txtが除外されないのは最後の!data/*.txtで解除されてるせいじゃね？ data/*.txtにdata/.b.txtがマッチするのはちょっと妙に感じるかもしれないけど data下の.ではじまるファイルを全部除外したいなら、 ルールの!data/*.txtとdata/.*の順番を入れ替えればいいのかな 463 名前：デフォルトの名無しさん mailto:sage [2015/05/15(金) 11:59:16.15 ID:XocOnm+L.net] リクエストがマージされたら即ブランチを削除していたのですが、それでは、リクエストに対してされたコメントやレビューが見れなくなってしまいます。 ブランチを削除してもレビューやコメントを残す方法は何かないでしょうか？ 464 名前：デフォルトの名無しさん mailto:sage [2015/05/15(金) 20:00:20.09 ID:p2cJvo/x.net] それGitの話なのか？ 465 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 01:25:17.31 ID:+UC07Y5W.net] >>459 githubは知らないけど、gitlab（最新版）なら ちゃんと残る。 正確にはコメントやレビューはマージリクエスト（githubのプルリク相当）に書かないとダメ。 ブランチ（コミット）に対してのコメントであれば見れなくなる。（今は残ってる気もするけど） 466 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 17:17:39.54 ID:AD3UxZEY.net] >>461 ありがとうございます。Gitlabを使ってるのでバージョン上げてみます。オフィシャルブログの更新内容をみてもそれらしき更新がなくダメだと思ってました。 467 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 23:14:20.75 ID:waTp+O7j.net] >>462 gitlabの話でよかったんだなｗ 自分もコメント消えるのが問題だったが、最近消えなくなったなーって 思うだけでどうなっているのかよくわからないから、ついでに動作を少し検証してみた。 * マージリクエスト(以降MRと書く）にコメント(1)を付ける。 * MRのDiscussionにコメント(1)が表示される。 * MRのChangesからコメント(2)を付ける * MRのDiscussionにコメント(2)が表示される。 * MRのCommitsからたどったコミット番号(A)のソースコードにコメント(3)をする * 同コミットの下からコメント(4)をする。 * MRのDiscussionにコメント(3)(4)が表示される。 * Discussionから(2)(3)(4)にReplyする。 * Discussion と共に、コメントを書いた元の場所にもReplyが表示されている。 ここまでは消したりしてないので、ごく普通にコメントが表示されている。 当たり前ではあるんだけど変更した行以外にはコメントつけられないな。 たまに周りにも修正すべき所があってコメントしたくなるんだけど。 468 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 23:15:03.07 ID:waTp+O7j.net] でこのマージリクエストをrebaseしてgit push --forceしてみた。 つまり、コミット番号(A)がMRから消えてなくなる。 * MRに書いたコメント(1)は当然残っている。 * Changesに書いたコメント(2)はMRに残っているが、outdated diffということで 　折りたたまれているので注意。Showをクリックすれば見れる。 * 消えたコミット番号(A)に書いたコメント(3)(4)は、MRからは消えている。 　ただしコミットを表示すれば見ることはできる。 　MR作成後にpushしたコミットなら自動的に、MRに記録されるようになっているが 　最初にpushしたコミットは残らない。（Dashboardあたりで確認可能） ではAccept Merge Requestしてブランチ削除してみる。 （当たり前だがマージしたMRを見ることは可能） この状態はgit push --forceしたのと同じ状態。 特にコメントすることもないかな。 結論としてはMRにコメントを残したいならば、 MRかもしくはそのChangesに書く。（たぶん昔からこの挙動） MRに含まれるコミットにコメントした場合、 そのコミットが消えると行方不明になることがある。 行方不明になるだけで残ってはいるので、コミットに 辿り着くことができれば見ることは可能。 なので、コミットにコメントしてしまった時は MRからたどり着けるようにリンクを張っておけば良い。 469 名前：デフォルトの名無しさん mailto:sage [2015/05/16(土) 23:20:45.79 ID:waTp+O7j.net] 結局のところコメントが残るかどうかの挙動自体は、 昔から変わってないと思うんだけど、それはそれとして MR自体が見やすくなっているので、バージョンをあげるのはありだと思う。 例えばgit push --forceした時とかにpushしたコミット番号が MRに記録されるようになったのは最近の機能。 できれば最初のコミット番号もMRに記録されて欲しいんだが。 Dashboardとかから調べられるけどさ。 gitlabは昔（と言っても一年前程度）はいかにもgithubの クローンってUIだったけど、UIが変わってgithubとは別の 同種のソフトって感じで良くなったと思うよ。 機能的にもgithubに全然劣ってないしね。 もちろんオープンソースでコミュニティ重視ならgithubになるんだけど、 クローズドならgitlabで十二分に使えると思う。 470 名前：デフォルトの名無しさん mailto:sage [2015/05/17(日) 19:28:04.61 ID:ImkX2Hg5.net] ↑新しい 1 2 3 4 ↓古い 1のコミットを3のコミットに含める事について。 これってコンフリクトを起こす可能性があるのであんまりやらないほうがいいと思うんです。 合体させるならコミットを飛ばさなず1,2,3を合体したほうがいい気がするんです。 ここの先輩方はよくやりますか？ 471 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 02:18:29.93 ID:/pjdhzEd.net] 好きにしろよ。 お前には無理なら止めといた方がいいが。 472 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 08:12:32.67 ID:ezOKhhiH.net] >>466 「あまりやらないほうがいいと思う」のは前提として 「コンフリクトを起こす可能性がある」からだよね？ まず一つ。コンフリクトは起きても問題ない。直せばいいだけ もう一つ。コミットが小さく分かれていれば、コンフリクトが起きる可能性は少なくなる。 この2点がある。 どうもコンフリクトを怖いもの。起きたら世界の破滅みたいに思っている人がいるみたいだけど ぜんぜん違う。起きるのは当たり前のことだし、他人が作ったものならまだしも 自分が作っているものなら、どうすればいいかなんてすぐにわかる。 そしてコンフリクトが起きるのはなぜかという話。それはコードが単一責任原則を 満たしていないから簡単にいえば、修正すべきコードがあちこちに分散しており ようするにコードが汚いから。 コンフリクトは起きたら直せばいいだけだが、 面倒くさいから、起きないほうが楽というのは確か 各コミット（そこでいう1, 2, 3, 4）がそれぞれ小さい修正になっており、 それぞれがちゃんと意味がある単位で分かれていれば、そうそうコンフリクトは起きない。 473 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 08:28:44.00 ID:ezOKhhiH.net] >>466の1のコミットを3のコミットに含めるか？ という質問の答は、含めるべきことであれば含める。 そうしないと逆にコンフリクトが多くなるから。 何故かと言うと、1と3をまとめたい＝意味がある単位で考えてまとめるべきこと。 単一責任の原則を満たしており、意味がある単位で小さいコミットというものは、 多くの場合同じ箇所の修正になる。「1と3は同じ箇所の修正」っていうことを覚えておいてね。 そして例えば新しくコードを書いている途中で、既存のバグが見つかったとする。 新しいコードはバグを直さなければ正しく動かない。 だから先にバグを修正するために、5というコミットが必要になったとする。 （どうでもいいが1〜4数値は新しい方を大きくしてくれｗ） そうすると5のコミットの続きからに、1〜4をrebaseしなければならない。 その時に3でコンフリクトが発生すると3を直したあと1でもコンフリクトが起きるだろう。 なぜなら、同じ箇所を修正しているから。 さらにむずかしいのは、最終的には1が終わった形にしないといけないわけだけど 3のコンフリクトをどう解決するか？って問題がある。 3の時点で1が終わった形にするわけには行かないんだよ。 3で発生したコンフリクトを直したあとに、1の修正を行うわけだから。 どう直せばいいかわからないものが多数発生する。 これがコンフリクト怖い病になる原因だねｗ だからコンフリクトが起きる頻度を少なくするためにも、 1. 各コミットは小さい修正にしておく 2. 意味的にまとめるべきコミットはまとめておく これを徹底することで、最終的にコンフリクトが起きにくくなる。 474 名前：デフォルトの名無しさん mailto:sage [2015/05/18(月) 09:10:31.18 ID:ezOKhhiH.net] 時間がかかる暗号化キーの生成待ちで暇だから書き込みｗ コンフリクトっていうのは同じ場所の修正がかぶると 発生するっていうのを意識しておいた方がいい。 あたりまえだと思うけど、じゃあどうすればいいかまで考えているだろうか？ 他人とのコンフリクトは、単純に同じ箇所を修正したときだが、 自分自身とのコンフリクト、rebaseでよく起きるね。（下手だと） こっちもコンフリクトが起きる原因は同じ箇所の修正だからなんだ。 もし同じ箇所の修正がなければ、rebaseしてコミットの順番を 入れ替えたりしてもコンフリクトは発生しない。 じゃあ同じ箇所の修正はいつ発生するか？ それはこういうの * Aという修正をコミットした * Bという修正をした * Aという修正にバグが見つかったので修正した * Aに機能が足りなかったから追加した * Aの変数名でタイポしていた こういうのを放置したまま、作業し続けていざmasterにマージする段階で コンフリクトが起きてrebaseしなきゃならないってなった場合に 多くのコンフリクトが発生して、大変なことになる。 こういうのは随時rebaseしておくことが重要。 バグとかタイポとかさっさとまとめておく。 * Aとい修正をコミットした * Bという修正をコミットした こういうふうコミットを意味がある単位で小さくまとめておけば、 コンフリクトの回数は減るし、直すのも単純になる。 475 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 08:43:08.91 ID:ETXaESJa.net] >>466 自分なら、普通は避けるな。 でも理由は、ソースの修正箇所がコンフリクトするからじゃないよ。 1->2->3の順にコミットして、1と3をまとめたら、2->1+3になるわけだよね？ このとき、2が1無しでも正しく動作するか分からないからね。 もし、2と1+3を別々のコミットとして履歴に残すなら、どっちのコミットでも 正しく動作することを担保したい。 でも、コミットをまとめるためだけに、（自動テスト環境があったとしても） 2だけのテストをまたやり直すのを避けたい。 だけどそれも、プロジェクトごとのgitの運用ルールによるかもしれない。 コンパイルエラーになるコミットがリモートリポジトリにあるのは構わないとか、 過去のコミットが動かなくなるのは構わないとかのルールになってるなら、 好きなようにまとめるかもしれない。 476 名前：デフォルトの名無しさん [2015/05/19(火) 10:17:56.67 ID:S02ugk9h.net] すいませんこの流れに出ているコミットのやり方ってどうやるんですか？ 477 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 11:07:38.39 ID:0hZF5IeJ.net] >>471 > このとき、2が1無しでも正しく動作するか分からないからね。 1+3のテストだけやればよくね？ 2がテストに通らなくても、 自動テストがあるならすぐにわかるし、最悪テストに通らないときだけやらなければいい。 もし自動テストがなければ、2がテストに通らなくても 「調べようがないので、通らないことがわからない=通っているのと一緒。」 ←重要 それにさ、コミットが多かったら、正しく動くことを担保するのは大変だよ。 * Aが正しく動くことを確認 * Bが正しく動くことを確認 * Cが正しく動くことを確認 * Dが正しく動くことを確認 というつもりだったが、たいていバグはあとから見つかるんで、 あとからAが正しく動いていなかった！と判明したらどうする？ * Aが正しく動かない * Bが正しく動かない * Cが正しく動かない * Dが正しく動かない * Eで修正 君は、どのコミットでも、正しく動くことを担保したいといったが A〜Dは全部正しく動かないことが担保されたわけだｗ EをAに混ぜ込めば直すことができるが、それをしないならば、A〜Dのコミットは正しく動かないままだよ。 A〜Dは正しく動かないが、でもその時はテストコードがなかったから分からないわけだよね。 それって、つまり「重要」って書いた所と同じ状態なんだが。 過去のコミットが動かないのは構わないというルールなら、そのまま放置でいいかもしれんが（笑） 478 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 12:47:36.82 ID:0hZF5IeJ.net] >>472 コミットのやり方？ 普通にgit addでコミット対象を選んで git commitでコミットするだけだけど？ コミットの順番を入れ替える話？ それならgit rebase -iだよ。 479 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 14:21:12.63 ID:oDPa6Z2V.net] >>473 バグの話じゃないでしょ 480 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 17:37:58.03 ID:0hZF5IeJ.net] >>475 バグの話ではこうなるよね？ つまりこれは「正しく動かないがテストコードがないから自動テストには通る」 という状態をどう考えてるかって話なんだよ。 俺はそれは自動テストに通るってことでいいじゃないかって言っている。 これがいやなら、前のコミットに混ぜて修正するしか無いわけだよ。 で、俺は 前のコミットに混ぜても自動テストに通るなら それでいいじゃないかとも言ってる。 ちなみに俺は特に大きな理由がない限り、テストケースも含めて 前のコミットに混ぜて、全てのコミットを正しく動くようにしている。 皮肉なことに>>471が言ってる > どっちのコミットでも正しく動作することを担保したい。 を実践出来てるのはこのやり方なんだ。 481 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 17:38:54.11 ID:0hZF5IeJ.net] ×テストケースも含めて ○（自動）テストコードも含めて 482 名前：デフォルトの名無しさん mailto:sage [2015/05/19(火) 21:49:21.81 ID:ez1Du3hq.net] 言ってるところのポイントは、1無しで2だけになったコミットが、 コンパイルと自動テストに通るかどうか、わざわざ確認するか？ ってことだな。 確認するなら、影響する各コミットでわざわざそれを確認するのは 面倒くさい、というデメリットが発生する。 確認しないなら、古いコミットは（コミットした当時は通ってたであろう） コンパイルと自動テストはもう通らないかもしれない、というデメリットが 発生する。 そのデメリットを避けるために、「間をとばしたコミットまとめはしない」 のが>>471だね。 >>476が結局どうしたいのかについては知らない。 483 名前：デフォルトの名無しさん [2015/05/19(火) 23:00:23.53 ID:aRRI5SvP.net] >>373 git init touch a; git add a; git commit -m "add a" touch b; git add b; git commit -m "add b" touch c; git add c; git commit -m "add c" "add c"のログを"add a"に加えたいんですがgit rebase -iでどうやるんでしょうか？ pick 07d5e6a a pick f550031 b pick 5d295c0 c このpickをどう書き換えたらbを飛ばしてaにまとめられるのかわかりません pick 07d5e6a a pick f550031 b fixup 5d295c0 c これだとbにまとまってしまいました どうやるのか教えてください 484 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 00:37:31.29 ID:NtQ54Cc0.net] 過去から現在までの全コミット情報がローカルに蓄えられるの？ そんな全部なんていらんし、途中からでいいんだけど どうしたらいいの？ 485 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 01:04:01.37 ID:jSvt41UG.net] >>479 pick 07d5e6a a fixup 5d295c0 c pick f550031 b エディタで順番を入れ替える。 486 名前：デフォルトの名無しさん [2015/05/20(水) 01:50:27.49 ID:TO++lAfh.net] >>481 できました これは便利ですね これでログを今よりも綺麗に出来ました 487 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 09:25:54.36 ID:v+0+7waM.net] >>480 >>143 488 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 12:05:48.01 ID:qzEPJuIN.net] >>478 あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？ たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。 コミットが何十個にもなってるでしょ？それはコミットをまとめないからだよ。 それから一度に変更（マージ）する内容が多すぎだろうね。 これはもう仕事のやりかた、作業の進め方のレベルの話だね。 まともなレビューが行われているかどうか不安になるな。 まず自動テストをしているならば、その内容をテストしたのは明らかなわけで、 何をレビューするかというと書いてあるテストとコードが正しいか漏れがないかだよ。 人力テストをしてもらうんわけじゃない。 つまりコード見て理解できる程度の量でないといけない。それも短い時間でね。 修正内容がバラバラで、順番も修正箇所もごちゃまぜな大量のコミットを一個ずつ見るのは不可能だし 全部まとめて見ると一度に大量のコードを見ないといけなくなるから大変。 レビューアに負担をかけるようなコードはだめだよ。 あと一連の機能を全部まとめてレビューしてもらってるでしょ？ 細かい機能毎にわけないとだめだよ。リファクタリングならリファクタリングだけでマージ モジュールの追加なら（テストコードも含めて）モジュールだけのマージ それらをいっぺんにレビューするよりも、分けたほうがレビューアの負担は減るのはわかるよね？ 君はいっぺんに全部やろうとするから、コミットまとめたり入れ替えた時の時の再テストが 大変とかいう話になってるが、俺の場合は、細かく分けてマージ可能な最小単位に分割するから、 一つの作業ブランチに含まれるコミットは数個しかない。 君、悪循環に陥ってるよ。コミットをまとめないから、マージできる単位に分割できない。 分割できないから一つのブランチの内容が多くのコミットになる。コミットが多いから並び替えたら コンパイル・テストが通るか不安になる。面倒くさい。だからコミットをまとめないって。 489 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 12:10:17.30 ID:qzEPJuIN.net] 長々と書いてしまったが、疑問点としてまとめるわ。 一連の機能を作っている時にリファクタリングやモジュールの追加は 絶対に発生する。ミスも発生する。 一連の機能をいっぺんに全部レビューするのはすごく大変だから 小さく分けた方がいい。 ならば一連の機能をリファクタリングだけのブランチ 機能追加だけのブランチ等にわけて、出来た所からマージした方がいいが、 コミットを入れ替えたりまとめたりしないで、どうやってそれを実現するの？ 490 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 16:22:35.29 ID:NtQ54Cc0.net] ちょっと書いてテスト、コミット を繰り返すならコミット量は自然に増えるよね 491 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 16:38:52.05 ID:qzEPJuIN.net] >>486 こんな感じにすればいいよ。別にコミットは実際の作業順に合わせる要はない。 * ちょっと書く * テスト * ちょっと書く * テスト ↓ 並び替え（これが失敗することはまずない） * ちょっと書く * ちょっと書く * テスト * テスト ↓ まとめる（これが失敗することもまずない） * ちょっと書く * テスト この作業を随時やっていく。 ・・・つづく 492 名前：483のつづき mailto:sage [2015/05/20(水) 16:47:02.59 ID:qzEPJuIN.net] ところで「ちょっと書く」と「テスト」を一つにするか？ それは内容によって変わる。 コミットを（まとめるべき内容なら）まとめながら作業するのは一緒だが リファクタリングの時は「ちょっと書く」と「テスト」はまとめない。 * テスト * ちょっと書く（リファクタリング） 最終的にこうなる。なぜならリファクタリングしても動作は変わらないはずなので、 コードを書いた前と後で全く同じテストが通るから。 それを確認するためにも、リファクタリング前に（テストが不足している場合は） テストを書いておき、そしてリファクタリングを行う。 またコミットを入れ替えることを前提にすると「後からテスト駆動」が実現できる。 理想としてはテストを先にやるのがテスト駆動なのだが、現実には後からミスが見つかったりして コードを書いてからテストを追加することが多い。 実際の作業ではコードを書いてからテストを書いたとしても、そしてそれらが コード書いてテスト、コード書いてテストって繰り返していたとしても、 テストだけまとめて1つ目のコミット。リファクタリングして2つ目のコミットの形にできる。 これでレビューする人は、問題なくリファクタリングできたことを確認できるわけ。 もちろん仕様変更や機能追加などであれば、テストコードと修正を 分ける意味が無いし、一つにするべきなのでまとめる。 493 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 16:59:43.68 ID:NtQ54Cc0.net] >>487 ローカルでのコミットはどんどん細かく、プッシュの粒度はテスト通ってから という方針でやってたんだけど、gitはそういうのに向かないんですね 494 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 17:01:43.80 ID:NtQ54Cc0.net] そうかこれがあれか、使い捨てブランチ使えってみんな言ってたやつか じゃあ俺のgitの使い方は間違っているのか 495 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 17:03:34.98 ID:NtQ54Cc0.net] そうすると、メインのコミットは綺麗な間隔で最小限に抑えられて かつ テスト用ブランチでどんどこ適当なコードを書きなぐれるのか？ みんなそこまでやってたの？ すげーな 496 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 17:07:28.79 ID:qzEPJuIN.net] >>489 なんで？ 意味がある単位で小さくすればいいよ。 でも意味がないのに分割する必要はない。 （ローカルでの作業中に） 例えば、関数名これでいいかな・・・コミット やっぱり、関数名こっちにしよう・・・コミット いやいや、やっぱり戻そう・・・コミット ってタイポしてたよ修正・・・コミット これってコミットを細かく分けたかったわけじゃない。 作業上の都合でコミットがわかれてしまっただけ。 こういう意味が無いコミットはまとめるべき。もちろん 別々の修正であれば、どんどん細かく分けた方がいい。 細かく分けておくと並び替えや分離がしやすくなるよ。 修正しているうちにコミットがたくさんになって、これ一度に レビューするの無理だろと思ったら、抜き出して別のブランチにするとかね。 でももし意味が無いコミットに分かれていたら、逆に抜き出すの難しくなるからね。 重要なのは、意味がある単位で小さいコミットに分けておくこと。分ける意味が無いものはまとめること。 これがコミットをうまく管理するコツだよ。 497 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 17:15:41.65 ID:qzEPJuIN.net] >>491 > みんなそこまでやってたの？ すげーな git歴は2年ぐらいかな？ 最初は当然できなかったよｗ ただレビュー可能なコードの重要性はわかっていたから、 subversion使っている時、こんな行き当たりばったりの修正履歴じゃ レビューできないだろっていう認識はあった。 （計画的にやれって思うかもしれないが、ミスや漏れどうしても発生する） gitを使ってからはどうすればレビューしやすくなるか？を 考えてコミットを作るようにしていたよ。 （ちなみにどちらかと言うと俺はレビュー依頼する側じゃなてレビューする方だけどね） 498 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 17:18:24.50 ID:zo5n24wv.net] >>466 そのケースで実際にコンフリクトが発生する場合は 2 の粒度がでかすぎるってのがよくあるパターンなので、 2 を分割して 4←3+2a+1←2b という形になるようにしている 499 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 21:06:38.40 ID:vVwXnjIW.net] >>484 >あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？ >たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。 コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。 たぶん>>484の場合は、例えば分野が小さなWebサイトの開発とかで、 そもそもの開発規模や自動テストの規模が少ないとか、昔のコミットや 昔の挙動を残しておいても問題調査の役に立つことが少ないとか、そういう 特徴があるんだろう。 500 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:00:00.11 ID:qzEPJuIN.net] > コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。 数秒で終わらないのが困るのなら、大量にあるコミットが ある状態で、rebaseとかどうするのさ？ 数秒で終わらないなら、逆にコミット減らすべきだろ。 矛盾してるぞｗ あと中間ファイルが残ってるはずだから、 適切にソースコードが分割されて依存関係が少ないなら 一つ一つのコミットの修正が僅かなはずなので コンパイルにそんなに時間がかかるはずがない。 501 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:05:10.63 ID:qzEPJuIN.net] > 昔のコミットや昔の挙動を残しておいても > 問題調査の役に立つことが少ないとか これも逆に不要なコミットは消すべきだよね。 何か勘違いしてる（他の人にされそう）だから 念の為に言っておくけど、俺が言ってるのは、 本来一つであるべきコミットは一つにするって話で 何でもかんでもまとめろって話じゃない。 だから当然、昔のコミットは残ってる。 調査に使うよ。git bisectで二分探索で。 でだ、この時大量にコミットがあるとその分探索の回数増えるわけで、 コンパイルと自動テストが数秒で終わらないとしたら大変だよなぁ？ 問題調査のためにも無駄なコミット減らしたほうがいいって結論になるぜ？ 502 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:19:59.27 ID:MjY1jVeQ.net] >>486 ＞数秒で終わらないのが困るのなら、大量にあるコミットが ＞ある状態で、rebaseとかどうするのさ？ だから、「間を飛ばしたコミットまとめをしない」って言ってるんじゃないのか？ A→B→C→Dの順にコミットされてるなら、連続したBCやBCDをまとめるのは コンパイルや自動テストに問題ないから。 503 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:30:23.27 ID:qzEPJuIN.net] >>498 rebaseって二つの複数の意味があるから気をつけないといけないなｗ master(1) 　　　　＼A→B→C→D で開発をはじめてさ、他の人のマージが先に加わった時、 master(1) → master(2) 　　　　＼A→B→C→D master(2)からの開発にrebaseするという話。 master(1) → master(2) 　　　　　　　　　　　　　＼A→B→C→D この時、A〜Dまですべてが書き換わるわけだから、 コンパイルと自動テストをするわけでしょ？ 時間がかかるのならなおのこと、まとめておいたほうがいいでしょ。 master(1) → master(2) 　　　　　　　　　　　　　＼AC→B→D もしかしてこのタイプのrebaseも禁止してるのかな？ なんか下手なコミットのせいで、時間が掛かるから便利なものを 封印せざるを得ない状態を作っているようにしか見えない。 504 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:49:40.28 ID:MjY1jVeQ.net] その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが なんでfeatureブランチの各コミットを直接masterにつなごうとするのかがよく分からない このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？ 505 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:50:55.88 ID:qzEPJuIN.net] もう一つ「もしかしてこのタイプのrebaseも禁止してるのかな？」 と思った理由もかいておく。 A, B, C, D が同じ箇所の修正（前のコミットのやり直し）をして 本来一つであるべきものが分かれていたとする。 そしてmaster(2)にrebaesしたときにAでコンフリクトが発生したとする master(1) → master(2) 　　　　　　　　　　　　　＼A→B→C→D そうすると、B, C, D も同じ箇所の修正だから 必然的に、BでもCでもDでもコンフリクトが発生するわけよ。 わー、大変だ。コンフリクトだ。しかもこれさっき直したじゃないか？ コンフリクトわけわからん。わー。ってなってるはず。 同じ箇所の修正を一つにまとめておけば、コンフリクトの修正も一回だけだよ。 関連あるコミットをまとめておかないから、コンフリクトが沢山発生する。 時間かかるし正しく修正できたわからんからrebaseしない方がいい！ってなってると思う。 コミットが沢山にわかれている → コンフリクトが沢山発生する → そうなるからrebase禁止 と 考えているのだろうが、本当の原因はコミットが沢山にわかれていて、それが意味もない順番でごちゃごちゃ並んでることだから。 関連あるコミットは随時まとめておく。順番も適切な順番になおしておく。そうしておけばコンフリクトの発生は少ない。 コミットの数も少なくなるし、だからrebaseしてもコンパイルにも自動テストに時間はかからなくなる。 コミットは意味がある形で最小限に抑えられているから、レビューも楽になる。 後から問題の調査をするときも、存在理由がわからない大量の謎コミットを見る必要もなくなる。 gitの機能を最大限使うことが出来るわけよ。 ってもう何回も言ってるねｗ 毎回長文でｗ 506 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:54:58.15 ID:qzEPJuIN.net] >>500 > その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが その場合ってどの場合？ 一人で開発してるんじゃないんだよ。 自分が開発をし始めた時からコードは変わっているから これをmaster(3)になんか出来ない。 他人の仕事を消してしまうじゃないか。 他人の仕事と自分の仕事を合わせてないと行けないんだよ。 コンフリクトが起きようと起きまいとね。 コミットが沢山あればあるだけ、全てのコミットが 正しく動くか再テストをする必要がある。 507 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 22:58:20.56 ID:MjY1jVeQ.net] 何となくだが、 ＞master(1) → master(2) ＞　　　　　　　　　　　　　＼AC→B→D これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。 これが許されるチームなら、各メンバーが自由にコミットをまとめても、たしかに問題ないな。 508 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:01:15.60 ID:qzEPJuIN.net] >>500 > このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？ 別ブランチにできるかどうかは内容次第だね。 コミットとしては一つ一つ取り込めたとしても 機能としては一つ一つでは完成しないこともある。 で、俺は一連の作業中に、先にマージ可能なものができたら、 別ブランチに抜き取って先にマージした方がいいとも書いた。 そのためにも、コミットをそのまま放置するのではなく 関連があるものはまとめていくようにって言ってるんだよ。 関連あるコミットがバラバラだったら、別のブランチに抜き出すのは大変だからね。 それもあって、そのケースでAとCをまとめたんだよ。 つまり最初のAとCが関係ある内容ならまとめますか？の質問の 答えはまとめた方がいいってこと。 で、これやるとコンフリクトが〜とかいって、まとめない方がいい 並び替えないほうがいいって言ってる人がいるわけよ。 509 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:05:27.02 ID:qzEPJuIN.net] >>503 > これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、 > 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。 話がループしているがｗ rebase後にACとBのコンパイルと自動テストをスレばいいだけだろう？ そんなのすぐに終わる。たった2回（ACとB）じゃないか？ すぐに終わらないのは、コミットがたくさんあるからだよ。 そりゃコミットが10個も20個もあれば、10回20回もコンパイルと自動テストをしなきゃならんだろうさ。 コミットがたくさんあるために、rebaseを許さない状況になってしまっている。 rebaseってさ、gitの基本じゃん？ チュートリアルの最初のほうで出てくる作業だよ。 許されるも何もこれは普通にやるべきことだよ。 ね？ 下手なコミットのせいで普通にやることがやれない状況になってしまっている。 コミットがたくさんあるために、rebase（master(2)への付け替え）を 封印してしまってるでしょ？ 510 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:19:51.82 ID:MjY1jVeQ.net] >>504 AとCをまとめますか？の回答には「そう思う」だが、 AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。 AとBとDはブランチを分けるな。 もしブランチを分けとけば、レビュー前？Push前？にAのバグに気付いても、AとCのコミットは連続してるだろうからな。 逆に、レビュー後？Push後？に問題に気付いたなら、自分の負けを認めてバグ修正のコミットを残す。 一方、後になって「コミットが連続しない、AとBとDをブランチに分けておけば良かった〜」なんてなるようなら、自分の腕のなさを呪ってブランチを切りなおす？？？かな。 511 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:21:45.30 ID:MjY1jVeQ.net] >>505 ＞そんなのすぐに終わる。たった2回（ACとB）じゃないか？ 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ

---

---

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

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