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/ 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）じゃないか？ 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ 512 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:28:53.73 ID:qzEPJuIN.net] > AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。 > AとBとDはブランチを分けるな。 分けたいなら後で分ければよくね？ 作業用ブランチなんだからそれはどっちでもいい話だと思うが。 AとBとDがお互い前のコミットに依存している場合、 最初にブランチを分けておくと、ごちゃごちゃしてくると思うが。 Aを作ったはいいけれど本当にこれでいいかは、そのAを使う Bを作らないとはっきりしないことだってあるしさ。 残念ながら人間はミスを犯すんで、どうしても後からバグを発見する。 後から修正をするものだよ。 一つのブランチで作業しておいて、ある程度納得がいったら別ブランチに 抜き出せばいいと思うけど。コミットが整理されていれば簡単な作業だし。 それとレビューは間違いを見つけるものだから、修正が入るのはあたりまえだよ。 レビュー中はまだ作業中段階。作業中のごみコミットを残したままマージする必要はないよ。 一連のレビューが終わったら整理すればいいだけの話。整理し終わってそこで完成。 513 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:30:22.13 ID:qzEPJuIN.net] >>507 > 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ そんなのすぐに終わらないって前提がおかしいんだよ。 だって開発中に何度もコミットしてるじゃん？ その段階でコンパイルと自動テストしてるじゃん？ コミットがたくさんあるのなら、その分だけやってるわけじゃん 開発中にすぐに終わらない作業を何回もやってるのか？ まずそれを解決した方がいいぞｗ 514 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:35:21.24 ID:qzEPJuIN.net] 補足すると、コンパイルがすぐに終わらないってのはおかしい。 なぜなら、コミットの前後で修正されるファイルは少しだから 該当ファイル以外のオブジェクトファイルはそのまま使えるわけで 差分のみのコンパイルしかしないはずだから。 そして自動テストは作業中は関連のあるところだけテストすれば良い。 で、最終段階（もう変更がないと思った時点）で全部やればいいんだよ。 最後にブランチ内の全コミットをテストするのか！という疑問に対しては だからぁ、コミット数が多いから大変なんじゃねぇかそれ。という話。 関連あるものはまとめろ。先にマージできるのは別ブランチに分けろ。 コミットは小さく分けろ。だが無駄なコミットはまとめろ。 515 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:39:45.06 ID:MjY1jVeQ.net] 例えばC言語だったらヘッダファイルを書き換えれば多くのソースファイルに影響するし、 自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。 例えばWebサイトの開発とかでは、そういうのほとんどないだろうし、ぶっちゃけ過去より今が大事なのかもしれない。 （過去の状態が「Webサイトの純然たる作りかけ」とかだったら、そのスナップショットを完全に残すことに価値はないだろうし） だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。 その方が、短期的な効率は出るだろうしさ。 516 名前：デフォルトの名無しさん mailto:sage [2015/05/20(水) 23:56:43.98 ID:/feEo/hs.net] ブランチってほんとにみんな使ってる？ gitのブランチって使いづらくね？ 517 名前：デフォルトの名無しさん [2015/05/21(木) 00:28:17.62 ID:0lqSGmSk.net] プルリクエストを送るときにmasterブランチ以外のブランチで作るのが定番ということで fix_numberブランチを作って"fix number value"ってログを書いてコミットしました その後はプッシュする前に最新の情報を取得するべきって聞いたのでgit pullしました そしたら There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> fix_number_value ってでました これってリポート上のmasterブランチを指定したらいいんでしょうか？ 実践で誰かと一緒に開発したことがないので怖くてどうしたらいいのかわかりません ご教示おねぎあします 518 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 00:41:14.37 ID:/NlBmKMh.net] >>512 俺もそう思ってた でもわかった、gitのブランチにはブランチモデルが必要なんだ 自由になんでも出来すぎるからブランチモデルで制約を付ける 「A successful Git branching model」てのを見つけて、 git-flowを使うようになってからだいぶまとまりが出来てきた その後で他にもいくつかブランチモデルがあることも知った 今はブロジェクトの初めに git-flowを使って「A successful Git branching model」をベースにやります。変更点はこれこれ。 みたいに宣言することにしてる。 だからお願い。VisualStudioにもgit-flow付けて、Microsoftさん。 519 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 11:22:31.08 ID:PvdFF4ay.net] >>511 なんか引っかかるねｗ 短期的じゃなくて長期的な効率が出てる。 ヘッダを書き換えれば多くのソースファイルに影響する話なら知ってる。 そうならないためのやり方があるのは知ってるかい？ ビルド依存を回避するような作り方をするんだよ。 あんたのやり方だと普段の開発から時間かかってしょうがないでしょ？ ちょっと修正するたびにビルドに多く時間がかかってるはずだよね。 それはもはやgitとは関係ない話だよ。 それからウェブの開発ではないって思ってるかもしれないけど、 今はウェブの開発でもビルド行う。 > だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。 > その方が、短期的な効率は出るだろうしさ。 なんか、俺が知らないと思ってそういうこと言っているような雰囲気だが 俺知ってるからね？ ウェブだけじゃなくてビルドが必要な開発も。 520 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 11:33:41.78 ID:PvdFF4ay.net] 何が引っかかるかわかったわ。 最近の若いもんは〜みたいな発言になってるからだ。 言葉の節々に、ウェブ開発をしてるもんは〜とか テストしてるわけがないはずだ〜とか 過去はどうでもいいと思ってるはずだ〜とか まともな自分の想像ばかり言ってる。 521 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 11:34:23.74 ID:PvdFF4ay.net] なぜか書き間違えたｗ × まともな自分の想像ばかり言ってる。 ○ 的はずれな自分の想像ばかり言ってる。 522 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 11:55:03.21 ID:PvdFF4ay.net] > 自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。 これに関してはだから何なんだ？といいたい。 （ごみ）コミットがたくさんあって、コミット毎に全部 アプリケーションの再起動を行っているのか？ だとしたら、テスト効率が極めて悪い。 10個のコミットがあって、それぞれのテストに 1時間かかるとしたら10時間じゃないか？ 俺ならまずおおむね十分だと思われるテストだけを行って コミットを減らしてからテストするね。5個に減らせば5時間で済む。 コミットしてテストした後で、さっきのコミットに混ぜるべきコードをコミットしてテストしたら さっきテストした時間は無駄になるじゃないか。 後から修正が入るかもしれないような不安定な所のテストに時間はかけない。もう修正は入らないなって 思った時にちゃんとテストをする。コミットを減らしてテストしたらテスト時間も減る。 git以前にテストのやり方そのものを見なおしたほうがいいよ。 効率を考えないで流れ作業をこなしているかのような開発になってる。 523 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 12:05:21.48 ID:PvdFF4ay.net] >>512 > ブランチってほんとにみんな使ってる？ > gitのブランチって使いづらくね？ 一人で開発してるとか？ 使いづらいかどうかは置いといて 使わないと、複数人で並行して開発できないよ。 使いづらいと思ったことはないな。 最初の頃は苦労したけど、それはgitのブランチのせいではなくて 自分の技術力不足だってわかっていたし。 作者のリーナスがどうしても必要だって思って作った道具であり gitの機能も必要だと思っているからこそ作ってるわけだしさ。 もっといい案があるというなら別だけど、わかってないのに リーナスが作ったものに、ケチつけるなんてだいそれたことなんか出来んってｗ わかった今ならよく出来てるって思うよ。 524 名前：デフォルトの名無しさん mailto:sage [2015/05/21(木) 22:28:03.52 ID:fr6zPWaF.net] Windowsでウィルススキャンソフトが入ってる状態でgit checkoutは時間がかかり過ぎるから、使いづらく感じるかもな 525 名前：デフォルトの名無しさん mailto:sage [2015/05/22(金) 00:01:21.71 ID:6DaqA/5u.net] >>519 リーナスだろうと関係ないよ リーナスには使いやすいものでも 俺には使いにくいってのは普通にあるよ 526 名前：デフォルトの名無しさん [2015/05/22(金) 22:43:05.39 ID:SSdLqWaE.net] >>512 ブランチってほんとにみんな使ってる？ 俺は一人開発だけど、master と daily の二つの branch を使っているよ。git 使い始 めの一年ぐらいは master だけだったけど。 master の commit/merge は version 番号より少し細かい粒度で行っている。daily branch は bug/issue tracking の粒度より少し細かいぐらいで commit している。とい うより、daily branch の commit message の殆どは bug/issue 番号に紐付けている。 Version 番号の粒度の履歴に bug tracking 粒度の履歴を残したくない。 ちなみに bug/issue tracking はソースとは別ディレクトリのテキスト・ファイルで git 管理している。 >>512 gitのブランチって使いづらくね？ Time stamp が checkout 時刻に強制変更されてしまうのが使いにくいと感ずる。make compile 時の便利さは分かるが、ファイルの time stamp 自体は重要な属性だから。俺 が git を作ったならば、time stamp を commit 時の時刻にするオプションを絶対設け ていた。 実際には commit 時刻に変更する script を書いてあるけれど、殆ど使っていないの実 情だ。その script が必要になるのは master 側だけだから。そして その master 側で push するときには、time stamp など構っていれらない状態が殆どだという実情なのが 情けない。 527 名前：デフォルトの名無しさん mailto:sage [2015/05/23(土) 16:05:57.79 ID:4OfmjrZC.net] プロジェクトがすごく小さい場合には、 途中経過の整合性が合わなくなるのが許されたり、 途中経過の整合性を合わせるためのテストやり直しが許されることがあるんだな pushした修正がバグってたからって、pushしたもんをリベースで打ち消すのはご法度と思っていたが プロジェクトの大きさによってはそれもあり得るということか 528 名前：デフォルトの名無しさん mailto:sage [2015/05/23(土) 17:21:41.69 ID:x743ZDZ3.net] pushした先がリベースが許されるブランチかそうでないブランチかって違いであってプロジェクトの大きさは関係ないんじゃないの？ 529 名前：デフォルトの名無しさん mailto:sage [2015/05/23(土) 17:24:16.06 ID:x743ZDZ3.net] いや逆か。 push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。 530 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 00:38:55.87 ID:NuukhrjT.net] push後のリベースが許されるブランチ＝他の誰も見ていないブランチ？ サブプロジェクトどころか、一人プロジェクトだな 531 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 10:38:28.38 ID:GI5iGoR+.net] 話題がループしてるな。もうすこし世の流れを学んだ方がいいよ。 gitだと特に、ブランチの運用によって前提が大きく変わる。 GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、 それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。 だからpushしたブランチをrebaseしてもまったく問題ない。 むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい 532 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 11:16:37.86 ID:VWanxcqX.net] >>526 ん〜と、前提が大ブランチになってるとそうかもしれないけど Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから 得意技を積極的に使った方がお得な気がするな うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた その代わり、細かくコミットしろ、作業単位でブランチを分けろ って、半年くらいは口うるさく言い続ける必要があったけどね レビューの時にコミットツリー図を見ながら ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか ややこしいコンフリクトが生じた時に どういう手順ならマージが簡単だったかとか 具体的に教えたり、みんなで考えたりした 新しい文化を根付かせるのは大変だよ、いつでもさ 533 名前：デフォルトの名無しさん [2015/05/24(日) 14:14:44.04 ID:J9ZjzLe3.net] >>527 だからpushしたブランチをrebaseしてもまったく問題ない。 branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処 に push するの？ レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？ 534 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 15:41:15.45 ID:1k2HbjOC.net] ブランチを公開する際に中央リポジトリにpushする形式が考えられる 535 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:35:16.30 ID:LHzJ6dIN.net] 今コミットした後にgit pullしたらリモートの最新のログ（1個だけ）が追加されてしまいまして 今コミットしたログの後にそのリモートのログが来てしまいました git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません これってどうしたらいいんでしょうか？ 536 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:41:30.07 ID:Ewhf1zLw.net] >>528 となると、やはり 本体はSVNで、ローカルはgitで 別に管理したほうが全体が幸せになりそうだな 537 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 19:50:34.06 ID:Jl9gFOkM.net] レビューが終わって共有ブランチにpushしてからバグが見つかった場合に 共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな 538 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 20:03:35.12 ID:Jl9gFOkM.net] >>532 この人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ （それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう 539 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 21:34:38.73 ID:VWanxcqX.net] >>532 それはいい解の一つだと思う。特に移行期には。 うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。 でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。 当時の対象プロジェクトがちょうど区切り良く、 過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、 フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。 最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど 結局馴染んでくればgitの方が扱いやすくなってきたよ。 しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。 （でも日本語変だよマイクロソフトのgit） 540 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 22:05:23.23 ID:VWanxcqX.net] >>534 おれ>>528な 「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、 俺がgit使ってる（使わせてる）理由の一番大きい所は 「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。 俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。 レビューもそのままで特に問題は無かったな。 でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 特に問題だったのは（svn使っていた頃の話ね） 何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。 svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。 ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。 そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。 今は「マージ操作間違えても俺が直してやる。 安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。 これだけでも後から意図を読み取るのは随分楽になったよ。 541 名前：デフォルトの名無しさん mailto:sage [2015/05/24(日) 22:19:55.92 ID:mdHWC0Am.net] 状況によるけどコミット分けたほうが見やすいというのは複数の作業単位(ブランチ)に分けるものを 一つのブランチに押しこんでるからじゃないの 機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし >>533 閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう >>531 リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ 次から最初からブランチ切っとけばこんなことで困らん 542 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 03:10:39.76 ID:WhsXE+Ib.net] >>536 個人でブランチ作ってコミットしたあと、どうすればいいの？ そのブランチを本家に取り込ませるの？ 543 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 05:59:36.31 ID:/VFybrtg.net] > でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 これ大事よね master に 544 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 06:01:10.35 ID:/VFybrtg.net] 途中で書きこんでしまった > でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。 これ大事よね master に wip と fix typo が積み重なってた時は流石に萎えたけど 545 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 08:14:58.07 ID:y6DNlXTS.net] >>540 ＞master に wip と fix typo が積み重なってた時は流石に萎えたけど そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう 546 名前：523 mailto:sage [2015/05/25(月) 09:19:23.83 ID:E69UDjHE.net] >>529 > >>527 だからpushしたブランチをrebaseしてもまったく問題ない。 > > branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処 > に push するの？ > > レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？ 自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。 典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する 547 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 13:36:42.28 ID:XuKAmWn9.net] 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、 まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん 548 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 13:49:29.09 ID:XuKAmWn9.net] >>531 あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い 検索すりゃ方法わかると思うので調べてみてくれ 549 名前：デフォルトの名無しさん mailto:sage [2015/05/25(月) 22:51:38.00 ID:o/eCAQPj.net] 共有ブランチ上のバグを直すために共有ブランチ上のコミットを書き換えるんだとしたら、 書き換え前のコミットををベースにしている人への配慮が必要そうだな 各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース してください」って頼んで回れる環境が必要だ 550 名前：212 mailto:sage [2015/05/25(月) 23:42:12.33 ID:fVXVPz7E.net] gitってなんでMakeFileにuninstallが用意されてないんですか？ アンインストール作業が苦痛なんですよ makeだけでアンインストールさせてくださいよ 551 名前：538 mailto:sage [2015/05/26(火) 00:30:58.55 ID:VHuDuKFu.net] >>543 > 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、 > まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん 中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。 これが GitHub flow な。 元が「 >>526 Pushしたブランチは書き換えてはならん」への反論だから、 そうでない運用もごく一般的、という主張をしたということ。 552 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 08:35:26.55 ID:n+9g7Zgu.net] 「各メンバーが、個人用ブランチをリモートリポジトリ上に持っている」 これじゃ>>526への反論になってないっていうか、>>526が言ってることそのままだな 553 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 17:27:09.33 ID:sKFLbSMM.net] >>545 そうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。 554 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 17:39:03.82 ID:sKFLbSMM.net] >>548 個人用ブランチは作成者だけが見るわけじゃないから>>526とは違うな。 >>526は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？ 単に極論言って煽ってるだけかもしれないけどね。 555 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 18:06:24.50 ID:2IsijlAj.net] ところでそれだけ熱心なブランチ管理のpush,rebase制限はどうやってる？ 規約任せかツールかスクリプトか 556 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 18:23:29.30 ID:O0gIeBts.net] うちは原則push -f禁止でやってるんで、みんながpushするサーバーにはreceive.denyNonFastforwardsとreceive.denyDeletesを設定してる 557 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 20:10:30.68 ID:qT5tL8rR.net] 横だがどうやって禁止するのかと思ったらちゃんとそういうコンフィグが用意されてるのか 一回オプション総ざらいしてみよう 558 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 22:07:42.46 ID:1ouiCH4F.net] >>549 で、>>523が言ってる「プロジェクトの規模が小さい場合には それができる」って話につながってくるのか…。 559 名前：デフォルトの名無しさん mailto:sage [2015/05/26(火) 23:55:53.54 ID:2IsijlAj.net] >>553 それブランチごとじゃなくて一律だからアクセス制限にはならないぞ 560 名前：デフォルトの名無しさん mailto:sage [2015/05/27(水) 12:17:18.05 ID:98FdFg1V.net] Git 2.4.2 https://github.com/git/git/releases/tag/v2.4.2 561 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 20:55:03.14 ID:2hiQrePQ.net] 特定のファイルを特定の履歴に戻すのはどうやるんでしょうか？ a.txtをHEAD@{12}のa.txtの内容にしたいんです git reset HEAD@{12} a.txtじゃ戻りませんでした 562 名前：デフォルトの名無しさん mailto:sage [2015/05/31(日) 21:23:55.63 ID:q0XD6tk+.net] checkoutせよ 563 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:34:02.79 ID:6w2KJtLO.net] git init git add -A このaddを取り消したいんですがgit reset HEADをやると fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. ってでます git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？ 564 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:39.31 ID:wXX1PCBE.net] まだHEADに相当するコミットが存在しないから 565 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:41.39 ID:60FC1uF1.net] 1回もコミットしてないとか？ 566 名前：デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:43:38.24 ID:wXX1PCBE.net] おれはそんなとき.gitをざっくり消したりしてたが、 ぐぐると git rm --cached が使えるみたいだな 567 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 10:41:16.23 ID:2Bq+WaXR.net] git rebaseでどこまでまとめるべきなのかわかりません 例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合 一緒にまとめたほうがいいんでしょうか？ 568 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:36:32.71 ID:ENh0ws/u.net] Windows版のバージョンは上がらんのかえ 569 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:29.49 ID:dwjHRJAm.net] 自分でコンパイルしろよ 570 名前：デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:35.29 ID:H1H2VilB.net] >>563 その二つならまとめない。 もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。 571 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:22:55.03 ID:knJmPdD6.net] >>563 そういうgit運用の話は、「管理者の意見に従うべき」 個人用or自分が管理者なら、好きなようにやっていい。 572 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:42:10.75 ID:3kJPkUc2.net] >>567 少しは助言してやれよ 573 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 03:55:40.59 ID:cOL0IOxC.net] どのやり方が良いかなんて決まっているわけじゃない 色々試して自分が一番しっくりする形を探すか 最も採用されていると思えるやり方というのを見出してそれを選択するか 有名どころのオープンソースプロジェクトの方針を色々と見てくるといい 574 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 05:32:16.44 ID:5OGKD7dq.net] 俺がまとめる基準はそのまとめたコミットに判り易いひとつのタイトルをつけられるかどうかあたり でも優先されるべきはそのリポジトリの管理方針なのは間違いない 575 名前：デフォルトの名無しさん mailto:sage [2015/06/03(水) 10:17:17.28 ID:qaWpPbOF.net] ところでpost commit mail送るのに何使ってる？ うちはmultimail使ってるがなんかしっくり来ない 576 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 01:27:40.14 ID:FZpfA7xp.net] >>569 お前はどうやってるんだよ 577 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:38:54.51 ID:ixdJmRIH.net] 俺は初心者の頃にここでコミットをまとめるなって言ってこのスレを炎上させた初心者＋だけどさ その時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ 一体まとめろ！まとめるな！のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる 1. initial commit ---- ここから ----- 2. save 3. type 4.　○○実装 5.save 6.○○実装 7.typo 8.ファイル追加 ----- ここまでまとめる ------- tagで1.0って付ける 578 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:43:29.77 ID:lUVfOohh.net] バージョン毎にまとめろとか誰も言ってないだろ 具体的にそのやりとは何スレ目だよ 579 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:47:48.34 ID:w41Ky1ux.net] >>573 「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、 どういうときはまとめたほうがよい どういうときはまとめないほうがよい というガイドラインのようなものならある程度意見はまとまってきそうだね 580 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:46:30.21 ID:7Y8AXPNC.net] 後から分離したくならないものはまとめる 要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか？と考えればいい 581 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:49:14.71 ID:5FZxl5co.net] そうして全てのコミットはひとつになった 582 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 16:11:36.89 ID:a/IZmogk.net] コミットを入れ替えるときにコンフリクトって起きないんですか？ git init touch README.md git add README.md git commit -m "Initial commit" echo 1 > a.txt git add a.txt git commit -m "add a.txt" echo b1 > b.txt git add b.txt git commit -m "add b.txt" echo a1 > a.txt git add a.txt git commit -m "modified a.txt" git rebase -i HEAD^^^ 以下のように並べ替え pick 06da9a6 add a pick 2c80b8f modified a pick 7a6a277 add b git checkout HEAD^ lsするとbファイルがありません "modified a"のコミットにはbはないことになるんですか？gitが自動的に面倒見てくれてるんですか？ 583 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:10:10.65 ID:lUVfOohh.net] Gitでは各コミットがその時点での全ファイルの状態を持ってるけど、 rebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな >>578のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、 "modified a"コミットにbは存在しなくなる rebase -iでコンフリクトは起こる 例えば>>578の"add a"と"modified a"コミットの順番を逆にしたりすれば 584 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:23:21.52 ID:69dFu2L0.net] >>573 正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな 585 名前：デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:46:29.00 ID:b+4KVUcq.net] 少なくともどの時点でもコンパイル通るようにコミットまとめる 大きくても機能ごとにはコミット分ける でその間はプロジェクトごとに方針あれば何でも 586 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:34:59.14 ID:4eOWDqlW.net] 問題は俺自身に経験がないのに 俺がルールを決めなきゃいけない時だな 587 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:35:56.50 ID:yk/a ] [ここ壊れてます] 588 名前：5xMg.net mailto: >>573 お前、マージ使ってないだろ？ まず前提として「一つのプロジェクトを複数の人が平行で開発している」という 個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。 よくある間違いが、小さい規模の例だけで考えて、 それがそのまま大きな開発にも適用できちゃうって考えること。 君はその間違いはまってる。 （俺が知ってる）小さい規模ではこれでうまくいくんだ。ではなくて 大きな規模になった時それでうまくいくのか？を考えた方がいい。 適切なやり方というのは、規模によって変わるんだから。 [] [ここ壊れてます] 589 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:41:32.51 ID:yk/a5xMg.net] >>581 問題は1コミットを後から見直すかどうかだよな。 後から見なおさないのであれば、どんなに意味不明な修正でも 同じ所を試行錯誤したコミットでも、何百行あるコミットでも 何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい でもあとからそのコミットを見るのであれば 修正内容が明確にわかるコミットが必要最低限あった方がいい。 あとからそのコミットを見るかどうかだよ。 もちろん俺はよく見る。 仕事でもその修正が適切であるかを見たり、 オープンソースとかでもある修正内容を見たり だからコミットは分かりやすくなっていたほうがいいと考える。 590 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:46:03.75 ID:yk/a5xMg.net] >>575 > というガイドラインのようなものならある程度意見はまとまってきそうだね コミットをまとめる or まとめないのが目的じゃないからね。 コミットを綺麗にするのが目的。 当然の話だけどガイドラインには理由が必要だろうね。 まとめる理由が。（もしまとめないのであれば、まとめない理由も） コミットをまとめたりまとめなかったりして、綺麗にする理由は 簡単にいえば、後からコミットを見た時にわかりやすいように するためなんだが、もっと細かい理由って必要だろうか？ 591 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:54:18.21 ID:yk/a5xMg.net] 少しだけガイドライン考えてみた ・一つのコミットで複数の修正を行わない 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから ・一つの修正を複数のコミットにわけない（分かれていればまとめる） 理由 後からそのコミットを見た時何を修正したのかがわからなくなるから 例外 リリースしてしまったコミットはまとめることは出来ない。 いま気づいたが、この「リリース」っていう概念が重要だな。 どの時点でリリースになるのかはそれぞれだろうが master、もしくは共有ブランチににマージされた時点がリリースだと考える。 と考えると、やはり>>573の例ははマージ機能を使ってない時点で 一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。 592 名前：デフォルトの名無しさん mailto:sage [2015/06/06(土) 23:00:59.08 ID:OBriYrAJ.net] 3行で 593 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 00:12:36.70 ID:5CuOmznL.net] あとから見てわかるようにコミットを綺麗にしておけ まとめる とか まとめない とかどちらか一方じゃない どちらもやって、綺麗にしておけ。 594 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:04:34.40 ID:VSY66R2E.net] 一つのコミットに入れる一つor複数の修正って、何単位で一つと呼ぶのかって話もあるし、 >>545と>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」 って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ 無駄ではないか それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう 595 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:08:39.07 ID:VSY66R2E.net] >>582 そういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う 596 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:48:23.33 ID:5CuOmznL.net] >>589 > >>545と>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」 いないだろｗ あぁ、なんで共有ブランチにpushしたコミットは 編集したらだめなのかを書いていなかったね。 物事は単純で、他人の役に立つことをしましょう、 他人の迷惑になることはうやめましょう。これだけだよ。 コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。 これは他人の役に立つこと。 そして共有ブランチを修正したらだめというのは、他の人も その共有ブランチから派生して修正しているので、その派生元が変わると 今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。 これは他人の迷惑になること。 このように俺のガイドラインにはちゃんと理由がある。 反対のガイドラインを作りたいなら、その理由をいうことだけ。 でないと俺の意見に対抗できない 597 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:52:10.94 ID:5CuOmznL.net] 念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。 俺が言ってる共有ブランチっていうのは、 他の人がそのブランチから作業をする、 または他の人がそのブランチにマージすると という目的で作られたブランチのこと。 つまり他の人が参照しているだけならば 共有ブランチとは言わない。 参照しているだけならば、そのブランチが変わっても 他の人の作業のじゃまにはならないからね 598 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:54:19.37 ID:5CuOmznL.net] ということで、何故そうするのか、どんなメリットがあるのかを しっかりと書いたガイドラインを、俺以外に出すのまってま〜すｗ 599 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:11:47.35 ID:V49LqTdE.net] >>591 ＞いないだろｗ いや、>>545が「共有ブランチ上のコミットを書き換えるんだとしたら」と言ったのに対して >>549が「そうだよ」と返しているので、いること自体は確かなようだ 545に対して、あなたがどうロンパするかは別に知らないが 600 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:31:51.05 ID:V49LqTdE.net] >>583-584 全部のコミットをひとつにまとめて周りから怒られなかったなら、 それは正しいまとめ方だったと思うんだけどね 601 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:19:13.74 ID:5CuOmznL.net] >>594 > 545に対して、あなたがどうロンパするかは別に知らないが 論破？ 何故そうするかの理由がないのだから、 まずその理由を言うのが先だろうｗ 602 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:20:45.23 ID:5CuOmznL.net] >>595 > 全部のコミットをひとつにまとめて周りから怒られなかったなら、 周りの人間がコードを見るということを知らないだけかもしれない。 スキルが低くてソースコード管理ツールすら知らない人もいるのだから。 だからそれは全く参考にならないな。 理由だよ理由。 俺は何故そうするかの理由を書いた。 この俺を論破する理由をかける奴はいないのか？ｗ 603 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:21:31.63 ID:yxti539q.net] 誰か運用スレ立ててくれない 604 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:52:14.95 ID:V49LqTdE.net] 結局は>>589の言ったとおりになるという、悲しい現実 >>598 運用スレを建てても、荒らしがそこに移動するかどうかは別問題だと思う 605 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:04:07.08 ID:yxti539q.net] 運用スレ行けと言えるようになるだけ幾分マシかと 606 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:08:53.36 ID:V49LqTdE.net] >>600 なるほどそうかもしれないね そういう意味だと、既存だとここあたりが適切なのかな バージョン管理システムについて語るスレ10 peace.2ch.net/test/read.cgi/tech/1393147031/ 607 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:12:32.75 ID:5CuOmznL.net] >>599 > 結局は>>589の言ったとおりになるという、悲しい現実 大丈夫。 俺が言った「ガイドラインを言う時は理由も明確書くこと」 のおかげで、今のところガイドラインは俺が言った一つしかでてない。 608 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:17:04.64 ID:yxti539q.net] >>601 ここでされてるの横断的でない個別的な内容だからスレチ 609 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:18:47.22 ID:V49LqTdE.net] >>603 そっか、じゃあ新スレがいるか・・・ 610 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:17.32 ID:V49LqTdE.net] >>602 ＞今のところガイドラインは俺が言った一つしかでてない。 そりゃ出ないでしょ 誰も関わりたくないんだから 611 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:26:15.60 ID:5CuOmznL.net] >>604 スレ立てておいたよ。 Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ >>605 > 誰も関わりたくないんだから 関わりたくないのが理由っていうのはおかしな話だな（笑） 言い返せない時に汎用的に使えそうな言い訳だ。 612 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:31:19.54 ID:V49LqTdE.net] >>606 ありがとう じゃあここから先は、ここで運用系の話をするのはスレ違いってことで、 あとはそっちでやってもらおう 613 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:42:31.68 ID:yxti539q.net] >>606 タイトルを単にGit運用スレにできないあたり自己顕示欲あふれるスレタイですね 614 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 15:41:57.12 ID:D5MO+jlJ.net] 立てたら立てたで文句言う奴 w 615 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:06:00.04 ID:D+Qsqenv6] はじめまして。　質問させてください。 とあるリポジトリに以下のようなブランチがあります。 ・master　特に進んでない ・masterから作成したブランチA　最初のほうだけ開発 ・ブランチAから作成したブランチB　あらかた開発 ・ブランチBから作成したブランチC　テストコード開発 masterとAは他人が作ったもので、 私はそれを引き継ぐ形でBで開発していました。 そこからCでテストコードを作ることになり、 一応終わったのでBにプルリクを出したところ少しのやり取りののちマージされました。 そのあとで不具合に気がついたのでまたコミットをしたいのですが、 この時`git checkout`でBに移動してから行うべきでしょうか？ それともそのまま行ってもよいのでしょうか？ CがマージされたBに続く形にしたいのですが、 Bで`git status`すると"Aより104コミット進んでいるから`git push`使って公開して"というような英文があり、 同様にCで行うと"Bより16コミット進んでいるから`git push`使って公開して"というような英文があるので、 言われたとおりにpushしたらコミットはどうなるのでしょう？ Cを作るときにpush漏れはないですし、Cがマージされた時も同様にないのですが。 616 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:26:22.23 ID:5CuOmznL.net] いるいるw 617 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:53:47.38 ID:V49LqTdE.net] >>608 荒らしが自分で建てたスレなんだから、そうなるのはしょうがない 運用の話はそっちでやってもらいましょう 618 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:53:48.87 ID:yxti539q.net] 自分で立てたスレなんだからもちろん自分は引っ越して誘導もするんですよね 期待してますよ 619 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 20:06:44.60 ID:5CuOmznL.net] >>613 はい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。 みなさんも協力してくださいね。 逆に運用以外の雑多な内容はこっちに移動しますよ。 620 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:10:56.78 ID:V49LqTdE.net] >>613 おみごと 621 名前：連続書込しすぎなのでID変えます mailto:sage [2015/06/07(日) 21:22:11.43 ID:rs3gN1uE.net] このスレから運用に関することをなくしたら どれだけのレスが残るか期待ですｗ ぜーんぶかっさらっていきますよーｗ 622 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:49:02.86 ID:HSoSL4U1.net] git とうまく組み合わせられるような バグトラッキングツールでおすすめのはある？ mantisってもう人気無い？ 623 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:52:12.28 ID:V49LqTdE.net] これでツールの質問ができるようになるのか、 または、ツールの質問に答えられる人なんて初めからいなかったのかがハッキリするな どっちにしても平和になってよかった 624 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:57:36.23 ID:/P0faz6I.net] Egitで、amendじゃなくてもっと過去のコミットを編集するには 画面上でどういう操作をすればいいんでしょうか？ 625 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:03:03.72 ID:rs3gN1uE.net] githubの使い方を教えて下さい。 626 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:13:31.59 ID:rs3gN1uE.net] >>619 よめ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja 627 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:14:24.04 ID:rs3gN1uE.net] WindowsでGUIでgitを使いたいです。 なんか良いツール無いですか？ 628 名前：616 mailto:sage [2015/06/07(日) 22:16:23.46 ID:rs3gN1uE.net] >>619 すまんすまん。EGitっていう名前のツールがあるのか。 ならこのスレだ。 629 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:16:39.42 ID:UKZkpptu.net] >>619 そんなのIDEの機能に頼るより、そのコミットを修正するコミットを作った後に コマンドラインからrebase -iで順番入れ替えてsquashしたほうが簡単じゃないか？ 630 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:17:04.27 ID:/P0faz6I.net] >>621 目次にどこにもEgitの話が出てないんですけど、どこに載ってるんですか？ 631 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:18:17.74 ID:/P0faz6I.net] >>624 Eclipse上で開発してるので、自分はEgitの方が楽です 632 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:41:10.16 ID:UKZkpptu.net] >>626 おれが使ってるのはIntelliJ IDEAだけど、Git関連は全部GUIでやるよりコマンドラインも併用したほうがいろいろ楽 ちなみにIntelliJ IDEAではrebase -iもGUIで出来るんで試しにやってみたけど、 思ったほどじゃないけどちょっと面倒 EGitもEGit rebaseでぐぐれば手順説明がいろいろ見つかるな 一応できるみたいだよ Rebase Interactiveとかあるらしい 633 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:44:07.71 ID:/P0faz6I.net] >>627 で、そのやり方を知りたいわけです 634 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:44:51.36 ID:rs3gN1uE.net] >>626 いやいや違う。Egitの方が楽というのは言い訳だ。 楽というのは事実だろう。だがそれはCLIで gitを使えないことの理由にはなっていない。 はっきり言おう。君はCLIでgitを使えないだけだ。 それはEgitが楽という事実とは無関係だ。 CLIでgitを使えるようになったほうがいいよ。 そうすればEgit＋CLIのコマンドで検索すれば簡単に見つかる。 >>623で訂正したが、やっぱり君が読むべきものはPro Gitだ。 GUIツールの機能はCLIを使える知識がなければ理解できないだろう。 いくつか使ってみたが、どれもいきなりCLIのコマンド相当のものがメニューにあるから 初めて使う人は「この機能なにをするものなんだ？」ってなるだろう。 で、CLIのコマンドを知らない人でも簡単に理解できるGUIツール無い？ プログラマーではないウェブデザイナー（HTMLとかCSSを書く人）にも 使ってほしいと考えてるんだけど。 635 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:46:34.98 ID:UKZkpptu.net] >>628 だからEclipseで普通にコミットを作ってRebase Interactiveしろよ amendは知ってるんだから普通にコミットを作るのはできるんだろ？ 636 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:49:18.28 ID:/P0faz6I.net] >>630 コミットは作れるんですが、Egit上での対話的リベースの使い方が分からないんですよね・・・ 637 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:51:21.60 ID:UKZkpptu.net] >>631 ヒストリーのコミットで右クリックすりゃRebase interactiveがあるらしいぞ 638 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:52:20.19 ID:/P0faz6I.net] >>632 そこまでは分かるんですが、そのあとの操作の仕方が・・・ 639 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:03:17.96 ID:rs3gN1uE.net] たいていのツールはGUIはCLIの使い方を知らなくても使えるものなんだが、 バージョン管理ツールをGUIにしても使いにくいのは ソースコードを管理するということの意味がわからないからだろうな。 例えばペイントソフトは、そのツールを使う前から 絵を書いたことがある。それと同じことをツールを使ってやるだけ でもソースコードを管理ツールは、そのツールを使う前にそのツールと同じことをやっていない。 ソースコードを修正している人であっても、ソースコードを管理していない。 （※バックアップはソースコードの管理じゃない） だからそれをGUIにしたところで、何をするのかわけがわからない機能ばかりで 使い方がわからない。（もしくはバックアップという間違った用途に使うだけ） ふぅ。そういうことを知らないし、知る必要が少ないウェブデザイナーに どうやって使いやすい環境を提示できるだろうか。 640 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:03:38.86 ID:UKZkpptu.net] >>633 その様子だと直前じゃないコミットを修正するって行為がどういう意味を持つか理解できてないだろ？ Gitに慣れるまではおとなしく新しいコミットで修正しとけ 641 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:07:11.82 ID:/P0faz6I.net] >>635 そうじゃなくて、それをしたくないから、Egitでのやり方を知りたいわけです 642 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:10:20.71 ID:UKZkpptu.net] >>636 EGit使おうがコマンドラインでやろうが、途中のコミットを修正するってことは単純な行為じゃないんだよ コンフリクトが発生する可能性があるの理解してる？ 643 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:15:59.04 ID:rs3gN1uE.net] >>636 当たり前のことを言うけどさ、プログラマっていうのは技術者だよ？ 技術者と何故呼ばれるかというと、それは技術がなければできないことが できるから技術者なんだよ。 今君が言っていることは「技術者になりたくない」って言っているのと 同じことだってわかってる？ 楽とか大変とかじゃない。 技術をつけること事拒否することは、技術者になりたくないと言ってるのと同じ。 CLIでgitの使い方を学ぶのが技術をつけるのに一番の近道なんだよ。 別にGUIが楽なら普段はGUIを使っていい。でも技術自体はちゃんとつけておけ。 644 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:16:28.99 ID:/P0faz6I.net] 個人的には、分からないなら「分からない」で全然かまいません できるなら、ここ以外でツールの話を分かりそうな人がいる場所を教えてくれるとうれしいですが 645 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:17:36.07 ID:rs3gN1uE.net] >>639 なんならまたスレ立てようか？ 「git関連のGUIツールの使い方を教えて下さい」っていうスレ 646 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:18:36.91 ID:/P0faz6I.net] もちろん、2chである必要は全然ないです （・・・っていうか、むしろこの状況ならそっちの方が知りたいです） 647 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:21:41.41 ID:rs3gN1uE.net] あ、もう一つgitのGUIツールがなぜCLI使えない人にとって 難しいのかがわかった。 普通CLIが難しい理由は「コマンドを覚えないといけないから」で その「コマンドを覚える必要がないから」GUIは簡単なんだ。 でもソースコードの管理ツールの場合、コマンドを覚えることよりも そのコマンドで何が出来るか、何をするかがわからないから難しい。 ボタンひとつでコマンドを呼び出せても、そこから何をすればいいか わからないんだよね。この人のように。 648 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:23:55.02 ID:/P0faz6I.net] >>640 っていうか、ここがgit関連のツールの使い方を聞ける場所になったんじゃないんですか？ >>617さんのように、CUIじゃない質問をしてる人もいますし、ここでGUIだけ絞る必要もない気がしますが・・・ 649 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:31:22.51 ID:1F5PzSNl.net] >>641 最低限英語できるならstackoverflow.com、機械翻訳でも多分他の人が適当に質問自体修正してくれる ja.stackoverflowでもいいけど回答くる確率は落ちる 650 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:34:31.78 ID:rs3gN1uE.net] >>643 聞くのは構わないが答えるとは限らないｗ 質問したところで>>617さんのように放置される。 このスレからgitフローのような運用に関する話が 分離しただけで、ここがなにかに変わったわけじゃない。 651 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:37:00.95 ID:/P0faz6I.net] >>642 自分の場合は、GUIが簡単でCLIが難しいからじゃなくて、 Eclipse上でそのまま操作できるのが楽だから、なんですよね あなたがEgitを知らなくて、自分はEgitのことを知りたいので、 分からないなら「分からない」って言ってくれて全然かまいません >>644 なるほど、そっちの方が良い人がそろってそうですね 英語にはさほど抵抗ないですし、そっちで質問してみます ありがとうございました 652 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:39:46.62 ID:rs3gN1uE.net] よし、これでこのスレでツールの話をする奴が消えたｗ こんな感じでどんどん減らしていくので、4649！ 653 名前：デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:43:59.53 ID:UKZkpptu.net] >>646 ほらよ another.maple4ever.net/archives/2060/ このブログの後半の「コミットを改変する場合」な 654 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 08:05:44.37 ID:USedaFhj.net] なにこの CLI で git 使える俺スゲー君 w 655 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 08:53:59.64 ID:Q2pvFPhj.net] CLIじゃないと、まともに使えないという方が多いんじゃないか。 656 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 11:32:29.03 ID:AXPER4TO.net] GUIで全部やるのは難し過ぎる 併用が無難だよ 657 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 11:48:08.05 ID:I6Rw7h/u.net] gitと親和性の高いBTSでお勧めを教えて 658 名前：デフォルトの名無しさん [2015/06/08(月) 12:15:16.89 ID:obzwvKms.net] もうgithub for windowsで満足 プルダウンメニューでブランチを替えて、 ファイルを編集したら未コミットのリストがリアルタイムで追随、 マージはブランチのドラッグアンドドロップで一発、 プッシュはsyncボタンで一発。 でもたまによくあるCLIの作業からは逃れられないけど 659 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 13:31:33.83 ID:AXPER4TO.net] ファイル編集、HEADとの差分確認、コミットの流れはIDEやエディタに統合されたのを使う ブランチのブラウズもGUIのを使う ここらへんは非CLIでやることのメリットを感じるね 660 名前：１０人に１人はカルトか外国人 [2015/06/08(月) 14:46:48.11 ID:KHrLNVN4.net] ●マインドコントロールの手法● ・沢山の人が偏った意見を一貫して支持する 　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法 ・不利な質問をさせなくしたり、不利な質問には答えない、スルーする 　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法 偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い 靖国参拝、皇族、国旗国歌、神社神道を嫌うカルト 10人に一人はカルトか外国人 「ガスライティング」で検索を！ 661 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 20:44:04.47 ID:BwIK9Ub/.net] >>652 自分でサーバー立てるか、どっかのサービス利用するかで回答が変わってくるな 662 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 20:51:15.26 ID:xf2QCU7p.net] >>652 ここはgitのスレです。 gitではない話はスレ違いです。 663 名前：デフォルトの名無しさん mailto:sage [2015/06/08(月) 21:50:53.55 ID:I6Rw7h/u.net] >>656 親玉のサーバをLinuxで自前で立ててあります 今は3人くらいでpushしてる 664 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 00:40:12.96 ID:LoeafuSM.net] >>658 既にホスティング環境があって、同じサーバーにbts立てられるっていうことならredmineかな。 ただ、redmineは設定に躓くとちょっとめんどい。うまくいけばbts部分はかなり高機能だし、プラグインで色々拡張もできる。 ホスティング環境も移れるなら、gitbucket (https://github.com/takezoe/gitbucket )とか手軽でいいかもしれない。 javaとtomcatが用意できれば始められるし、それでいてgitホスティングとかpullrequest、issue連携とかの機能は揃ってる。 ただ、gitbucketはbtsとしては高機能とは言えないので、凝ったことしようとすると不満が出るかもしれない。 665 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 09:04:20.23 ID:QNGnbMWJ.net] gitlabの方がいいよ。git連携というかgit統合みたいなものだから ものすごく使いやすい。設定はほぼ不要。 redmineはBTSとしてはいいが、ソースコードを 快適に修正するための機能がない。 具体的に言えば「プロジェクトをフォークして、個人用の フォークプロジェクトで行った修正をマージする」といった 極めて重要な機能がない。 あとBTSはもう古いね。今はITS。 BTSだとITSとして使えるようにカスタマイズしないといけないから 初期状態で使いにくい（そして初心者は使いにくいことに気づかないまま 使いにくいものを使い続けてしまうよ） 666 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 21:00:02.32 ID:mCgHqgj4.net] gitlabは昔に触ったときは導入が色々大変だったから勧めなかったけど、今は結構楽みたいだね。dockerにも対応してるみたいだし。 確かに高機能だし、本格的に始めたいならいいよね、gitlab。 667 名前：デフォルトの名無しさん mailto:sage [2015/06/09(火) 21:14:19.30 ID:gDccibNx.net] gitlabか。 いっかいインストールしたけど 使い方がわからなくてあきらめたんだよな もう一度頑張るか 668 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 01:07:42.05 ID:7XQM9Exq.net] >>661 今は公式リポジトリが出来たよ。 普通にapt-get, yumでインストールも アップデートもできるようになった。 >>662 BTSはMantisをちょっと触っただけだけど考え方が違う。 BTSだともぐらたたきゲームのようにバグが湧いてきて それを「通報がありました」「バグを確認しました」 「誰かにアサインしました」「修正しました」「リリースしました」 のように随時状況を報告しながらバグを退治。 他の人がそのステータスを確認するっていうフローが想定されている。 そのフローが準備されているからバグ退治の流れはそれに乗っかればいいが アプリ開発（新機能追加など）はやりにくい。 gitlabだと（githubもそうだが）逐一状況を伝える事はしない。 ラベル機能とかで出来なくはないが、BTSではないのでバグ退治のフローはない。 代わりにあるのがアプリ開発のためのIssueでバグを含めた課題全般を取り扱う リリース済みでバグが次から次へと発覚して、それを急いで直さなきゃ。みたいな状況ならBTSの方がいいかもしれないね。 ITSはもう少し安定していて、マイルストーンを決めてそこまでに対応するという感じ。 もちろん急ぐ奴はすぐリリースしても良いけどね。 フローの話になったから、こっちのほうが良かったかｗ Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ 669 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 22:15:34.72 ID:rQ07tGpq.net] gitBREAK使ってる人、感想聞かせてください！ codebreak.com/ja/ 670 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 23:21:39.44 ID:19Nfo0Ba.net] どうやって利益あげてんのか気にはなるな 671 名前：デフォルトの名無しさん mailto:sage [2015/06/10(水) 23:38:29.29 ID:EBTmmvru.net] codebreakか 日本の法律下にある他人の鯖にソースコードを預けたくないな 672 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 05:00:08.95 ID:QpuB/nCQ.net] わざわざ劣化コピー使う意味がわからない 673 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 06:29:11.47 ID:6Kqx+wy+.net] github日本版がツイキャスみたいな出会い系サイトになったら移っても良い 674 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 06:32:27.10 ID:6Kqx+wy+.net] >>663 >>573 ってだれかとおもった 675 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 06:40:44.25 ID:6Kqx+wy+.net] >>634 最後の２行について言うと それはGUIとしての完成度が低いと言う見方もあるな 馬鹿なデザイナーでも使えるようにする必要があるかどうかは知らん >>638 その通り 676 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 08:05:33.95 ID:bgrkp9n0.net] >>638 難しい手順を覚えるのは技術のうちに入らない。 それは単にプロトコルに習熟しただけ。 例えばENIACプログラミングを今更やる奴は殆ど居ない。 本質的な結果を出す為の過程を単純化した方法を作り出すのが技術。 テクノロジーの語源からも明らか。 677 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 08:12:02.69 ID:IhjRP6Ev.net] guiは履歴を俯瞰してみたり、チェリーピックしたいときに便利だと思う。 cliはシェルと組み合わせれば半自動で色々できるから好き。 678 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 19:58:54.95 ID:pGn6KOhY.net] >>664 > ソースコードや個人情報等の情報およびその投稿に関する禁止事項 > 3.ソースコードに、自己または第三者の連絡先を記載または暗示すること > その他一般的な禁止事項 > 4.本システムを通じて入手した情報を、複製、販売、出版、その他私的利用の範囲を超えて使用する行為 ライセンス文もまともに書けず仮に公開したとしても使用には強い制限がかかる 誰がこんなバカな規約書いたんだよ 679 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 20:52:13.58 ID:0L5sgKmI.net] 無料で、数人で、非公開のプライベートリポジトリを使う手段は、現時点では存在しませんか？ 680 名前：デフォルトの名無しさん [2015/06/11(木) 21:10:32.77 ID:d4+JHvzb.net] Dropbox 681 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 21:49:51.01 ID:QpuB/nCQ.net] >>673 島国根性丸出しのジャップ猿が退化させてやんの 死ねよもう 682 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 21:56:58.54 ID:jxx/4OCH.net] >無料で、数人で、非公開のプライベートリポジトリを使う手段は、現時点では存在しませんか？ gitlabがある https://about.gitlab.com/gitlab-com/ Unlimited repositories Unlimited private collaborators Unlimited disk space* Completely free, no credit card required 683 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 22:05:30.61 ID:0L5sgKmI.net] >>677 ありがとうございます！見てみます！ 684 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:21:46.83 ID:lwbpITef.net] >>671 > 難しい手順を覚えるのは技術のうちに入らない。 なにドヤ顔で嘘ついてるのさｗ 手順覚えるだけでも運転技術だし 飛行機の操縦も船の操縦も手術も手順覚えるだけだから 技術じゃねーってことになるな 685 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:34:12.67 ID:YENRiAY6.net] 技術じゃないとまでは言わなくても誰がやっても同じ動きになるなら大した話じゃない 飛行機も船も手術も知識があるうえで感覚も必要なもんだから誰でも同じにはならんわな 686 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:36:23.68 ID:lwbpITef.net] > 技術じゃないとまでは言わなくても誰がやっても同じ動きになるなら大した話じゃない は？ ハンドルを右に切れば 右に曲がりますが？ 687 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:37:09.16 ID:MEVqNqhj.net] あいつには運転技術があるって聞いて運転の手順覚えてるだけかよって思う奴は少ないわな 688 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:37:32.79 ID:lwbpITef.net] >>680 gitも知識があるうえで感覚も必要なもんだから誰でも同じにはならんわなｗ コミットの内容も、コミットの順番も人それぞれ違ったものになる。 689 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:38:20.68 ID:lwbpITef.net] >>682 ワロタｗ うまいね あいつにはgit技術があるって聞いてgitの手順覚えてるだけかよって思う奴は少ないわな なるほど、gitの手順だけ知っていて それを技術があるって思い込んでる奴だったのか！ 690 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:40:40.14 ID:VCTHLF0P.net] gitを使うっていうのは、gitのコマンドを覚えるだけじゃないからね。 どいういう風にブランチとコミットを 組み立てていくか、それがgitを使うということ。 その技術次第で、過去の修正の内容が分かりやすくなったり ごちゃごちゃで意味不明になったりする。 きれいなコミットだとrevertしたり、cherry-pickも簡単なんだが、 だめなやつがやると使えないコミットだらけになるもんな。 691 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:41:01.81 ID:OzhCdhwc.net] GitHubで公開されているものを利用してシステムを作ろうとしています。 ですが社内のプログラマが同じバージョンのものを使うようにしたいため Gitのサーバを構築して、GitHubのを社内にコピーしてプログラマは 社内のGitサーバから落してもらうようにしたいのですが、このような 使い方はできるのでしょうか？ 用語が分からないので上手く説明できませんが、もしできる場合は具体的に どのようにすればばよいのでしょうか。 692 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:42:44.09 ID:VCTHLF0P.net] >>686 githubで公開されているものを使うってだけなら、 submoduleを使えばいいだけ。 特定のバージョン（コミット）を指定して参照することができる 693 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:42:53.47 ID:bgrkp9n0.net] >>679 先人が作り上げた技術に「習熟」する事と、改善等を加える事との区別ぐらい付けよう。 694 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:45:06.84 ID:VCTHLF0P.net] >>688 飛行機だってマニュアルがあって 先人が作り上げた技術を 「習熟」するだけですが？ なにか言う前に矛盾しないか 少し考えてから発言しようよｗ 695 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:51:54.22 ID:bgrkp9n0.net] >>689 「習熟しただけ」のパイロットもどきが事故起こすんだよなあ。 まあ、プログラム言語の文法覚えた「だけ」の奴には難しかったか。 696 名前：デフォルトの名無しさん mailto:sage [2015/06/11(木) 23:54:53.44 ID:VCTHLF0P.net] >>690 > 「習熟しただけ」のパイロットもどきが事故起こすんだよなあ。 だからなんなんでしょうか？ｗ 「習熟しただけ」のパイロットもどきが事故起こすが 「習熟した」以上の技術をつけたのパイロットは事故を起こさない 「習熟しただけ」のgitつかいもどきが、くそきたないコミットを作るが 「習熟した」以上の技術をつけたのgitつかいはきれいなコミットを作る。 あれあれ？ 同じことですねｗ 697 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 04:30:47.16 ID:XoMzVDAf.net] 定石をおぼえる時は 定石から外れたことをするとどうなるかまで知ってる人と 定石通りのことしか出来なくて定石から外されると負ける（前者なら普通勝てる）タイプの人が居るね 698 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 05:33:48.07 ID:KE10iP2h.net] 汚いか綺麗かを決めるのは自分だ。 699 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 07:55:39.88 ID:DpgRw3ep.net] >>691 見苦しいから、その辺にしとけ。 >飛行機だってマニュアルがあって >先人が作り上げた技術を >「習熟」するだけですが？ こういう甘い発想の奴は困るんだよなあ・・・ 700 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 08:28:50.68 ID:K1SJqQ2p.net] >>689 git 使うような人はそのマニュアルを作るような立場の人が多いんだが 701 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 08:41:22.54 ID:UHhWvxxE.net] >>695 わかる このスレ「管理者の方針に従えばいい」 俺「俺がその管理者なんだよ〜。どうやってルール決めればいいかわかんねーよ」 702 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 09:11:20.96 ID:uZJNyCxR.net] やはりそうか hissi.org/read.php/tech/20150611/VkNUSExGMFA.html hissi.org/read.php/tech/20150611/SUdTbEt3Wnk.html hissi.org/read.php/tech/20150612/MGtLbjJuSjU.html hissi.org/read.php/tech/20150612/dzVHdW5NWTY.html 703 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 19:21:58.70 ID:w9SfTIdr.net] 外部の刻々と変わる環境に対して、 適切な対応を選択し、実行する これは操作方法だけじゃ無理だよ 704 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 19:48:06.43 ID:OQHJwW6B.net] Git初心者で、使い方が分からない部分が多くあります。答えていただけると嬉しいです。 GitにアップロードするためのツールとしてTortoiseGitを使っているのですが、 最初にアップロードする(プッシュする)のはいいとして、 ローカルの中身を更新した際、プッシュしてもオンライン上で全く同じ状態にはならず困っています。 具体的には、オンライン上で「ファイルA・ファイルB」、ローカル上で「ファイルA・ファイルC」とあった場合、 プッシュするとオンライン上で「ファイルA・ファイルB・ファイルC」となって、ファイルBが削除されないのです。 いちいちブラウザ上で手動で削除するのが面倒なのですが、何か上手い方法はあるのでしょうか。 また、各種Gitツールを使わず、ブラウザからレポジトリに直接ファイルをアップロードすることはできるのでしょうか？ 705 名前：デフォルトの名無しさん mailto:sage [2015/06/12(金) 20:10:35.67 ID:AMVc4lNO.net] >>699 > ファイルBが削除されないのです TortoiseGit のメニューから削除してないんじゃない？ > ブラウザからレポジトリに直接ファイルをアップロード サービスの提供者に聞いてどうぞ 706 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 01:44:19.98 ID:2XvJk2DZ.net] >>694 えとさぁ、見苦しいよ。 人のコメントを引用して、 そのことについて、何が間違ってるかを 何一つ書かないで、言い返した気になるのは。 707 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 01:47:39.52 ID:2XvJk2DZ.net] >>696 > 俺「俺がその管理者なんだよ〜。どうやってルール決めればいいかわかんねーよ」 社内に詳しい人がいないなら、社外の知識を利用すればいいのでは？ 最近はオープンソースでgitでどういうコミットをしているのか 見ればすぐにわかるし、資料も多いし、２ちゃんねるでもこっちのスレで詳しくやってるよ。 Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ 708 名前：デフォルトの名無しさん mailto:sage [2015/06/13(土) 01:50:44.54 ID:2XvJk2DZ.net] >>698 > 外部の刻々と変わる環境に対して、 それはわかる。単にコマンドを覚えるだけじゃなく gitの外部の環境＝ソースコードに応じて 適切な順番と内容で対応を変更して実行する。 これはコマンドを覚えるだけじゃ出来ないからね。 それは他の人のコードのブランチをレビューしていて 痛いほどよくわかってる。コマンドを使うことは出来る だけどあるべき姿のものを作れない。 709 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 00:59:50.94 ID:PH3D3/9J.net] 浜野さんのミドルネームの C って、何の略かな？ 710 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 11:20:49.71 ID:ZM3mWJtN.net] 濱野・チャーリー・純。 それが彼のフルネームよ！ 711 名前：デフォルトの名無しさん mailto:sage [2015/06/15(月) 11:37:12.53 ID:HDA/Cn6G.net] ごめんくさい〜 712 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 00:13:48.85 ID:7C1PfN58.net] >>687 ありがとうございます。 submoduleでいけました。 713 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 01:55:47.83 ID:LRuQsu+J.net] >>705 >>706 懐かしい。 チャーリー浜かよw 714 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 13:15:18.31 ID:AmmNKqz/.net] https://github.com/python/cpython/commit/efe0e11c78f890146375f1d4cbed4b513cdffa3c これどういうことですか？ 同じ文字列が削除されて追加されているコミットってどうやって作るんですか？これ何の意味があるんですか？ 715 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 13:16:28.66 ID:TZUCxsD3.net] foxがFoxになっとるやんけ 716 名前：デフォルトの名無しさん mailto:sage [2015/06/16(火) 13:28:36.36 ID:dzgBqGJj.net] 改行コードが変更されただけとか 行末のスペース無くなってるだけとか TABがスペースに置き換わっただけとか たまによくある 717 名前：デフォルトの名無しさん [2015/06/16(火) 21:45:33.41 ID:gqnH2dL3.net] sourcetreeで、stashをpopする方法はある？ 718 名前：704 mailto:sage [2015/06/17(水) 00:09:44.91 ID:zdNvSItr.net] 言われて気づきました大文字が小文字になってるだけだったのに今気づきました 719 名前：デフォルトの名無しさん mailto:sage [2015/06/17(水) 19:22:19.83 ID:Uu1OTzaj.net] Git 2.4.4 https://github.com/git/git/releases/tag/v2.4.4 720 名前：デフォルトの名無しさん mailto:sage [2015/06/18(木) 00:27:48.54 ID:7B4eGBDb.net] うまく説明できないんですが、GitHubとは別サイトで認証が必要なライブラリで そのサイトでGitHubのアカウントを登録してGitHubから引っ張ってくるんですが、 登録さえしてしまえば普通にcloneで取ってこれます。 それをsubmoduleで使いたいんですがローカルリポジトリに追加してコミット、 自分のサーバのリポジトリにプッシュしても、他の人が使えません。 自分自身も一度ローカルを消して、自分のサーバからクローンしようとしても エラーになってしまいます。 このような場合はどうすればよいでしょうか? 721 名前：デフォルトの名無しさん mailto:sage [2015/06/18(木) 00:33:40.72 ID:vn28fqVf.net] >>715 まずこの意味がわからない ＞GitHubのアカウントを登録してGitHubから引っ張ってくる 具体的に何やってるの？ 722 名前：デフォルトの名無しさん mailto:sage [2015/06/18(木) 01:25:52.57 ID:X9wRJKf5.net] >>715 submoduleのリポジトリも含めて皆がcloneできる場所において、 submoduleの参照先を変えないとだめかもしれない。 723 名前：デフォルトの名無しさん mailto:sage [2015/06/18(木) 19:53:58.42 ID:lbH07egD.net] >>716 .gitmodulesの示す先がローカルのパスか、その別サイトにログインできないとcloneできないとか そんなんじゃね？ 724 名前：デフォルトの名無しさん mailto:sage [2015/06/18(木) 20:20:22.80 ID:lbH07egD.net] ああ、>>716の疑問はそこじゃないな・・ githubを監視するようなサイトが幾つかあるけど、そんな中にミラーを提供する奴もあったかもしれない (うろ覚えでオセロか何かそんな名前のサイトがあった気がするけど今見たら消えてるな・・・) そういうのを使ってるんだろう と、エスパーしてみた 725 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 16:52:03.91 ID:YPeQCGDm.net] pushしたコミットログをタイポしたのでrebaseで直した後に 別の最新の更新内容をpushしようとしたら pullしろっていわれたのでpullしたらコンフリクトしました こういうときってどうやってコンフリクト起こさずにログを修正したらよかったんですか？ 726 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 17:00:11.07 ID:RKAD3ekV.net] >>720 あんたのレベルだとpush済みのタイポをrebaseで直してpushしようとしたらダメだ 多少歴史が汚くなるとしてもタイポも新しいコミットとしてpushすべき 727 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 18:17:52.76 ID:0NmNrFCo.net] >>716 >>717 >>718 >>719 どうもすいません。ちょっとてんぱり気味でした。 >>718のおっしゃる通りです。 ただユーザー名とパスワードを書くのは引けるので調べたところ GitGubでトークンというのを作って.gitmodulesに書き込む事で うまくいきました。 728 名前：デフォルトの名無しさん mailto:sage [2015/06/21(日) 18:55:06.03 ID:/gMpDjZs.net] pushしてからrebaseはコンフリクトする罠 729 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 02:49:01.15 ID:j9mWyPD+.net] >>720 >>721は無視していい（笑） おそらく>>721自体がやり方をわかっていない。 >>721自信がが説明できるレベルにないのを「あんたのレベル」という言葉でごまかしてるｗ おそらく答えとしては「push時に--forceをつけろ。」だろうけど 以下、ちゃんとした解説 ------------------ どれをどこにpullしたのかよくわからんが、まず「みんなで共有しているブランチ」と 「自分専用のブランチ」と分けて考える。 「みんなで共有しているブランチ」の代表例はmasterだな。他に次バージョン用のブランチなどがある 「自分専用のブランチ」はトピックブランチと呼ばれたりする。 自分専用のブランチは、その名の通り自分専用なのだから勝手に更新されることとはない。 みんなで共有しているブランチは誰かが勝手に更新する。 みんなで共有しているブランチは、そのブランチに対して直接修正してはいけない。 必ず共有ブランチから自分専用のブランチを作って作業をする。終わったら共有ブランチにマージする。 自分専用のブランチは自分専用なのだから好きにrebaseしてよい 自分専用でも他の人が見ることはある。だけどそれは見てるだけなので何も問題ない ここまでは前提知識として 続く 730 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 02:50:06.54 ID:j9mWyPD+.net] > 別の最新の更新内容をpushしようとしたらpullしろっていわれたので pullする必要があるのは共有ブランチの場合だけ。なぜなら自分専用であれば 自分しか更新しないから、サーバー側がローカルよりも新しくなることはなく pullする必要がない。 そして共有ブランチであれば、そこを調節更新することはないのでpullが失敗することはない 失敗したら間違って共有ブランチをローカルで更新してしまったとうこと。 その場合は（他のブランチにリネームしたりしてバックアップを取ってから） 共有ブランチは適当に巻き戻したり消して取り直せばいい じゃあ何故pushした時にpullしろと言われたのか？ それは単にサーバーにpushされているのと、 自分がpushした内容（の歴史）が食い違っていたからなだけ。 gitはブランチが共有ブランチなのか自分専用のブランチなのかの区別は できないから無いから食い違いをサーバー側が更新されたからだと解釈した。 でもそれが自分専用のブランチであれば、 ローカルにあるブランチが正しいので単にgit push --forceをすれば良い。 自分専用のブランチなのだから、git push --forceしたとしても 誰にも迷惑はかからない。 731 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 03:00:25.50 ID:j9mWyPD+.net] 補足 理屈上は>>725に書いたとおりで間違いないのだけど、 人間はミスするもので、間違ってローカルでmasterを修正して それをgit push --forceしてしまうなどということが起こりかねない。 中途半端にしか理解できてない人がmasterにpushできない？ あれぇ〜？ --forceしてみよう。とかやってめちゃくちゃにして、 その経験（？）を悪い方向に活かして、○○は禁止 （理由：なんでそうなるのか俺には理解できんから）とか 言い出してgitを使えない・不便な道具に、変えてしまう愚か者が少なからずいる。 だから早いうちにgithubやgitlabを取り入れた方がいい。 gitlab（無料だよ）だと、masterに対してのpush --forceを禁止して ウェブ画面に限定出来たり（デフォルトでそうなってる）と便利。 「共有のブランチ」と「自分専用のブランチ」を明確に区別するために プロジェクトのリポジトリから、自分専用のリポジトリへforkを行ってから開発するから ブランチがたくさん出来て、どれがなんのブランチなのかわからなくなることもない。 732 名前：デフォルトの名無しさん [2015/06/22(月) 04:12:25.25 ID:6fsOI3Rm.net] そして>>724-726を見た>>720は、なんだかよくわからないけどgit push --forceでいいのかぁ〜と理解し push --forceの乱発で他人のコミットを上書きしまくってプロジェクトを混乱に陥れるのであった… 733 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 05:17:00.13 ID:mEuvJOmb.net] >>724-726 の結論 git push --force 推奨 734 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 06:18:54.34 ID:j9mWyPD+.net] なんか必死なバカが居るｗ 735 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 08:17:21.67 ID:Jo3Uu3lv.net] 自演乙 736 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 09:57:48.30 ID:PyoyBJGz.net] >>727 >なんだかよくわからないけどgit push --forceでいいのかぁ〜と理解し これは別にID:j9mWyPD+悪く無いだろ…… 737 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 10:01:38.28 ID:PyoyBJGz.net] 大体、Git使う奴がアホかどうかなんてソフト側から判別できるわけ無いんだから、 どう丁寧に教えようがリスクは当然有ると考えるべき(戻せるだけマシ) だったら丁寧に教えてあげた方が後から文句言われる筋合いを無くせるという利点も…… 738 名前：ID:j9mWyPD+ mailto:sage [2015/06/22(月) 10:09:04.83 ID:6W+IUVUv.net] 俺的には プロ（俺）の目の前で、アマチュアが初心者に 「お前にはまだわからんだろう� 739 名前：ｪな〜」と 言い出したように感じたものでｗ アマチュアが、pushした物の歴史改ざんしたらいけないんだぜーとか push --forceはだめなんだぜーとか言ってるのを見るとねぇ（苦笑） そういう書き込みには、決まってなぜだめなのかといった理由が書いていない。 自分がわかってないからさ。 理由を考えれば、どういう場合にはだめで、どういう場合ならいいかが わかるはずなんだが、一部の人間は何も考えたくないからか、 状況など考えずに、良いか駄目かのわかりやすいルールを求める。 そういう人間にはならないようにしような。 [] [ここ壊れてます] 740 名前：デフォルトの名無しさん [2015/06/22(月) 10:16:31.40 ID:nboh/a20.net] 間違って操作しても壊れないようにするのがフェイルセーフ（馬鹿除け）の基本なんだが 741 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 10:30:46.58 ID:6W+IUVUv.net] 世の中に間違って操作しても絶対に壊れないものなんてないぞｗ フェールセーフというのは間違って操作しても「安全」という意味だ。 英語：セーフ＝安全 お前が言うべきなのは、フールプルーフな。 英語：フール＝馬鹿 gitにおけるフールプルーフはreflogだろうな。 これによってコミットが消えることはない。 間違って操作してもgitなら複数の場所にコピーがあるから これもフールプルーフといえよう。 push --forceしても別に壊れるわけじゃない。混乱が発生して困るだけだ。 もちろんそういう問題が発生するのは、みんなで共有しているブランチだけであって だから自分専用であれば誰も困らないんだからやっていいという話をしてる。 >>734 お前は何がいいたいのだ？ 742 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 10:52:29.70 ID:kJni3XZO.net] 釣られたんじゃね？ 743 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 11:00:33.51 ID:Jo3Uu3lv.net] リポジトリが公開されているからと言って 勝手にforkして作業してたら 主が勝手に（自由に）pushして forkした側が混乱して困ってこれまた勝手にクレームを付ける 誰宛てのアンカも無いレスに対して >>735 がやってることはまさにそれ 744 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 12:16:35.13 ID:a9m1vXpg.net] そういう揉め事はこちらへどうぞ peace.2ch.net/test/read.cgi/tech/1433650988/ 745 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 17:40:26.27 ID:PyoyBJGz.net] ID:6fsOI3Rm＝ID:Jo3Uu3lv必死すぎワロスｗｗｗ 746 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 18:04:38.52 ID:6W+IUVUv.net] >>737 落ち着こうｗ あんたが言っている問題（？） それはフォークなど関係なく発生することだ。 複数人で開発したら、一人が開発中に もう一人が修正した。という話をしているだけだな。 747 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 19:50:24.16 ID:ScRlfOQU.net] いっぱい釣れたね 748 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 20:27:08.06 ID:O6QpuzQl.net] おまえらpush --forceを甘く見すぎだな Aがトピックブランチ作成 Aがトピックブランチ上でコミットXを作成してpush Bがトピックブランチ作成 Bがトピックブランチ上でコミットYを作成してpush、トピックブランチ破棄 Aがトピックブランチ上でタイポ直したコミットX'をrebaseで作成してpush --force コミットYは上書きされてしまうわけだが、これ誰も気がつかずコミットYがGCされちゃうことあるんだよ？ 749 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 22:41:32.22 ID:mEuvJOmb.net] x されちゃうことがある o されちゃう 750 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 22:47:27.01 ID:O6QpuzQl.net] GCされる前に誰か気がつけばreflogから復旧できるんで 751 名前：デフォルトの名無しさん mailto:sage [2015/06/22(月) 23:36:10.08 ID:a9m1vXpg.net] >>742 AとBのトピックブランチが同じ名前ならBのpushのときに失敗するだろ。 その場合はトピックブランチを共有してるのだから、push -fしてはいけないのは当たり前 752 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 00:36:04.38 ID:UdZmnE2/.net] >>742 >>745の言うとおり。共有しているブランチは push --forceしたらだめだと書いた。ちゃんと判断して使え。 ミスしたらという話をするならば masterを消すことだって出来てしまう。 だからgitlabを使えと言ってるんだよ。gitはソースコードの管理をするためのもので ユーザーの管理、つまり誰が何をやっていいかダメかっていうのは管理してない。 --forceが問題なのではなくて、gitだけでやろうとしているのが問題 ユーザーの管理がしたいのならGitサーバーを使う。それはGit Proにも書いている。 https://git-scm.com/book/ja/v1/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC 俺のおすすめはgitlab。Git Pro 2nd Editionの方に翻訳されてるな。 https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-GitLab フォークして自分のプロジェクトで作業するならば、 メインのプロジェクトには共有ブランチだけ、 自分のプロジェクトには自分専用のブランチだけになる。 共有ブランチはプロテクト等をかけることで、 push --forceできなくすることもできる。 753 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 00:45:05.79 ID:4795aBmW.net] gcをしても初期設定だと直近二週間のコミットは保存されるし 他の奴の作業コピーから復元できるかもだし 754 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 01:19:15.14 ID:UdZmnE2/.net] 少なくともコードを書いた本人のマシンには 本人が書いたコードは残ってるんだよね。 755 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 16:29:38.65 ID:LQfp6JsA.net] べらんめぇ 宵越しのコードは持たねぇのが粋ってもんよ 756 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 20:22:25.05 ID:CqiNTuO0.net] おっ、粋だね！ 757 名前：デフォルトの名無しさん mailto:sage [2015/06/23(火) 20:57:22.50 ID:Yra6/pdr.net] >>749 てめえ、コミットする前にコード消しやがって、何が粋だよ 758 名前：デフォルトの名無しさん [2015/06/23(火) 22:28:58.60 ID:SktsG5/m.net] コードもまた別れがあるから愛おしいのよ。 いつでも逢えたらロマンチックじゃないじゃない。 759 名前：デフォルトの名無しさん mailto:sage [2015/06/24(水) 08:57:50.31 ID:NHniIMjV.net] >>751 江戸っ子は気が短けーんでい 760 名前：デフォルトの名無しさん mailto:sage [2015/06/24(水) 22:23:29.89 ID:ix5XSndE.net] コードなんてもなぁ、そう何度も何度もね、 テストしたりコミットしたりほどのもんじゃないんだよ。 オレなんか、急ぐときなんざ エディタで保存する前に 消しちまうんだ 761 名前：デフォルトの名無しさん mailto:sage [2015/06/26(金) 11:47:16.43 ID:Q1kb1EVf.net] 3つのファイルを編集した1コミット分をgit pushしたときに Total 9 (delta 5), reused 0 (delta 0) って表示されたんですが9と5ってなんですか？ 762 名前：デフォルトの名無しさん [2015/06/28(日) 11:33:24.51 ID:5m9gZHLm.net] 基本的には実行属性を無視しつつ、 ある特定のファイルの実行属性だけ無視しない という設定をしたいんだけど、どうすればいい！？ 763 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 11:47:33.27 ID:VLu09OAr.net] >>756 Linux使えば良い。 764 名前：デフォルトの名無しさん [2015/06/28(日) 13:44:26.56 ID:5m9gZHLm.net] >>757 Linux使ってるんだけど、どうすればいい・・・ 765 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 14:04:26.07 ID:lxz6gjyn.net] chmodぐらい勉強しろ。 766 名前：デフォルトの名無しさん [2015/06/28(日) 15:26:50.01 ID:5m9gZHLm.net] >>759 いちおうわかりやすく説明しなおすと、 chmodをすると、gitは属性の変更を検知するでしょ？ それを本当に実行するファイル以外では無視したいの。 たとえば、 bin というフォルダにあるファイルの 実行属性があやまって変更されたら検知してほしいけど doc というフォルダのファイルをうっかり属性変更しても そんなのは無視してほしいんですよ 767 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 15:36:00.06 ID:YBvq0FDq.net] .gitignoreや.gitattributesでどう設定すれば・・・って話だろうけど 確かにもうすこし具体的に何がしたいか書かないとレスつかないだろうね 768 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 16:49:31.94 ID:uJqfu/82.net] sambaからコピってパーミッション直さないのがいると 全部のファイルに実行権ついててうざっ…とはなるな 769 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 17:03:24.02 ID:WJabjmO6.net] >>762 cygwinなら/etc/fstabで/cygdriveをnoaclに設定しとけばその手の煩わしい手間の必要はたぶん無い msysgitとかだと同じことできなかったりする？ 770 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 18:27:03.56 ID:uJqfu/82.net] >>763 Windows->(Samba)->Linuxにコピーして Linuxでgit addした時の話ね msysgitなら実行権を無視するのでそういう事にはならないよ 771 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 18:39:52.16 ID:lxz6gjyn.net] だからLinux使えって言ってんだろ？ 772 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 20:07:20.93 ID:WJabjmO6.net] >>764 それはsamba側の設定でcreate maskを0644にしちゃえばいいと思うんけど、 そういうわけには行かない使い方をしてるのかな？ 773 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 20:25:52.15 ID:uJqfu/82.net] >>766 自分配下のものならそれでいいんだけど、 個人用のLinux PCとか、IT管理部門が許可しなかったりと なかなか統一できないのよね…。 質問の件は git config core.filemode false で 実行権限無効化するくらいしか思いつかないな gitattributesでできるんかな？ 774 名前：デフォルトの名無しさん [2015/06/28(日) 20:28:07.89 ID:5m9gZHLm.net] >>767 実行権限無視の設定にしてる。 でもこれだと、ほんとに実行するファイルの実行権限が落ちていた時に 気付かないので、できればやめたい 775 名前：750 mailto:sage [2015/06/28(日) 20:31:54.95 ID:/nFQf9C+.net] どなたかおねがいします 776 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 20:44:04.23 ID:WJabjmO6.net] >>769 stackoverflow.com/questions/21476167/when-i-do-git-push-what-do-the-statistics-mean-total-delta-etc 777 名前：デフォルトの名無しさん mailto:sage [2015/06/28(日) 22:55:49.53 ID:im5DcXMU.net] うーん、 プリコミットフィルターでコミットを拒絶するか ポストコミットフックで実行権を強制的に書き換えるか やりかた？知らん。 778 名前：デフォルトの名無しさん mailto:sage [2015/06/29(月) 16:18:10.01 ID:rbxhDT3n.net] git diffが見づらいんですが 背景色を変更したり文字の色を指定する方法をおしえてください 779 名前：デフォルトの名無しさん mailto:sage [2015/06/29(月) 17:14:42.93 ID:k+90EXgh.net] .git/config 780 名前：デフォルトの名無しさん [2015/06/30(火) 09:22:56.54 ID:TGfi4m1b.net] コミットした内容を破棄するんじゃなくて コミットしたことを破棄したいんだけど どうしたらいいの？ ファイルの内容は戻したくない 781 名前：デフォルトの名無しさん mailto:sage [2015/06/30(火) 09:39:02.37 ID:4wEdMli5.net] >>774 git reset HEAD^ 782 名前：デフォルトの名無しさん [2015/07/04(土) 13:39:17.57 ID:YKtPOMLD.net] 要件とか設計書をmarkdownとかで作成してバージョンを管理するとします。 そして変更履歴を一覧として出力(差分のみ)して作業指示書のようにすることはできますか？ 783 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 07:01:20.85 ID:p0+3cdhD.net] git log -p でええか？ 784 名前：デフォルトの名無しさん mailto:sage [2015/07/06(月) 11:19:13.00 ID:jgWjPX/O.net] SourceTree ってわかりにくくない？ 編集したのを元に戻すつもりで破棄を選んだら ファイルを消されたよ 実行したgitコマンドのログも見れないし 785 名前：デフォルトの名無しさん [2015/07/06(月) 12:24:05.59 ID:IqUlle/j.net] 使ってないよ 786 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 07:05:33.80 ID:NpIL7uvL.net] >>776 人間を機械のように扱わないとあかん案件か。 787 名前：デフォルトの名無しさん [2015/07/07(火) 10:56:27.88 ID:L2fl7GI9.net] >>780 Excelでいつの間にか更新されてて、取り込まれてないよ！っつーのをなくしたいんですわ 788 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 23:01:07.32 ID:JwFwNWWF.net] csvにしてからテキスト比較する程度でも足りそうな 789 名前：デフォルトの名無しさん mailto:sage [2015/07/07(火) 23:25:04.32 ID:y1gFbJO1.net] いままで要件定義とか設計書をExcelでやってたのをGit管理したmarkdownへ変更したいってことなのか？ 790 名前：デフォルトの名無しさん [2015/07/08(水) 01:45:10.53 ID:uot9w4rY.net] これって他人のコード見れたりするんですか？ 791 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 02:11:28.13 ID:uBhtmoLk.net] ほんとExcelの仕様書は根絶してもらいたいな バックエンドにGitを使ったWikiで何か良いものはないのかな？ 792 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 04:28:24.61 ID:L2Tv4EJx.net] >>785 gitlab 793 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 19:28:18.03 ID:ribTz8l0.net] >>785 エクセルをgitで管理すると捗るよ 794 名前：デフォルトの名無しさん mailto:sage [2015/07/08(水) 23:28:04.19 ID:PLuP1x0a.net] tortoiseGitのdiffでexcelの差分表示機能は秀逸 差分機能のないexcel自身を使ってなぜか差分表示を行ってしまう wordファイルはword自身の機能を使って差分表示 SourceTreeはWinMargeの呼び出しが標準たな？ tortoiseGitには負けるけどそこそこ使える コマンドラインではdocx2txtが定番なのかな？これってexcel対応してたっけ？ 795 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 00:13:15.31 ID:Ud/4MC5K.net] markdownやplantUML使うならAtomよさげだなあ これぞ開発者のツールって感じ 796 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 03:42:11.87 ID:/JprfCCX.net] >>787 > エクセルをgitで管理すると捗るよ 前にやってた（知らない所で勝手にやってた）ことあるけど データ容量増えすぎでいらいらするようになったよｗ 差分で記録できないからね。 画像とか含まれていると、数MB単位で増え続ける。 797 名前：デフォルトの名無しさん [2015/07/10(金) 04:02:17.76 ID:27W+BsF0.net] やって後悔するのは愚者 やらんでも予想出来るのが賢者 798 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 08:38:00.86 ID:xDEEK620.net] git って差分で記録なんてしてたっけ 799 名前：デフォルトの名無しさん mailto:sage [2015/07/10(金) 09:26:19.80 ID:JycZhxcB.net] その人はExcelでgitを作って管理すると捗ると言ってるのだ それなら通じる 800 名前：デフォルトの名無しさん mailto:sage [2015/07/12(日) 14:24:22.04 ID:PDFfD/6i7] >>792 コミット時にはしないけど、git gcの時に似ているファイル同士は連結圧縮してくれる 801 名前：デフォルトの名無しさん mailto:sage [2015/07/12(日) 14:24:46.34 ID:9keGjwZf.net] >>792 コミット時にはしないけど、git gcの時に似ているファイル同士は連結圧縮してくれる 802 名前：デフォルトの名無しさん mailto:sage [2015/07/13(月) 17:46:21.87 ID:t6CAZDWG.net] SourceTreeをアップデートしたらウィンドウが半分になった どうしよう 803 名前：デフォルトの名無しさん mailto:sage [2015/07/13(月) 17:49:20.78 ID:t6CAZDWG.net] ブックマークを表示してサイズ変更して非表示にしたら直った。 不思議なこともあるもんだ。 804 名前：デフォルトの名無しさん [2015/07/14(火) 01:33:04.33 ID:vBESeRtH.net] 案件とかで使ってないけど、趣味でgit勉強してます。 で、どういう運用すればいいのかよくわからん。 まず、バージョン1とかマイルストーンでブランチを切った方がいい？で、そこから機能でブランチを切ってく感じ？ 805 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 06:39:52.42 ID:lsljdDda.net] 好きにしろ 806 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 10:23:57.14 ID:pNaF7lhj.net] >>798 まずブランチなんか無視して使い方を覚えるんだ 807 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 11:24:20.22 ID:OwkWHpBs.net] >>798 このスレはgitであのコマンドってなに？とか git周辺のソフトって何が有る？とか そういうことを聞くスレだよ。 主に初心者向け gitの運用の仕方はこっち Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ 808 名前：デフォルトの名無しさん [2015/07/14(火) 12:53:22.36 ID:G0PBqp91.net] >>801 どう見ても初心者だろ 809 名前：デフォルトの名無しさん mailto:sage [2015/07/14(火) 13:07:53.62 ID:VxoBFrok.net] >>802 運用のことを考え出したら初心者じゃない。 コマンドなんてあとから覚えりゃいいんだよ。 運用があって、それに必要なものを作ったのが gitなんだから。 810 名前：デフォルトの名無しさん [2015/07/14(火) 13:20:00.15 ID:G0PBqp91.net] 初心者はコマンドを先に覚えた方が良い。 でないと、話が通じない。 ある程度使って、具体的に困ったところが出てきたら、運用スレで聞けば良い。 ただしあっちは関係無い話に脱線しがちだから、良いとこ取りした方が良いよ。 811 名前：デフォルトの名無しさん [2015/07/15(水) 23:09:43.18 ID:a+rEGmf6.net] すいませんgitでコミットするときにこのファイルは何で更新したのか思い出せません。 なので、これから更新する内容は「○○機能を実装」ってことでそれをプロジェクトルートのテキストファイルにメモ書きしてました。 しかし、コミットするときに毎回メモを見るのを忘れてしまいます。 再帰にコミットログを書いとくとかなんかtodoみたいなコマンドってありませんか？ 812 名前：デフォルトの名無しさん [2015/07/15(水) 23:10:19.62 ID:a+rEGmf6.net] 訂正 ☓再帰にコミットログ ○先にコミットログ 813 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:21:39.17 ID:YpeXwOwK.net] >>805 > それをプロジェクトルートのテキストファイルにメモ書きしてました。 いますぐそのようなアホなことを辞めましょう。 814 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:22:13.29 ID:VsrdjrWK.net] 前回との差分見ながらコミットログ書けばいい あらかじめ用意しておくから忘れるんだ 815 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:44:52.69 ID:DsRhlYqB.net] 自分が今なにをしてきたか忘れるのか、 よっぽどコミットを溜めるのか、 コミットのコメントが適当すぎるのか もうバージョン管理以前の問題な気が アナログだけど付箋にメモしてディスプレイに貼れば？ 左がこれからやること、上部が今やってる事、右が終わった事、 いや右は要らんかな？ 816 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 00:52:26.73 ID:Ye9E1FJD.net] >>805 自分が差分を見て理解できないコードをコミットしちゃダメだよ 817 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 02:04:46.85 ID:C5QhjRoF.net] git notes とかはどうかな？ 818 名前：デフォルトの名無しさん [2015/07/16(木) 04:35:55.01 ID:MREKRM2C.net] >>810 差分ってたまに直観的じゃない出力することが良くある 819 名前：デフォルトの名無しさん [2015/07/16(木) 07:52:03.14 ID:SnFgv9L8.net] git diffの表示範囲を広げるオプションは？ 820 名前：デフォルトの名無しさん [2015/07/16(木) 08:04:35.28 ID:SnFgv9L8.net] >>805 githubとかRedmineとかticket/issue管理ツールと併用するのが一番だけど、1人で使うのだと構築するのが大変かもね。 メモをgit管理されていれば、メモの差分もgit diffで出るよね。なので、commitする前に必ずgit diffしていればメモを見るのを忘れることはないはず。 このやり方をする/しないにかかわらず、commitする前にgit diffをするのは大事だから習慣付けるべきだよ。 821 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 09:31:42.39 ID:NYNU6iM6.net] 変更するたびにコミットしといてpushやmerge前にamendなりrebaseで整形すればよくない？ 822 名前：デフォルトの名無しさん [2015/07/16(木) 12:26:35.31 ID:WO54leEH.net] >変更するたびにコミット コンパイル出来ないものをコミットするメリットは？ 823 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 12:32:11.52 ID:DSiPnBiQ.net] コンバイル云々より下のレイヤーの使い方をしてるだけだろ。 ビルド管理の目的以外でバージョンコントロールしてはいけないという理由はない。 824 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 13:02:02.47 ID:Q/SdAAm+.net] してはいけないのではない。 ソフトウェアのバージョンを管理する以外につかっても 意味が無いということだ。 825 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 13:39:11.99 ID:Ye9E1FJD.net] ぜんぜん使いこなせてないな そんなんじゃgitを使う意味が無い 826 名前：デフォルトの名無しさん [2015/07/16(木) 14:56:22.79 ID:SnFgv9L8.net] ここは初心者向けだそうなので、gitの使い方に自信がある人はこちらへどうぞ。 Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net peace.2ch.net/test/read.cgi/tech/1433650988/ 827 名前：デフォルトの名無しさん [2015/07/16(木) 15:16:59.28 ID:FDPV8gUS.net] >>810 ある機能を実装するのに、差分の出し方としての段階があると思うけどそういう単位でやるの？ 面倒じゃない？ 828 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 15:29:22.25 ID:cQ0wrBTO.net] >>816 何をやってたか忘れない 別途メモ管理不要 revertできる 829 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 16:59:52.48 ID:XEPlidkJ.net] revertは悪 830 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:11:52.83 ID:BQ1LfMZh.net] >>805 > 先に再帰にコミットログを書いとく どうしてもと言うなら git commit --allow-empty -m "○○する予定" touch a; git add a; git commit --amend -m "○○してやったぜ" 831 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:13:56.91 ID:sUV1QtUU.net] プログラムしてからコミットコメントを練る習慣を逆にすることを勧める。 コミットコメントの内容は、コーディングする前に決めておく。 つまり、これから何をプログラムするのかをまず決める。 その後、コメント通りにプラグラムできたら完了、コミットする。 下記のページの Write preemptive comments でも推賞されている。 https://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/ こうすれば、何で更新したのか、と悩むことはなくなる。 832 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 19:24:57.63 ID:sUV1QtUU.net] >>805 「○○機能を実装」というのがデカすぎるから、 メモを見なきゃ把握できなくなるんだよ。 で、メモを見るのを忘れて困ったことになる。 これを改善しないと、git に君が望む機能（ツール）があったとしても、 全く役に立たなくなる。 更新内容の粒度はもっともっと小さくしなきゃだめだ。 10分かそこらでプログラムできる程度の大きさにしてみな。 そうすれば、メモを見る必要すらなくなる。 833 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 20:38:56.88 ID:IhY29Rvn.net] VCSがない時代の人 1.あれやこれや編集して、時々変更が失なわれないようにファイルに保存 2.目的の変更が完了したところで、バックアップを作成しておく VCSの時代の人 1. 以前と同じ 2. リポジトリにコミット DVCSの時代の人 1.編集中の変更は基本自動保存。昔のファイル保存するような感覚でローカルリポジトリにコミット。 2.目的の変更が完了したところで、履歴をまとめてリモートリポジトリにプッシュ。 この運用方法のポイントは ファイルは自動保存すること。 ローカルコミットにはまとまった意味など不要。 単に編集量や、経過時間のチェックポイントとしてコミットする。 このコミットコメントは、いい加減なメモや、あるいはコメントなしでもよい。 834 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 00:55:21.98 ID:6Y2ZhytJ.net] Android studioというかIntelliJ IDEAでGitと連動させたソースの編集がまさに>>827のDVCSの時代の人のやりかたができて便利 ファイルへの保存についてはまったく気にする必要がない ソースの編集画面でHEAD内容と差分のある行の左端に常に印がつく その印をクリックすると編集前の内容がポップアップで表示されて、行を編集前の状態に戻すとかこのポップアップから操作できる ソースの編集画面からファイル単位のコミットとかできるし、--amend指定なんかもワンタッチ HEADと差分あるファイルの一覧を表示してる窓からまとめて全部コミットとかもできる これで行単位のコミットとかできたら完璧なんだけどそれは無いみたい IDEを起動したままコマンドラインでgit add -pしてcommitしてもIDE側でほぼ完璧に追従してくれるのでまあなんとかなってる 835 名前：デフォルトの名無しさん [2015/07/17(金) 04:20:41.08 ID:OfiHmkDl.net] >>826 差分を1つ1つみなきゃいけないゴミコード打つなよ 836 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 05:57:36.41 ID:JRoNxi4V.net] パーツごとにブランチを分けて開発し、各パーツを統合する開発ブランチにマージして開発をする or パーツごとにリポジトリを分けて開発し、全てのパーツをサブモジュールとしてリポジトリ内に持つリポジトリで開発をする どっちがいい 837 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 13:27:11.26 ID:2DUlvwkL.net] パーツごとにブランチ？ そんなことをやってるプロジェクトがありますか？って話だ。 838 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 20:25:59.09 ID:zMQ3zlsL.net] よっぽどの規模じゃないとあんまり細かくサブモジュール化しても面倒なだけだと思う 839 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 20:45:24.33 ID:3x9AOrGu.net] index.php calendar.php この２つのファイルを編集してまだaddをしてない状態なんですが index.phpだけ編集しなかったことにして前回のコミットした時の内容のままにして、 calendar.phpだけコミットしたいんですが どうやってindex.phpを更新してなかったことに出来ますか？ 840 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 22:56:30.48 ID:muZ+fGR1.net] >>833 Indexの変更を手元に残しておきたければcalenderだけaddしてcommit 841 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 17:46:21.84 ID:GcYCq0Aw.net] iOSアプリ開発をsource treeで管理している初心者です。 今回チャット機能つきのアプリを制作しているのですが、ネイティブコード、サーバーサイド(php)、データベース(MySQL)を同時に管理するのは無理(もしくはかなり難しい)ですよね？ ネイティブコードとサーバーサイドはsource treeで管理するとして、 データベースの情報はコミット毎になんらかの方法で全テーブル情報をログ出力して、それをメモ代わりに置いておく…ということくらいしか思いつかないんですけど、どうでしょうか。 サーバー連携が必要なアプリって、みなさんどうやってGitで管理してるんでしょうか… 842 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 20:15:32.34 ID:5OYZKZ4e.net] 普通、バージョン管理の対象にするのはDDL、初期データ、設定ファイルくらいだろ。 コミットごとのテーブル情報って、何を管理しようとしてるんだか。 843 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 21:05:27.99 ID:Xl228nsE.net] 俺もデータ内容まで保存しようというのはかなり冗長な気がする。 スキーマ更新のSQLのみバージョン管理、 DBのバックアップは別にダンプしてアーカイブだろうな。 844 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 06:20:36.38 ID:KkAp073H.net] >>835 データの中身は管理対象外、データベースのバックアップの問題 ソフトが対応するデータベースのインターフェースと言う意味では クエリー処理のプロシージャをDB側で組んでおくのが一番簡単だけど どうしてもというならDBをゼロから構築するスクリプトなりバッチなりを書いて それをGitで管理せておく なんにしろデータベースとアクセスアプリは分離しておくのが大切 845 名前：デフォルトの名無しさん [2015/07/19(日) 06:48:36.12 ID:EU0ROg42.net] 特定のデータの混入がバグの原因になる場合 git bisect で特定したければ DB のバックアップも git 管理に入れる必要がある 846 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 07:28:28.07 ID:KkAp073H.net] >>839 なるほどそういう考え方もあるか 847 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 09:06:48.58 ID:wG1rbxp8.net] バグはデータじゃなくてコードの側に存在するものだろ。 bisectするにしても、バグを再現できる同じデータを使わなければ見つかるもんも見つからなくなると思うが。 848 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 09:12:53.24 ID:I0iNBGYL.net] 確かにその場合単体テストを増やすべきな気がするな 849 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:04:49.68 ID:Npxm1YBj.net] >bisectするにしても、バグを再現できる同じデータを使わなければ そのためにコミットごとにデータもダンプするんじゃないのか？ 再現ももちろんデータ書き換えでテスト実行 850 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:48:59.20 ID:wG1rbxp8.net] bisectは基本的に、新たに判明したバグについて過去にさかのぼって原因箇所を特定する ためのものだと思っていたが。 テストデータもcommit時点のものを使うとすればその時点で既にbadだったということになるが、 そういう運用していたらbisect役に立たないんじゃね？ もちろん、bisectを使うつもりがなければビルドが通らないcommitするのも自由だと思うんで それは別の話として。 851 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 12:59:24.27 ID:3NrA4A7J.net] >>843 > そのためにコミットごとにデータもダンプするんじゃないのか？ データは0の状態から、テストコードを書くんだよ。 テストコードの中でデータをリストアする 普通はフィクスチャっていうけどな。 当たり前だが実データまるまるダンプしてリストアなんてしない。 そんなことをやったら効率よくテストがかけない。 テスト全体が一つのデータに依存してしまうからね。 正しいテストとは、テスト対象（ファイル単位等）の テストに必要なデータだけを入れてテストする。 だからテスト実行前にはデータを全て削除する。 データベース全体をダンプするなんてことはしない。 852 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 13:06:34.44 ID:I0iNBGYL.net] テスト用ＤＢの他にモック、リポジトリパターンも使われるな 853 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 14:22:36.05 ID:4suFbVBW.net] データもgitで管理するって新しいなｗ 854 名前：デフォルトの名無しさん [2015/07/22(水) 10:52:31.65 ID:phbUY/16.net] git checkout develop git branch -b my_topic_branch とした後でいくつかcommit後、「my_topic_branch作成直後〜さっきのcommitまで」をrebaseしたいとき、 git rebase -i *** の***には、何と指定すればいいですか？ 855 名前：デフォルトの名無しさん [2015/07/22(水) 12:19:49.68 ID:EiNSX7P4.net] 何も指定しない 856 名前：デフォルトの名無しさん [2015/07/22(水) 13:10:35.36 ID:phbUY/16.net] 何も指定しないと怒られます。 $ git rebase -i usage: git-rebase [-i] [options] [--] <upstream> [<branch>] or: git-rebase [-i] (--continue | --abort | --skip) ちなみに、今はcommitの数を数えて、HEAD~~~~~~とかしてます。 857 名前：デフォルトの名無しさん [2015/07/22(水) 13:17:41.56 ID:EiNSX7P4.net] じゃあ、git rebase -i develop 858 名前：デフォルトの名無しさん [2015/07/22(水) 13:54:39.00 ID:phbUY/16.net] >>851 おお、それでいけました。 ありがとう。 859 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 16:41:20.44 ID:zBOMfGM9.net] >>851はgit checkout developの後にdevelopへ何かコミットされた場合、 たぶん>>848が期待してる動作にはならんぞ 860 名前：デフォルトの名無しさん [2015/07/22(水) 17:25:54.55 ID:EiNSX7P4.net] そういや、そうだね。 じゃあ、 git rebase -i `git merge-base develop HEAD` ってのが、あったけど、素直にgit logして分岐点のcommit idを調べた方がはやいかもね。 別のブランチとの分岐点を起点に rebase -i する git エイリアス qiita.com/uasi/items/70d4358c3c70c64f4261 861 名前：デフォルトの名無しさん [2015/07/22(水) 18:24:49.47 ID:phbUY/16.net] >>853 なるほど、topic branchを複数作って作業するときまずいわけですね。 >>854 merge-baseのこと知らなかったので、もう少し調べてみます。 862 名前：デフォルトの名無しさん [2015/07/27(月) 15:06:20.98 ID:+ejnTFZv.net] 質問させてください 公開版のHTMLと公開を控えたHTMLがあって、これをgitで管理しようかと考えているのですが 公開版（Master）、確認用（Blanch）とした場合、Blanchは確認環境（HTTPアクセス）として機能させることはできるのでしょうか 863 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 15:24:49.11 ID:aZg91AP9.net] >>856 何をどうしたいのかもうちっと具体的に説明しないと ツッコミようがないぞ？ 864 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 15:45:36.34 ID:biNPOZMH.net] >>856 masterブランチはどうやって確認環境として機能させるつもりなの？ 865 名前：デフォルトの名無しさん [2015/07/27(月) 15:47:39.18 ID:+ejnTFZv.net] >>857 説明不足ですみません！ たとえば example.com/public/ この「public」内のコンテンツをgitで管理するとして 「public150727」という名前で「public」のブランチの更新版を作ったときに、ブランチ「public150727」の内容を確認環境としてブラウザで閲覧する方法はないものかと思いまして質問しました。 もっと砕いた言い方をしますと、gitと使えない環境の人にブランチ「public150727」の内容をブラウザで見てもらうことはできるのでしょうか。 866 名前：デフォルトの名無しさん [2015/07/27(月) 15:50:15.95 ID:+ejnTFZv.net] >>858 そうですね、勝手な思い込みで公開版をマスターという前提で書いていました 特に公開中のバージョンがマスターであるこだわりはありません 失礼しました！ 867 名前：デフォルトの名無しさん [2015/07/27(月) 15:56:55.58 ID:T5zoWN7L.net] masterブランチをexample.com/public/でアクセスできるようにする手順と同じ手順でできる 868 名前：デフォルトの名無しさん [2015/07/27(月) 16:03:28.50 ID:+ejnTFZv.net] >>861 「public150727」をpushするということですね！ 869 名前：デフォルトの名無しさん [2015/07/27(月) 16:16:20.09 ID:T5zoWN7L.net] >>862 > 「public150727」をpushするということですね！ 違う。そういうレイヤーの話じゃない。 「更新されたmasterブランチ」を「example.com/public/でアクセスできるようにする手順」だ。 870 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 16:23:58.54 ID:ybeDhwD5.net] >>859 ローカルサーバーで見るではだめなの？ りぽじとりを２つ分けて それぞれ別々でステージングサーバーにでぷろい環境にするとか 871 名前：デフォルトの名無しさん [2015/07/27(月) 16:50:45.48 ID:+ejnTFZv.net] >>863 理解が浅くてすみません 自分の知識ですとブランチごとにURLを割り当てるように読み取れるのですが、おそらくそういうお話ではなさそうなのでもっと勉強します！ >>864 やっぱりステージングサーバーで確認→本番環境にPUSHするのが安心ですね 皆さんありがとうございました！ 872 名前：デフォルトの名無しさん [2015/07/27(月) 16:52:44.86 ID:T5zoWN7L.net] まぁ、本人がこれで解決したと思うんならそれでいいか・・・。 873 名前：デフォルトの名無しさん [2015/07/27(月) 17:03:36.01 ID:+ejnTFZv.net] >>866 よかったら>>863に書いていただいた手順の概要、もしくは参考のURLを教えていただけませんでしょうか 874 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:17:59.43 ID:T5zoWN7L.net] >>867 > よかったら>>863に書いていただいた手順 いやいや、それは俺らにはわからんよ。 その手順がわかりさえすれば、それと同じ手順でできるだろってこと。 ローカルのmasterを変更して、それをサーバにpushしたら、example.com/public/の内容が更新されるんだろ？ その仕組みは一体誰が構築したんだ？ 875 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:18:41.69 ID:aippD/Jn.net] .gitをWebサーバーで公開していないか心配になるな 876 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:21:38.69 ID:T5zoWN7L.net] >>869 うわ、その発想はなかったわ。 877 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 17:27:25.72 ID:JJPg7kwZ.net] 業務使うコマンドを全部教えてください 来月からアルバイトなんですけど clone,log,reflog,reset,branch,push checkout,commit,add,rm,mvはしってます 878 名前：デフォルトの名無しさん [2015/07/27(月) 18:21:27.18 ID:bJ8mI018.net] >>871 git --help 879 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 21:16:18.54 ID:v7fIr+eP.net] >>869 Push to deploy の改善 2.3.0 で入ってるし .git を不可視にしとけば個人サイトくらいなら問題ないんじゃない？ 880 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 22:46:51.50 ID:aZg91AP9.net] >>859 やつぱりまだわからないや やりたいのは次のどっち？ 1) 公開webページとかのhtmlその他諸々をgitで管理して どっかのブランチにコミットすると自動的に公開webページになるようにしたい さらに、公開前の事前確認用のページも用意したい 2) なんかプログラム開発中のソースコードとかをgitで管理しておいて みんなにレビューしてもらうためにwebページで閲覧できるようにしたい 881 名前：デフォルトの名無しさん [2015/07/27(月) 22:48:07.44 ID:u9s58J+y.net] A:ある手順を踏めばできるぞ B:プッシュすればいいんですね A:そういうレイヤーの問題じゃない B:ではどういう手順で？ A:それはわからん、プッシュすればできるだろ なんとなくこのスレの闇を垣間見たような気がするぜ 882 名前：デフォルトの名無しさん mailto:sage [2015/07/27(月) 23:00:40.37 ID:aZg91AP9.net] あ、よく見たら1)の方だね。 俺だったらポストフックスクリプト書こうとするな 特定のブランチにコミットされたら対応するディレクトリにexportするようなやつ gitに付属のフックスクリプトのサンプルに似たようなことやるのがあったと思うから調べてみ 手抜きバージョンなら 事前確認用のディレクトリにクローンしておいて 1分おきとかでpullかけるようにcronをセットしちゃう こんなあたりでいかが？ 883 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 13:25:37.42 ID:3O5DcyiA.net] Jenkins とかの Pull Request Builder とかでいいんじゃないかと あとは heroku なにかに push して確認すればいいんじゃない? 884 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 16:06:24.66 ID:iS6umbvt.net] 2.4.7 と 2.5.0 がリリースされたね。 https://github.com/git/git/releases/tag/v2.4.7 https://github.com/git/git/releases/tag/v2.5.0 885 名前：デフォルトの名無しさん mailto:sage [2015/07/28(火) 23:54:34.28 ID:Z/s3EayV.net] git v2.4.3 mv index.php sub/list.php git add . git commit -m "backup" コミットした後に rename index.php => sub/list.php (74%) って表示されたんですがこれってindex.phpをgit mvで移動したのと同じことですか？ ato 74%って何を表してるんですか？ 886 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 00:17:46.73 ID:j0BJwxBz.net] ファイルの一致率。ファイルの修正と移動を同時にしたんだね。 gitは移動を記録していないので、ファイルの一致率から移動を推測している。 887 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 09:32:05.34 ID:bPiFDPfp.net] >>859 よそ様の記事だがこんな感じだよ、hook script < qiita.com/fnobi/items/98bd5d1c83c010842733 > ぜひバルスしてくれたまえ 888 名前：デフォルトの名無しさん [2015/07/29(水) 15:20:03.83 ID:YsMaiv/S.net] あるフォルダの中のあるフォルダ・ファイル以外を無視したいんだけど .gitignoreをどう書いたらいいかわからない hoge/piyo　　←無視しない hoge/fuga/　←無視する hoge/foo/　　←無視する hoge/bar 　　←無視する たとえばこんな感じで、今は fuga,foo,bar を毎度列挙してるけど 今後フォルダがどんどこ増えるとするとちょっと嫌な気分になる 889 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 16:33:49.47 ID:bPiFDPfp.net] >>859 890 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 16:38:56.52 ID:bPiFDPfp.net] >>859 How to rebuild from update hook で検索してみ kernel.orgでのドキュメント自動公開用のフックスクリプトが解説付きで買いてあるよ あなたの場合はこれよりは簡単なはず 891 名前：デフォルトの名無しさん [2015/07/29(水) 17:01:12.31 ID:1zEW+9y+.net] hoge/!piyo 892 名前：デフォルトの名無しさん mailto:sage [2015/07/29(水) 19:54:41.79 ID:syqOZkA4.net] >>878 「Git 2.5」がリリース osdn.jp/magazine/15/07/30/044700 893 名前：デフォルトの名無しさん mailto:sage [2015/07/30(木) 01:34:27.13 ID:6b1uCZJv.net] おお、ついにPerforceまで取り込む気か！ 894 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 08:21:08.61 ID:Uyj1+FiM.net] 指定したディレクトリ以下のファイルをスキャンして 編集してから1週間以上コミットせずに放置してあるファイルを 一覧で出力するようなスクリプトかツールあったら教えて下さい 雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて そのまま忘れて半年放置のようなファイルを検出したいのですが 895 名前：デフォルトの名無しさん [2015/07/31(金) 08:36:32.35 ID:709JoO30.net] git diff 896 名前： HEAD [] [ここ壊れてます] 897 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 09:00:48.29 ID:u6UInjxJ.net] >>888 > 雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて svnじゃないんだから、コミットしろよｗ svnと違ってコミット＝サーバーに送信 ではない。 そこがsvnのだめなところであり、gitの優れたところなんだよね。 gitなら安定しなくてもコミットできる。 もしバグが見つかれば修正してrebaseしてまとめてしまえばいい。 だから意味がある単位でコミットしていって、 あとでまとめて安定したと思ったらサーバー（共有リポジトリ）にpushすればいい。 （work in progress的なやりかたなら、作りかけでもpushするのもあり） そこからレビューをうけてOKになったらmasterにマージする。 「安定したらコミット」という発想をやめないといけない その発想だとどうしても一回のマージのコードが多くなりすぎる。 小さく機能毎にコミット、gitではそれができる。 898 名前：デフォルトの名無しさん [2015/07/31(金) 09:30:41.27 ID:709JoO30.net] コンパイルできないものもコミットしていいですか？ 899 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 09:51:16.96 ID:02j0y00V.net] いいよ 900 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 10:08:59.48 ID:VSZ3MRZU.net] >>891 そもそもスクリプトはコンパイラしないし 901 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 10:23:03.17 ID:5Be3R/21.net] 「意味がある単位」でコンパイルできないものという発想が良くわからない。 902 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 12:30:24.06 ID:Q/Fv6mzV.net] 毎朝コミットで良いよ 903 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 12:32:31.44 ID:02j0y00V.net] svnのコミットに近いのは、masterへのpushじゃないかね 904 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 13:05:45.97 ID:5Be3R/21.net] >>888 ひょっとして、etckeeperが求めるものだったりする？ 905 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 14:59:02.99 ID:Pi4vilvw.net] https://git-scm.com/book/ja/v2/使い始める-Gitのインストール ここの一番最後に ＞次からはGitを使ってGitそのものをアップデートできます： って書いてあるんですが これってmakeとかしなくてもgit pullしただけで新しいバージョンのGitが使えるようになるってことですか？ 906 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 15:49:47.76 ID:5Be3R/21.net] >>898 ならない。 907 名前：デフォルトの名無しさん mailto:sage [2015/07/31(金) 15:51:07.09 ID:R58DjZqg.net] >>898 インストールしたGitを使ってGitのソースをアップデートできるって意味だな 当然ソースをアップデートしたあとmakeは自分でやる 908 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 05:22:16.40 ID:fbUoNrmE.net] >>891 > コンパイルできないものもコミットしていいですか？ 他人に渡さないならば何の問題もない。 svnとか使ってると、この自分だけが触れる コミットという概念がわからんのだろうな。 909 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 05:24:32.97 ID:fbUoNrmE.net] >>895 > 毎朝コミットで良いよ なんで1日の区切りでコミットしてるんだよｗ 作業の区切りでコミットしろよ。 大抵の場合、1日に数回コミットするもんだ 910 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 05:32:58.26 ID:fbUoNrmE.net] >>894 > 「意味がある単位」でコンパイルできないものという発想が良くわからない。 コードとして意味がある単位だと、コンパイルできないことはないはずだね。 だけど、作業として見るとコンパイルできないけどコミットすることはあり得る。 例えば何かの修正をする時、設計Aの方法で実装するか、 設計Bの方法で実装するか悩んでたとする。 悩んで出てもわからないのでざっくりと作って検証することにする。 設計Aである程度作って、設計Bである程度作る。 そういった場合に、コンパイルできない状態でコミットすることはあるだろう。 もちろんこれはマージするときには、コンパイルできる意味がある単位に直すのは 当たり前だけど、作業中であればコンパイルできない単位でコミットすることはある これがsvnだと即サーバーにpushされて周りに迷惑をかけたりすることがあるけど、 gitだと自分だけのコミットにしておけばいいので、中途半端なコードでも バンバンコミットできる。というかgitならコミットしていいんだよ。 そのためにあるのがrebaseという機能なんだから。 911 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 06:00:09.26 ID:Fq14Oy7Q.net] msysgitは2系が出てくる気配ないし もうgitに追従する気は無いってことか 912 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 06:17:46.92 ID:fbUoNrmE.net] >>904 俺はwindowsだとcygwinを使ってるよ。 色々他を試したが結局cygwinに戻ってきた。 昔と違ってマシンスペックが上がったから たいして重さを感じないしね。 zshも使えるし。 913 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 07:37:18.72 ID:O3MfLUJM.net] >>904 v2系はこれ？ 使ったこと無いけど git-for-windows.github.io/ 914 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 11:19:27.66 ID:BlX74pFF.net] >>903 あるある 俺も「筋が悪そうだからこのブランチは放棄」ってコメント付けてコミットした事は何度かある 915 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 14:26:03.50 ID:fbUoNrmE.net] 他にも思い出した。 とある修正をしていて、コードを書いていると うぉい、ここバグってるじゃねーか （そのせいでとある修正がちゃんとできない） 一旦コミットしておいて、 先にバグの修正をコミットして、 んで戻ってくる。 こういった時に中途半端な状態でコミットする。 戻ったあとはバグ修正状態からの変更ににrebaseする。 このようにgitの素晴らしさっていうのは、 ファイルの管理やバックアップではなく、 実際の開発で起こることに対応するための機能なんだよ。 履歴管理ツールではなく、開発ツール。 そう認識しないといけない。 916 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 21:25:30.14 ID:fuLtc72j.net] >>908 rebaseしたくないので、同じようなことを rebaseしないでやる方法も教えてください。 おねがいします。 917 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 21:30:36.62 ID:cZ9y3hcR.net] >>909 「rebaseしたくない」ではなく 「馬鹿だからrebaseを使える能力がない」の 間違いだろ？ 「したくない」ではなく「できない」 自分に嘘をついてはいけない。 918 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 21:39:52.86 ID:Co43fSsi.net] 正解は「rebaseする必要はない」でした 919 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 22:52:16.85 ID:cZ9y3hcR.net] 道具は適切に使うものだ。 目的のために作られた専用のものがあるのであれば それを使えばいい。 それが必要だから作られたわけなんだから。 920 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 23:12:53.23 ID:h+APIw5a.net] stashやcommit --amendや--no-commit系使える時は使う。rebase代わりにformat-patch使うことケースも1%くらいはある。 でもほぼrebase -iだな。 921 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 23:18:37.12 ID:Co43fSsi.net] 道具は適切に使うものだ。 そして、それがあるから使うというのは適切な使い方ではない。 それは道具に使われてると言うんだから。 922 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 23:31:46.83 ID:fuLtc72j.net] >>910 rebaseという思想が好きじゃないんです。 それはそれとして、rebaseを使わないと出来ないことなのですか？ 923 名前：デフォルトの名無しさん mailto:sage [2015/08/01(土) 23:49:08.71 ID:RZc3oG0T.net] とりあえず空行交えて語りたい人たちは運用スレ行ってください 924 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 00:01:19.35 ID:ID0TD3H5.net] gitは運用方法に派閥っていうか宗派っていうか宗教戦争みたいなもんがあるのか 925 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 00:09:46.39 ID:KQ3UQl73.net] 運用が自由すぎて どこかの宗派の戒律を受け入れたほうが楽、と言うのはあるな 俺はgit-flow派 926 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 00:12:00.18 ID:uoA7o0bf.net] >>915 > それはそれとして、rebaseを使わないと出来ないことなのですか？ ？ rebaseを使うとやりたい事が簡単にできるんだよ。 やりたい事＝思想。 rebaseを使わなくても、同じことをするのであれば rebaseの思想は正しいということとなんだが。 927 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 00:15:40.65 ID:gKbzhWvd.net] rebaseしたくないならmergeすりゃいいじゃん 928 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 00:37:19.06 ID:eV4xuuQq.net] 複数コミットにまたがるamendのようなrebase -> rebase開始位置に指定したコミットは変らない -> HEADのファイルは変化しない 分岐した元ブランチとの関係をFF状態にするためのrebase -> rebase開始位置に指定したコミットが別のコミットになる -> HEADのファイルが変化する 良く知らない人はrebaseっていうと後者しか思い浮かばなくて mergeすればいいじゃんとか言い出す 929 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 07:51:47.64 ID:zAkA6wkz.net] rebaseは手段の一つであるが目的ではない rebaseの思想とかｗ馬鹿はこれだから怖い 930 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 08:42:49.05 ID:gKbzhWvd.net] rebaseでしかできないことがあるのは当たり前。 rebase以外で目的を達成することができることがある != すべてrebase以外で実現できる 931 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 09:00:44.24 ID:dTRZmQiN.net] 論理値の比較に等号不等号つかうひとって筋が悪いよね 932 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 13:19:25.28 ID:5pxTtzkh.net] >>924 世間のレベルに合わせてるんだよ。 あと、rebaseは名前が嫌い。 933 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 13:30:22.74 ID:RcysspGc.net] たかがgitを使える程度で尊大な大先生がよくわくスレだ 934 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 20:18:22.98 ID:HQ+xGyu0.net] linuxでgit pullで新しいコミットを取得したら自動でビルドしたいんですけど どうやればいいのか教えてください 935 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 21:02:00.58 ID:j05l/s8s.net] >>923 > rebaseでしかできないことがあるのは当たり前。 rebaseでしかできないことなんてない。 全ては効率の問題。 その他の方法でもやれるが、 効率が凄く悪くなる。 例えて言うのなら、東京から大阪まで徒歩でも行ける。 車でしか行けないわけじゃない。それと同じ。 ある目的のためにrebaseという手段が作られた。 rebaseは目的ではない。目的を最速で達成するための 手段なのだ。使わない理由がない。 936 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 22:07:56.09 ID:zAkA6wkz.net] rebaseでしかできないことなんてないし rebaseしなければいけないこともない ではなぜrebaseするのか？ これは哲学的であり、そしてかなり難しい問題のようにみえる しかし、実は我々はその答を既に知っているのだ その答とは そこにrebaseがあるからだ 937 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 22:13:02.07 ID:j05l/s8s.net] いや、rebaseがなかったから作ったんだよｗ Linusがね。必要だと思ったから作った。 938 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 22:51:23.25 ID:sASJ2DPa.net] Linusまたはその後継者が必要だと思ったからrebaseが作られた きっとそうだろう でも俺はLinusじゃない 939 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 22:54:55.58 ID:I5g9+RU+.net] Linusよりも劣る人間が言っても説得力ないな。 940 名前：デフォルトの名無しさん mailto:sage [2015/08/02(日) 23:04:48.44 ID:sASJ2DPa.net] >>932 つまりだ、Linusのために作られた道具を 俺ごときが使いこなせるわけがない ということだ 941 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 08:13:34.83 ID:6s/iApNK.net] 誰でもrebaseを使う事によって最速のrebaseが達成出来る 全く問題はない 942 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 17:13:09.03 ID:CE59HNJ8.net] >>908 > 一旦コミットしておいて、 > 先にバグの修正をコミットして、 > んで戻ってくる。 stashしろよ。 943 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 20:22:26.69 ID:OzQ4PZKS.net] >>935 やってるよ？ コミットしてないファイルがあるとrebaseできないからね。 stashしても作業中のファイルを一旦対比してから、 その後で修正してrebaseする。 944 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 20:35:53.78 ID:nTSIXxVa.net] rebaseってどういう機能なの？ コミット済みのコミットにマージするの？ 945 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 20:40:24.64 ID:6s/iApNK.net] 履歴を改竄するだけの、稀に便利だけど、必然性は全くない機能。 946 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 20:43:36.27 ID:OzQ4PZKS.net] 間違いをしないと言う人間には 不要でしょうなぁｗ タイポしたことがない人、手を揚げて！ 閻魔様の前に連れて行ってあげる♪ 947 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 20:57:28.47 ID:DLpcuCaG.net] rebaseが無かったら単なるバージョン管理ツールだね rebaseがあるから差分管理編集ツールとでも呼ぶべき別次元のツールになった 948 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 21:01:48.03 ID:Po35HDPO.net] rebaseがないと、もうバグはないかな？とか考えてしまって まだコミットしないで様子を見よう。とかやってしまうんだよね。 そうすると小さくコミットすることが難しくなってしまう。 949 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 21:20:26.33 ID:6s/iApNK.net] バグの痕跡を秘密裏に闇に葬る暗黒のrebase使い達 950 名前：デフォルトの名無しさん mailto:sage [2015/08/03(月) 23:17:22.87 ID:nTU4lW67.net] >>937 rebaseはブランチの分岐点を変更する機能 gitより前にclearcaseなどで実装されていてgit固有の機能という訳ではない rebaseにコミットの編集・結合・取捨選択する機能を追加して より柔軟にコミットを直せるようにしたのがgitかな 951 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 02:11:14.86 ID:pFxIT8vh.net] >>942 リリースしてないもののバグを なんで痕跡残さないといけないんだ？ 952 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 08:51:51.90 ID:1pDlaOkO.net] >>942 成果物の途中経過を次元の狭間に葬り去る古のno-commiterとの血で血を洗う闘争の幕開けであった 953 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 09:07:24.48 ID:LaebqzUe.net] 前のコードはコメントアウトして残せ。 リリースしてないコードも全部だ。 954 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 09:35:03.57 ID:ioOBuo8G.net] 年代記に残る争いになるわけですな あ、改竄派が勝てば、そもそも争いはなかった事になって、年代記には残らないね え？言葉が悪い？ では修正的歴史観と呼び直しましょう。 955 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 10:08:20.01 ID:rYHf65xq.net] >>936 > >>935 > やってるよ？ は？stashせずにコミットしてんだろ？ 956 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 14:23:44.57 ID:jQzRldfC.net] コミットにランク機能がほしい とりあえずバックアップ代わりのコミットと コンパイル通ったコミットとガッツリテスト済みのコミットと それぞれ記録したいけど、ログをみるとき 全部出てしまうのはうっとおしい （ガッツリテストとおったログだけみたい） 957 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 14:36:08.82 ID:rYHf65xq.net] >>949 それぞれ何かキーワードを決めて、ログ表示するときに絞り込めばいい。 958 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 14:52:01.94 ID:wN0qaZCY.net] >>949 それぞれブランチをつくればいいと思う 959 名前：デフォルトの名無しさん [2015/08/04(火) 15:01:54.07 ID:KT0L8boW.net] チェックアウトってなんすか？ ホテルとかで家に変えるときチェックアウトしますよね？ そうすると部屋空いてるから、だれでもチェックインできるようになるんですか？ 960 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 15:56:53.06 ID:jQzRldfC.net] >>950 今はそうやってる >>951 それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね 961 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 18:13:17.56 ID:rYHf65xq.net] >>953 > それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね bashだったら、git-prompt.shを使うといい。 プロンプトを [username@ dirname] (issue-2701-add-hoge-api *) $ みたいにできる。 ついでにgit-completion.bashもインストールすれば、gitコマンドやbranch名をTabで補完できるようになる。 962 名前：デフォルトの名無しさん mailto:sage [2015/08/04(火) 20:39:05.58 ID:LaebqzUe.net] >>949 普通に日本語でコメント書けばいい。 > ログをみるとき全部出てしまうのはうっとおしい ブランチに含まれるコミットが多すぎるってことさ。 いろんなプロジェクトのマージコミット見てみ。 マージコミットの内容＝ブランチの内容なわけだが、 ブランチに含まれるコミットは数個しか無い。 >>953 > それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね >>954がいっている通り。 それはさすがにgitを使いこなせてない。 gitというかシェルに近い話だが。 初心者のうちは、なにか使いにくいと思ったら 自分の使い方が間違ってるのではないかって 考えることが重要だよ。 963 名前：デフォルトの名無しさん mailto:あげ [2015/08/05(水) 16:11:14.67 ID:qTT2Q3HY.net] Git始めました 964 名前：デフォルトの名無しさん mailto:sage [2015/08/05(水) 22:03:19.51 ID:Y8QWrwSI.net] 冷えてるの？ 965 名前：デフォルトの名無しさん mailto:sage [2015/08/06(木) 12:24:17.98 ID:YnB06pEs.net] あったかいGit始めました 966 名前：デフォルトの名無しさん mailto:sage [2015/08/07(金) 21:38:28.11 ID:VjeH+b7c.net] SourceTreeは結構バグ多いんだけど 代替GUIでお勧めはある？ 967 名前：デフォルトの名無しさん mailto:sage [2015/08/07(金) 21:50:49.99 ID:TJyjY+1J.net] あまりgitを使いこなせてないからか標準のgitgui？gittk？で割と十分だと思ってるんだけど 皆さんはどのへんに不満があるのでしょう？ 968 名前：デフォルトの名無しさん mailto:sage [2015/08/07(金) 22:38:51.48 ID:zZgheHLR.net] SourceTree時々固まるけどいうほどバグあるか？ コミットとブランチ編集はGUIでやってrebaseはCLIでやってる 969 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 02:18:48.55 ID:hvTU1eUO.net] >>961 とくに目立つのは ・日本語入力がたまにできなくなる ・日本語がたまに文字化けする の2点かなぁ 970 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 19:03:43.84 ID:eLygs58n.net] ShiftJISとか使ってんの？ 971 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 21:12:25.04 ID:hvTU1eUO.net] ShiftJISとか使ってませんよ？ 972 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 21:21:49.39 ID:vBlQRCao.net] Windowsは全世界でShiftJISが使われているんだろう？ 973 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 23:20:35.51 ID:BQYw/0/m.net] テスト 974 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 23:27:16.33 ID:m5zrYZQl.net] ファイル名とかは後方互換性でそうなっちまうわな >>965 英語圏はとりあえず違うかな？ 975 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 23:32:51.12 ID:A+ZgS5ti.net] >>965 ASCIIがShiftJISのサブセットだと大体そんな感じかな？ 有名な円化するくらいで 976 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 23:33:39.68 ID:PKfIE09h.net] ﾃﾞﾓﾈ ﾀﾞｲｼﾞﾅｶｷﾞﾓ ｶｷﾞﾓ ｶｴｼﾀﾉ〜 　　　 ∧_∧ 　　　(*ﾟー^) 　　 ／つ￥ つ 　　｜*/;≡|@＼ 　　 ￣(/ Ｕ￣ ￣￣￣￣￣￣￣￣￣￣ ﾁｬｰﾝｯｯ　ｳｫｰｯ　ｼｨｰｰｯ `∧∧ ∧∧∧∧ ∧∧ (　　)　　)　 )　　) 977 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 00:06:42.83 ID:SZxZe4hf.net] >>965 SJISなわけはないがフランスやロシアや中国の人のソースもたまに化けてるの見る https://en.wikipedia.org/wiki/Windows_code_page 978 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 01:38:16.85 ID:un4R4gw1.net] なんか最近のニュースで MSのVisualStudio2015でシフトJISじゃコンパイル失敗するからなんか設定してねってあったぞ WindowsでもソースコードのデフォルトはもうUTF-8なんだよ 979 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 16:53:09.64 ID:zMNscprH.net] そりゃC#の話じゃないの 980 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 17:04:53.01 ID:un4R4gw1.net] べつにC#限定の話じゃないようだが ぐぐるとC#の話が一番上にでてくるがなｗ 981 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 17:21:44.28 ID:DsvXgH80.net] 2015だとC++もデフォルトUTF-8になったのか？ いちいち変更しなくて済むようになったんならありがたいが。 982 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 17:25:29.84 ID:doZuGkX/.net] >>974 たぶん2010あたりから 983 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 17:43:56.94 ID:zMNscprH.net] Win32でC++新規作成するとSJISだけど、これうちの環境のせいなのか？ 984 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 17:48:54.67 ID:TarQJqGz.net] >>975 Visual Studio 2013 Community ではシフト JIS ですけど？ 985 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 21:40:02.06 ID:MwH/TAN+.net] 大丈夫だ、2015でもCP932のままだ 986 名前：デフォルトの名無しさん [2015/08/10(月) 05:15:36.78 ID:joKVIITR.net] Windows10のcmd.exeまだchcp65001のバグ治らないな 987 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 08:39:31.31 ID:woEY2l+M.net] >>979 もうほとんどやる気ないでしょ この部分だけでいいからソース開示して有志に改造させて欲しいわ 988 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 09:29:36.92 ID:Y9npztmj.net] 同意 だけど git for windows だったかなんかについてくる UTF-8 対応の cmd.exe っぽいのは結構使える 989 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 09:37:10.95 ID:7mEm0oAX.net] 今どきCLIとか石器時代の生き残りかよ 990 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 10:58:28.36 ID:lE/gCziL.net] だがまあgitに限って言えば GUIだけでは心もとないのもたしか 991 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 15:32:34.36 ID:iHuYT/si.net] テキストベースは便利なんだよ 自動化とか簡単だし、それをgitで管理できるから 992 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 17:41:57.41 ID:24CTSkEb.net] CLIはデプロイツールと親和性が高い 993 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 18:43:19.26 ID:wnxGShdH.net] 自動化に関わるツールはCLIがないと困るよね 994 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 20:12:09.12 ID:Mkjl0645.net] git pullで新しい更新を取り入れた時に指定したシェルスクリプトを実行したいんですけど フックの名前を教えてください 995 名前：デフォルトの名無しさん mailto:sage [2015/08/10(月) 20:12:45.22 ID:Mkjl0645.net] 俺はGUIの見方がよく分かんないからCUIしか使ってないよ 996 名前：デフォルトの名無しさん mailto:sage [2015/08/11(火) 06:26:57.50 ID:/JNKK5gi.net] >>987 新しい更新がマージされたのを契機に処理をしたいなら post-merge になりそうだけど、 リモートからコミットがfetchされてそれがマージされたのかどうかは自分で判断しないといけないんじゃないかな 997 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

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

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