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/ 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で自分で直接順番操作する必要は無い 検索すりゃ方法わかると思うので調べてみてくれ

---

---

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

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