Git 12©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net
2015/03/23(月) 13:35:13.83ID:aBYp+bVsGit - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 11
http://peace.2ch.net/test/read.cgi/tech/1416195050/
0459デフォルトの名無しさん
2015/05/16(土) 23:14:20.75ID:waTp+O7jgitlabの話でよかったんだなｗ
自分もコメント消えるのが問題だったが、最近消えなくなったなーって
思うだけでどうなっているのかよくわからないから、ついでに動作を少し検証してみた。
* マージリクエスト(以降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が表示されている。
ここまでは消したりしてないので、ごく普通にコメントが表示されている。
当たり前ではあるんだけど変更した行以外にはコメントつけられないな。
たまに周りにも修正すべき所があってコメントしたくなるんだけど。
0460デフォルトの名無しさん
2015/05/16(土) 23:15:03.07ID:waTp+O7jつまり、コミット番号(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からたどり着けるようにリンクを張っておけば良い。
0461デフォルトの名無しさん
2015/05/16(土) 23:20:45.79ID:waTp+O7j昔から変わってないと思うんだけど、それはそれとして
MR自体が見やすくなっているので、バージョンをあげるのはありだと思う。
例えばgit push --forceした時とかにpushしたコミット番号が
MRに記録されるようになったのは最近の機能。
できれば最初のコミット番号もMRに記録されて欲しいんだが。
Dashboardとかから調べられるけどさ。
gitlabは昔（と言っても一年前程度）はいかにもgithubの
クローンってUIだったけど、UIが変わってgithubとは別の
同種のソフトって感じで良くなったと思うよ。
機能的にもgithubに全然劣ってないしね。
もちろんオープンソースでコミュニティ重視ならgithubになるんだけど、
クローズドならgitlabで十二分に使えると思う。
0462デフォルトの名無しさん
2015/05/17(日) 19:28:04.61ID:ImkX2Hg51
2
3
4
↓古い
1のコミットを3のコミットに含める事について。
これってコンフリクトを起こす可能性があるのであんまりやらないほうがいいと思うんです。
合体させるならコミットを飛ばさなず1,2,3を合体したほうがいい気がするんです。
ここの先輩方はよくやりますか？
0463デフォルトの名無しさん
2015/05/18(月) 02:18:29.93ID:/pjdhzEdお前には無理なら止めといた方がいいが。
0464デフォルトの名無しさん
2015/05/18(月) 08:12:32.67ID:ezOKhhiH「あまりやらないほうがいいと思う」のは前提として
「コンフリクトを起こす可能性がある」からだよね？
まず一つ。コンフリクトは起きても問題ない。直せばいいだけ
もう一つ。コミットが小さく分かれていれば、コンフリクトが起きる可能性は少なくなる。
この2点がある。
どうもコンフリクトを怖いもの。起きたら世界の破滅みたいに思っている人がいるみたいだけど
ぜんぜん違う。起きるのは当たり前のことだし、他人が作ったものならまだしも
自分が作っているものなら、どうすればいいかなんてすぐにわかる。
そしてコンフリクトが起きるのはなぜかという話。それはコードが単一責任原則を
満たしていないから簡単にいえば、修正すべきコードがあちこちに分散しており
ようするにコードが汚いから。
コンフリクトは起きたら直せばいいだけだが、
面倒くさいから、起きないほうが楽というのは確か
各コミット（そこでいう1, 2, 3, 4）がそれぞれ小さい修正になっており、
それぞれがちゃんと意味がある単位で分かれていれば、そうそうコンフリクトは起きない。
0465デフォルトの名無しさん
2015/05/18(月) 08:28:44.00ID:ezOKhhiHという質問の答は、含めるべきことであれば含める。
そうしないと逆にコンフリクトが多くなるから。
何故かと言うと、1と3をまとめたい＝意味がある単位で考えてまとめるべきこと。
単一責任の原則を満たしており、意味がある単位で小さいコミットというものは、
多くの場合同じ箇所の修正になる。「1と3は同じ箇所の修正」っていうことを覚えておいてね。
そして例えば新しくコードを書いている途中で、既存のバグが見つかったとする。
新しいコードはバグを直さなければ正しく動かない。
だから先にバグを修正するために、5というコミットが必要になったとする。
（どうでもいいが1〜4数値は新しい方を大きくしてくれｗ）
そうすると5のコミットの続きからに、1〜4をrebaseしなければならない。
その時に3でコンフリクトが発生すると3を直したあと1でもコンフリクトが起きるだろう。
なぜなら、同じ箇所を修正しているから。
さらにむずかしいのは、最終的には1が終わった形にしないといけないわけだけど
3のコンフリクトをどう解決するか？って問題がある。
3の時点で1が終わった形にするわけには行かないんだよ。
3で発生したコンフリクトを直したあとに、1の修正を行うわけだから。
どう直せばいいかわからないものが多数発生する。
これがコンフリクト怖い病になる原因だねｗ
だからコンフリクトが起きる頻度を少なくするためにも、
1. 各コミットは小さい修正にしておく
2. 意味的にまとめるべきコミットはまとめておく
これを徹底することで、最終的にコンフリクトが起きにくくなる。
0466デフォルトの名無しさん
2015/05/18(月) 09:10:31.18ID:ezOKhhiHコンフリクトっていうのは同じ場所の修正がかぶると
発生するっていうのを意識しておいた方がいい。
あたりまえだと思うけど、じゃあどうすればいいかまで考えているだろうか？
他人とのコンフリクトは、単純に同じ箇所を修正したときだが、
自分自身とのコンフリクト、rebaseでよく起きるね。（下手だと）
こっちもコンフリクトが起きる原因は同じ箇所の修正だからなんだ。
もし同じ箇所の修正がなければ、rebaseしてコミットの順番を
入れ替えたりしてもコンフリクトは発生しない。
じゃあ同じ箇所の修正はいつ発生するか？ それはこういうの
* Aという修正をコミットした
* Bという修正をした
* Aという修正にバグが見つかったので修正した
* Aに機能が足りなかったから追加した
* Aの変数名でタイポしていた
こういうのを放置したまま、作業し続けていざmasterにマージする段階で
コンフリクトが起きてrebaseしなきゃならないってなった場合に
多くのコンフリクトが発生して、大変なことになる。
こういうのは随時rebaseしておくことが重要。
バグとかタイポとかさっさとまとめておく。
* Aとい修正をコミットした
* Bという修正をコミットした
こういうふうコミットを意味がある単位で小さくまとめておけば、
コンフリクトの回数は減るし、直すのも単純になる。
0467デフォルトの名無しさん
2015/05/19(火) 08:43:08.91ID:ETXaESJa自分なら、普通は避けるな。
でも理由は、ソースの修正箇所がコンフリクトするからじゃないよ。
1->2->3の順にコミットして、1と3をまとめたら、2->1+3になるわけだよね？
このとき、2が1無しでも正しく動作するか分からないからね。
もし、2と1+3を別々のコミットとして履歴に残すなら、どっちのコミットでも
正しく動作することを担保したい。
でも、コミットをまとめるためだけに、（自動テスト環境があったとしても）
2だけのテストをまたやり直すのを避けたい。
だけどそれも、プロジェクトごとのgitの運用ルールによるかもしれない。
コンパイルエラーになるコミットがリモートリポジトリにあるのは構わないとか、
過去のコミットが動かなくなるのは構わないとかのルールになってるなら、
好きなようにまとめるかもしれない。
0468デフォルトの名無しさん
2015/05/19(火) 10:17:56.67ID:S02ugk9h0469デフォルトの名無しさん
2015/05/19(火) 11:07:38.39ID:0hZF5IeJ> このとき、2が1無しでも正しく動作するか分からないからね。
1+3のテストだけやればよくね？ 2がテストに通らなくても、
自動テストがあるならすぐにわかるし、最悪テストに通らないときだけやらなければいい。
もし自動テストがなければ、2がテストに通らなくても
「調べようがないので、通らないことがわからない=通っているのと一緒。」 ←重要
それにさ、コミットが多かったら、正しく動くことを担保するのは大変だよ。
* Aが正しく動くことを確認
* Bが正しく動くことを確認
* Cが正しく動くことを確認
* Dが正しく動くことを確認
というつもりだったが、たいていバグはあとから見つかるんで、
あとからAが正しく動いていなかった！と判明したらどうする？
* Aが正しく動かない
* Bが正しく動かない
* Cが正しく動かない
* Dが正しく動かない
* Eで修正
君は、どのコミットでも、正しく動くことを担保したいといったが
A〜Dは全部正しく動かないことが担保されたわけだｗ
EをAに混ぜ込めば直すことができるが、それをしないならば、A〜Dのコミットは正しく動かないままだよ。
A〜Dは正しく動かないが、でもその時はテストコードがなかったから分からないわけだよね。
それって、つまり「重要」って書いた所と同じ状態なんだが。
過去のコミットが動かないのは構わないというルールなら、そのまま放置でいいかもしれんが（笑）
0470デフォルトの名無しさん
2015/05/19(火) 12:47:36.82ID:0hZF5IeJコミットのやり方？
普通にgit addでコミット対象を選んで
git commitでコミットするだけだけど？
コミットの順番を入れ替える話？
それならgit rebase -iだよ。
0471デフォルトの名無しさん
2015/05/19(火) 14:21:12.63ID:oDPa6Z2Vバグの話じゃないでしょ
0472デフォルトの名無しさん
2015/05/19(火) 17:37:58.03ID:0hZF5IeJバグの話ではこうなるよね？
つまりこれは「正しく動かないがテストコードがないから自動テストには通る」
という状態をどう考えてるかって話なんだよ。
俺はそれは自動テストに通るってことでいいじゃないかって言っている。
これがいやなら、前のコミットに混ぜて修正するしか無いわけだよ。
で、俺は 前のコミットに混ぜても自動テストに通るなら
それでいいじゃないかとも言ってる。
ちなみに俺は特に大きな理由がない限り、テストケースも含めて
前のコミットに混ぜて、全てのコミットを正しく動くようにしている。
皮肉なことに>>467が言ってる
> どっちのコミットでも正しく動作することを担保したい。
を実践出来てるのはこのやり方なんだ。
0473デフォルトの名無しさん
2015/05/19(火) 17:38:54.11ID:0hZF5IeJ○（自動）テストコードも含めて
0474デフォルトの名無しさん
2015/05/19(火) 21:49:21.81ID:ez1Du3hqコンパイルと自動テストに通るかどうか、わざわざ確認するか？
ってことだな。
確認するなら、影響する各コミットでわざわざそれを確認するのは
面倒くさい、というデメリットが発生する。
確認しないなら、古いコミットは（コミットした当時は通ってたであろう）
コンパイルと自動テストはもう通らないかもしれない、というデメリットが
発生する。
そのデメリットを避けるために、「間をとばしたコミットまとめはしない」
のが>>467だね。
>>472が結局どうしたいのかについては知らない。
0475デフォルトの名無しさん
2015/05/19(火) 23:00:23.53ID:aRRI5SvPgit 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にまとまってしまいました
どうやるのか教えてください
0476デフォルトの名無しさん
2015/05/20(水) 00:37:31.29ID:NtQ54Cc0そんな全部なんていらんし、途中からでいいんだけど
どうしたらいいの？
0477デフォルトの名無しさん
2015/05/20(水) 01:04:01.37ID:jSvt41UGpick 07d5e6a a
fixup 5d295c0 c
pick f550031 b
エディタで順番を入れ替える。
0478デフォルトの名無しさん
2015/05/20(水) 01:50:27.49ID:TO++lAfhできました
これは便利ですね
これでログを今よりも綺麗に出来ました
0479デフォルトの名無しさん
2015/05/20(水) 09:25:54.36ID:v+0+7waM>>140
0480デフォルトの名無しさん
2015/05/20(水) 12:05:48.01ID:qzEPJuINあー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コミットが何十個にもなってるでしょ？それはコミットをまとめないからだよ。
それから一度に変更（マージ）する内容が多すぎだろうね。
これはもう仕事のやりかた、作業の進め方のレベルの話だね。
まともなレビューが行われているかどうか不安になるな。
まず自動テストをしているならば、その内容をテストしたのは明らかなわけで、
何をレビューするかというと書いてあるテストとコードが正しいか漏れがないかだよ。
人力テストをしてもらうんわけじゃない。
つまりコード見て理解できる程度の量でないといけない。それも短い時間でね。
修正内容がバラバラで、順番も修正箇所もごちゃまぜな大量のコミットを一個ずつ見るのは不可能だし
全部まとめて見ると一度に大量のコードを見ないといけなくなるから大変。
レビューアに負担をかけるようなコードはだめだよ。
あと一連の機能を全部まとめてレビューしてもらってるでしょ？
細かい機能毎にわけないとだめだよ。リファクタリングならリファクタリングだけでマージ
モジュールの追加なら（テストコードも含めて）モジュールだけのマージ
それらをいっぺんにレビューするよりも、分けたほうがレビューアの負担は減るのはわかるよね？
君はいっぺんに全部やろうとするから、コミットまとめたり入れ替えた時の時の再テストが
大変とかいう話になってるが、俺の場合は、細かく分けてマージ可能な最小単位に分割するから、
一つの作業ブランチに含まれるコミットは数個しかない。
君、悪循環に陥ってるよ。コミットをまとめないから、マージできる単位に分割できない。
分割できないから一つのブランチの内容が多くのコミットになる。コミットが多いから並び替えたら
コンパイル・テストが通るか不安になる。面倒くさい。だからコミットをまとめないって。
0481デフォルトの名無しさん
2015/05/20(水) 12:10:17.30ID:qzEPJuIN一連の機能を作っている時にリファクタリングやモジュールの追加は
絶対に発生する。ミスも発生する。
一連の機能をいっぺんに全部レビューするのはすごく大変だから
小さく分けた方がいい。
ならば一連の機能をリファクタリングだけのブランチ
機能追加だけのブランチ等にわけて、出来た所からマージした方がいいが、
コミットを入れ替えたりまとめたりしないで、どうやってそれを実現するの？
0482デフォルトの名無しさん
2015/05/20(水) 16:22:35.29ID:NtQ54Cc0を繰り返すならコミット量は自然に増えるよね
0483デフォルトの名無しさん
2015/05/20(水) 16:38:52.05ID:qzEPJuINこんな感じにすればいいよ。別にコミットは実際の作業順に合わせる要はない。
* ちょっと書く
* テスト
* ちょっと書く
* テスト
↓ 並び替え（これが失敗することはまずない）
* ちょっと書く
* ちょっと書く
* テスト
* テスト
↓ まとめる（これが失敗することもまずない）
* ちょっと書く
* テスト
この作業を随時やっていく。
・・・つづく
0484483のつづき
2015/05/20(水) 16:47:02.59ID:qzEPJuINそれは内容によって変わる。
コミットを（まとめるべき内容なら）まとめながら作業するのは一緒だが
リファクタリングの時は「ちょっと書く」と「テスト」はまとめない。
* テスト
* ちょっと書く（リファクタリング）
最終的にこうなる。なぜならリファクタリングしても動作は変わらないはずなので、
コードを書いた前と後で全く同じテストが通るから。
それを確認するためにも、リファクタリング前に（テストが不足している場合は）
テストを書いておき、そしてリファクタリングを行う。
またコミットを入れ替えることを前提にすると「後からテスト駆動」が実現できる。
理想としてはテストを先にやるのがテスト駆動なのだが、現実には後からミスが見つかったりして
コードを書いてからテストを追加することが多い。
実際の作業ではコードを書いてからテストを書いたとしても、そしてそれらが
コード書いてテスト、コード書いてテストって繰り返していたとしても、
テストだけまとめて1つ目のコミット。リファクタリングして2つ目のコミットの形にできる。
これでレビューする人は、問題なくリファクタリングできたことを確認できるわけ。
もちろん仕様変更や機能追加などであれば、テストコードと修正を
分ける意味が無いし、一つにするべきなのでまとめる。
0485デフォルトの名無しさん
2015/05/20(水) 16:59:43.68ID:NtQ54Cc0ローカルでのコミットはどんどん細かく、プッシュの粒度はテスト通ってから
という方針でやってたんだけど、gitはそういうのに向かないんですね
0486デフォルトの名無しさん
2015/05/20(水) 17:01:43.80ID:NtQ54Cc0じゃあ俺のgitの使い方は間違っているのか
0487デフォルトの名無しさん
2015/05/20(水) 17:03:34.98ID:NtQ54Cc0かつ テスト用ブランチでどんどこ適当なコードを書きなぐれるのか？
みんなそこまでやってたの？ すげーな
0488デフォルトの名無しさん
2015/05/20(水) 17:07:28.79ID:qzEPJuINなんで？ 意味がある単位で小さくすればいいよ。
でも意味がないのに分割する必要はない。
（ローカルでの作業中に）
例えば、関数名これでいいかな・・・コミット
やっぱり、関数名こっちにしよう・・・コミット
いやいや、やっぱり戻そう・・・コミット
ってタイポしてたよ修正・・・コミット
これってコミットを細かく分けたかったわけじゃない。
作業上の都合でコミットがわかれてしまっただけ。
こういう意味が無いコミットはまとめるべき。もちろん
別々の修正であれば、どんどん細かく分けた方がいい。
細かく分けておくと並び替えや分離がしやすくなるよ。
修正しているうちにコミットがたくさんになって、これ一度に
レビューするの無理だろと思ったら、抜き出して別のブランチにするとかね。
でももし意味が無いコミットに分かれていたら、逆に抜き出すの難しくなるからね。
重要なのは、意味がある単位で小さいコミットに分けておくこと。分ける意味が無いものはまとめること。
これがコミットをうまく管理するコツだよ。
0489デフォルトの名無しさん
2015/05/20(水) 17:15:41.65ID:qzEPJuIN> みんなそこまでやってたの？ すげーな
git歴は2年ぐらいかな？
最初は当然できなかったよｗ
ただレビュー可能なコードの重要性はわかっていたから、
subversion使っている時、こんな行き当たりばったりの修正履歴じゃ
レビューできないだろっていう認識はあった。
（計画的にやれって思うかもしれないが、ミスや漏れどうしても発生する）
gitを使ってからはどうすればレビューしやすくなるか？を
考えてコミットを作るようにしていたよ。
（ちなみにどちらかと言うと俺はレビュー依頼する側じゃなてレビューする方だけどね）
0490デフォルトの名無しさん
2015/05/20(水) 17:18:24.50ID:zo5n24wvそのケースで実際にコンフリクトが発生する場合は
2 の粒度がでかすぎるってのがよくあるパターンなので、
2 を分割して 4←3+2a+1←2b という形になるようにしている
0491デフォルトの名無しさん
2015/05/20(水) 21:06:38.40ID:vVwXnjIW>あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
>たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。
たぶん>>480の場合は、例えば分野が小さなWebサイトの開発とかで、
そもそもの開発規模や自動テストの規模が少ないとか、昔のコミットや
昔の挙動を残しておいても問題調査の役に立つことが少ないとか、そういう
特徴があるんだろう。
0492デフォルトの名無しさん
2015/05/20(水) 22:00:00.11ID:qzEPJuIN数秒で終わらないのが困るのなら、大量にあるコミットが
ある状態で、rebaseとかどうするのさ？
数秒で終わらないなら、逆にコミット減らすべきだろ。
矛盾してるぞｗ
あと中間ファイルが残ってるはずだから、
適切にソースコードが分割されて依存関係が少ないなら
一つ一つのコミットの修正が僅かなはずなので
コンパイルにそんなに時間がかかるはずがない。
0493デフォルトの名無しさん
2015/05/20(水) 22:05:10.63ID:qzEPJuIN> 問題調査の役に立つことが少ないとか
これも逆に不要なコミットは消すべきだよね。
何か勘違いしてる（他の人にされそう）だから
念の為に言っておくけど、俺が言ってるのは、
本来一つであるべきコミットは一つにするって話で
何でもかんでもまとめろって話じゃない。
だから当然、昔のコミットは残ってる。
調査に使うよ。git bisectで二分探索で。
でだ、この時大量にコミットがあるとその分探索の回数増えるわけで、
コンパイルと自動テストが数秒で終わらないとしたら大変だよなぁ？
問題調査のためにも無駄なコミット減らしたほうがいいって結論になるぜ？
0494デフォルトの名無しさん
2015/05/20(水) 22:19:59.27ID:MjY1jVeQ＞数秒で終わらないのが困るのなら、大量にあるコミットが
＞ある状態で、rebaseとかどうするのさ？
だから、「間を飛ばしたコミットまとめをしない」って言ってるんじゃないのか？
A→B→C→Dの順にコミットされてるなら、連続したBCやBCDをまとめるのは
コンパイルや自動テストに問題ないから。
0495デフォルトの名無しさん
2015/05/20(水) 22:30:23.27ID:qzEPJuINrebaseって二つの複数の意味があるから気をつけないといけないなｗ
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も禁止してるのかな？
なんか下手なコミットのせいで、時間が掛かるから便利なものを
封印せざるを得ない状態を作っているようにしか見えない。
0496デフォルトの名無しさん
2015/05/20(水) 22:49:40.28ID:MjY1jVeQなんでfeatureブランチの各コミットを直接masterにつなごうとするのかがよく分からない
このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
0497デフォルトの名無しさん
2015/05/20(水) 22:50:55.88ID:qzEPJuINと思った理由もかいておく。
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の機能を最大限使うことが出来るわけよ。
ってもう何回も言ってるねｗ 毎回長文でｗ
0498デフォルトの名無しさん
2015/05/20(水) 22:54:58.15ID:qzEPJuIN> その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが
その場合ってどの場合？
一人で開発してるんじゃないんだよ。
自分が開発をし始めた時からコードは変わっているから
これをmaster(3)になんか出来ない。
他人の仕事を消してしまうじゃないか。
他人の仕事と自分の仕事を合わせてないと行けないんだよ。
コンフリクトが起きようと起きまいとね。
コミットが沢山あればあるだけ、全てのコミットが
正しく動くか再テストをする必要がある。
0499デフォルトの名無しさん
2015/05/20(水) 22:58:20.56ID:MjY1jVeQ＞master(1) → master(2)
＞ ＼AC→B→D
これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
これが許されるチームなら、各メンバーが自由にコミットをまとめても、たしかに問題ないな。
0500デフォルトの名無しさん
2015/05/20(水) 23:01:15.60ID:qzEPJuIN> このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
別ブランチにできるかどうかは内容次第だね。
コミットとしては一つ一つ取り込めたとしても
機能としては一つ一つでは完成しないこともある。
で、俺は一連の作業中に、先にマージ可能なものができたら、
別ブランチに抜き取って先にマージした方がいいとも書いた。
そのためにも、コミットをそのまま放置するのではなく
関連があるものはまとめていくようにって言ってるんだよ。
関連あるコミットがバラバラだったら、別のブランチに抜き出すのは大変だからね。
それもあって、そのケースでAとCをまとめたんだよ。
つまり最初のAとCが関係ある内容ならまとめますか？の質問の
答えはまとめた方がいいってこと。
で、これやるとコンフリクトが〜とかいって、まとめない方がいい
並び替えないほうがいいって言ってる人がいるわけよ。
0501デフォルトの名無しさん
2015/05/20(水) 23:05:27.02ID:qzEPJuIN> これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
> 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
話がループしているがｗ
rebase後にACとBのコンパイルと自動テストをスレばいいだけだろう？
そんなのすぐに終わる。たった2回（ACとB）じゃないか？
すぐに終わらないのは、コミットがたくさんあるからだよ。
そりゃコミットが10個も20個もあれば、10回20回もコンパイルと自動テストをしなきゃならんだろうさ。
コミットがたくさんあるために、rebaseを許さない状況になってしまっている。
rebaseってさ、gitの基本じゃん？
チュートリアルの最初のほうで出てくる作業だよ。
許されるも何もこれは普通にやるべきことだよ。
ね？ 下手なコミットのせいで普通にやることがやれない状況になってしまっている。
コミットがたくさんあるために、rebase（master(2)への付け替え）を
封印してしまってるでしょ？
0502デフォルトの名無しさん
2015/05/20(水) 23:19:51.82ID:MjY1jVeQAとCをまとめますか？の回答には「そう思う」だが、
AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。
AとBとDはブランチを分けるな。
もしブランチを分けとけば、レビュー前？Push前？にAのバグに気付いても、AとCのコミットは連続してるだろうからな。
逆に、レビュー後？Push後？に問題に気付いたなら、自分の負けを認めてバグ修正のコミットを残す。
一方、後になって「コミットが連続しない、AとBとDをブランチに分けておけば良かった〜」なんてなるようなら、自分の腕のなさを呪ってブランチを切りなおす？？？かな。
0503デフォルトの名無しさん
2015/05/20(水) 23:21:45.30ID:MjY1jVeQ＞そんなのすぐに終わる。たった2回（ACとB）じゃないか？
「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
0504デフォルトの名無しさん
2015/05/20(水) 23:28:53.73ID:qzEPJuIN> AとBとDはブランチを分けるな。
分けたいなら後で分ければよくね？
作業用ブランチなんだからそれはどっちでもいい話だと思うが。
AとBとDがお互い前のコミットに依存している場合、
最初にブランチを分けておくと、ごちゃごちゃしてくると思うが。
Aを作ったはいいけれど本当にこれでいいかは、そのAを使う
Bを作らないとはっきりしないことだってあるしさ。
残念ながら人間はミスを犯すんで、どうしても後からバグを発見する。
後から修正をするものだよ。
一つのブランチで作業しておいて、ある程度納得がいったら別ブランチに
抜き出せばいいと思うけど。コミットが整理されていれば簡単な作業だし。
それとレビューは間違いを見つけるものだから、修正が入るのはあたりまえだよ。
レビュー中はまだ作業中段階。作業中のごみコミットを残したままマージする必要はないよ。
一連のレビューが終わったら整理すればいいだけの話。整理し終わってそこで完成。
0505デフォルトの名無しさん
2015/05/20(水) 23:30:22.13ID:qzEPJuIN> 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
そんなのすぐに終わらないって前提がおかしいんだよ。
だって開発中に何度もコミットしてるじゃん？
その段階でコンパイルと自動テストしてるじゃん？
コミットがたくさんあるのなら、その分だけやってるわけじゃん
開発中にすぐに終わらない作業を何回もやってるのか？
まずそれを解決した方がいいぞｗ
0506デフォルトの名無しさん
2015/05/20(水) 23:35:21.24ID:qzEPJuINなぜなら、コミットの前後で修正されるファイルは少しだから
該当ファイル以外のオブジェクトファイルはそのまま使えるわけで
差分のみのコンパイルしかしないはずだから。
そして自動テストは作業中は関連のあるところだけテストすれば良い。
で、最終段階（もう変更がないと思った時点）で全部やればいいんだよ。
最後にブランチ内の全コミットをテストするのか！という疑問に対しては
だからぁ、コミット数が多いから大変なんじゃねぇかそれ。という話。
関連あるものはまとめろ。先にマージできるのは別ブランチに分けろ。
コミットは小さく分けろ。だが無駄なコミットはまとめろ。
0507デフォルトの名無しさん
2015/05/20(水) 23:39:45.06ID:MjY1jVeQ自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。
例えばWebサイトの開発とかでは、そういうのほとんどないだろうし、ぶっちゃけ過去より今が大事なのかもしれない。
（過去の状態が「Webサイトの純然たる作りかけ」とかだったら、そのスナップショットを完全に残すことに価値はないだろうし）
だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
その方が、短期的な効率は出るだろうしさ。
0508デフォルトの名無しさん
2015/05/20(水) 23:56:43.98ID:/feEo/hsgitのブランチって使いづらくね？
0509デフォルトの名無しさん
2015/05/21(木) 00:28:17.62ID:0lqSGmSkfix_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ブランチを指定したらいいんでしょうか？
実践で誰かと一緒に開発したことがないので怖くてどうしたらいいのかわかりません
ご教示おねぎあします
0510デフォルトの名無しさん
2015/05/21(木) 00:41:14.37ID:/NlBmKMh俺もそう思ってた
でもわかった、gitのブランチにはブランチモデルが必要なんだ
自由になんでも出来すぎるからブランチモデルで制約を付ける
「A successful Git branching model」てのを見つけて、
git-flowを使うようになってからだいぶまとまりが出来てきた
その後で他にもいくつかブランチモデルがあることも知った
今はブロジェクトの初めに
git-flowを使って「A successful Git branching model」をベースにやります。変更点はこれこれ。
みたいに宣言することにしてる。
だからお願い。VisualStudioにもgit-flow付けて、Microsoftさん。
0511デフォルトの名無しさん
2015/05/21(木) 11:22:31.08ID:PvdFF4ayなんか引っかかるねｗ
短期的じゃなくて長期的な効率が出てる。
ヘッダを書き換えれば多くのソースファイルに影響する話なら知ってる。
そうならないためのやり方があるのは知ってるかい？
ビルド依存を回避するような作り方をするんだよ。
あんたのやり方だと普段の開発から時間かかってしょうがないでしょ？
ちょっと修正するたびにビルドに多く時間がかかってるはずだよね。
それはもはやgitとは関係ない話だよ。
それからウェブの開発ではないって思ってるかもしれないけど、
今はウェブの開発でもビルド行う。
> だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
> その方が、短期的な効率は出るだろうしさ。
なんか、俺が知らないと思ってそういうこと言っているような雰囲気だが
俺知ってるからね？ ウェブだけじゃなくてビルドが必要な開発も。
0512デフォルトの名無しさん
2015/05/21(木) 11:33:41.78ID:PvdFF4ay最近の若いもんは〜みたいな発言になってるからだ。
言葉の節々に、ウェブ開発をしてるもんは〜とか
テストしてるわけがないはずだ〜とか
過去はどうでもいいと思ってるはずだ〜とか
まともな自分の想像ばかり言ってる。
0513デフォルトの名無しさん
2015/05/21(木) 11:34:23.74ID:PvdFF4ay× まともな自分の想像ばかり言ってる。
○ 的はずれな自分の想像ばかり言ってる。
0514デフォルトの名無しさん
2015/05/21(木) 11:55:03.21ID:PvdFF4ayこれに関してはだから何なんだ？といいたい。
（ごみ）コミットがたくさんあって、コミット毎に全部
アプリケーションの再起動を行っているのか？
だとしたら、テスト効率が極めて悪い。
10個のコミットがあって、それぞれのテストに
1時間かかるとしたら10時間じゃないか？
俺ならまずおおむね十分だと思われるテストだけを行って
コミットを減らしてからテストするね。5個に減らせば5時間で済む。
コミットしてテストした後で、さっきのコミットに混ぜるべきコードをコミットしてテストしたら
さっきテストした時間は無駄になるじゃないか。
後から修正が入るかもしれないような不安定な所のテストに時間はかけない。もう修正は入らないなって
思った時にちゃんとテストをする。コミットを減らしてテストしたらテスト時間も減る。
git以前にテストのやり方そのものを見なおしたほうがいいよ。
効率を考えないで流れ作業をこなしているかのような開発になってる。
0515デフォルトの名無しさん
2015/05/21(木) 12:05:21.48ID:PvdFF4ay> ブランチってほんとにみんな使ってる？
> gitのブランチって使いづらくね？
一人で開発してるとか？
使いづらいかどうかは置いといて
使わないと、複数人で並行して開発できないよ。
使いづらいと思ったことはないな。
最初の頃は苦労したけど、それはgitのブランチのせいではなくて
自分の技術力不足だってわかっていたし。
作者のリーナスがどうしても必要だって思って作った道具であり
gitの機能も必要だと思っているからこそ作ってるわけだしさ。
もっといい案があるというなら別だけど、わかってないのに
リーナスが作ったものに、ケチつけるなんてだいそれたことなんか出来んってｗ
わかった今ならよく出来てるって思うよ。
0516デフォルトの名無しさん
2015/05/21(木) 22:28:03.52ID:fr6zPWaF0517デフォルトの名無しさん
2015/05/22(金) 00:01:21.71ID:6DaqA/5uリーナスだろうと関係ないよ
リーナスには使いやすいものでも
俺には使いにくいってのは普通にあるよ
0518デフォルトの名無しさん
2015/05/22(金) 22:43:05.39ID:SSdLqWaE俺は一人開発だけど、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 管理している。
>>508 gitのブランチって使いづらくね？
Time stamp が checkout 時刻に強制変更されてしまうのが使いにくいと感ずる。make
compile 時の便利さは分かるが、ファイルの time stamp 自体は重要な属性だから。俺
が git を作ったならば、time stamp を commit 時の時刻にするオプションを絶対設け
ていた。
実際には commit 時刻に変更する script を書いてあるけれど、殆ど使っていないの実
情だ。その script が必要になるのは master 側だけだから。そして その master 側で
push するときには、time stamp など構っていれらない状態が殆どだという実情なのが
情けない。
0519デフォルトの名無しさん
2015/05/23(土) 16:05:57.79ID:4OfmjrZC途中経過の整合性が合わなくなるのが許されたり、
途中経過の整合性を合わせるためのテストやり直しが許されることがあるんだな
pushした修正がバグってたからって、pushしたもんをリベースで打ち消すのはご法度と思っていたが
プロジェクトの大きさによってはそれもあり得るということか
0520デフォルトの名無しさん
2015/05/23(土) 17:21:41.69ID:x743ZDZ30521デフォルトの名無しさん
2015/05/23(土) 17:24:16.06ID:x743ZDZ3push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。
0522デフォルトの名無しさん
2015/05/24(日) 00:38:55.87ID:NuukhrjTサブプロジェクトどころか、一人プロジェクトだな
0523デフォルトの名無しさん
2015/05/24(日) 10:38:28.38ID:GI5iGoR+gitだと特に、ブランチの運用によって前提が大きく変わる。
GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、
それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。
だからpushしたブランチをrebaseしてもまったく問題ない。
むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい
0524デフォルトの名無しさん
2015/05/24(日) 11:16:37.86ID:VWanxcqXん〜と、前提が大ブランチになってるとそうかもしれないけど
Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから
得意技を積極的に使った方がお得な気がするな
うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた
その代わり、細かくコミットしろ、作業単位でブランチを分けろ
って、半年くらいは口うるさく言い続ける必要があったけどね
レビューの時にコミットツリー図を見ながら
ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか
ややこしいコンフリクトが生じた時に
どういう手順ならマージが簡単だったかとか
具体的に教えたり、みんなで考えたりした
新しい文化を根付かせるのは大変だよ、いつでもさ
0525デフォルトの名無しさん
2015/05/24(日) 14:14:44.04ID:J9ZjzLe3branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
に push するの？
レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
0526デフォルトの名無しさん
2015/05/24(日) 15:41:15.45ID:1k2HbjOC0527デフォルトの名無しさん
2015/05/24(日) 19:35:16.30ID:LHzJ6dIN今コミットしたログの後にそのリモートのログが来てしまいました
git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません
git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません
これってどうしたらいいんでしょうか？
0528デフォルトの名無しさん
2015/05/24(日) 19:41:30.07ID:Ewhf1zLwとなると、やはり 本体はSVNで、ローカルはgitで
別に管理したほうが全体が幸せになりそうだな
0529デフォルトの名無しさん
2015/05/24(日) 19:50:34.06ID:Jl9gFOkM共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな
0530デフォルトの名無しさん
2015/05/24(日) 20:03:35.12ID:Jl9gFOkMこの人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ
（それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう
0531デフォルトの名無しさん
2015/05/24(日) 21:34:38.73ID:VWanxcqXそれはいい解の一つだと思う。特に移行期には。
うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。
でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。
当時の対象プロジェクトがちょうど区切り良く、
過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、
フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。
最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど
結局馴染んでくればgitの方が扱いやすくなってきたよ。
しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。
（でも日本語変だよマイクロソフトのgit）
0532デフォルトの名無しさん
2015/05/24(日) 22:05:23.23ID:VWanxcqXおれ>>524な
「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、
俺がgit使ってる（使わせてる）理由の一番大きい所は
「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。
俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。
レビューもそのままで特に問題は無かったな。
でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
特に問題だったのは（svn使っていた頃の話ね）
何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。
svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で
みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。
ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。
そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。
今は「マージ操作間違えても俺が直してやる。
安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。
これだけでも後から意図を読み取るのは随分楽になったよ。
0533デフォルトの名無しさん
2015/05/24(日) 22:19:55.92ID:mdHWC0Am一つのブランチに押しこんでるからじゃないの
機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし
>>529
閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう
>>527
リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ
次から最初からブランチ切っとけばこんなことで困らん
0534デフォルトの名無しさん
2015/05/25(月) 03:10:39.76ID:WhsXE+Ib個人でブランチ作ってコミットしたあと、どうすればいいの？
そのブランチを本家に取り込ませるの？
0535デフォルトの名無しさん
2015/05/25(月) 05:59:36.31ID:/VFybrtgこれ大事よね
master に
0536デフォルトの名無しさん
2015/05/25(月) 06:01:10.35ID:/VFybrtg> でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
これ大事よね
master に wip と fix typo が積み重なってた時は流石に萎えたけど
0537デフォルトの名無しさん
2015/05/25(月) 08:14:58.07ID:y6DNlXTS＞master に wip と fix typo が積み重なってた時は流石に萎えたけど
そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう
0538523
2015/05/25(月) 09:19:23.83ID:E69UDjHE> >>523 だからpushしたブランチをrebaseしてもまったく問題ない。
>
> branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
> に push するの？
>
> レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。
典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する
0539デフォルトの名無しさん
2015/05/25(月) 13:36:42.28ID:XuKAmWn9まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
0540デフォルトの名無しさん
2015/05/25(月) 13:49:29.09ID:XuKAmWn9あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い
検索すりゃ方法わかると思うので調べてみてくれ
0541デフォルトの名無しさん
2015/05/25(月) 22:51:38.00ID:o/eCAQPj書き換え前のコミットををベースにしている人への配慮が必要そうだな
各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース
してください」って頼んで回れる環境が必要だ
0542212
2015/05/25(月) 23:42:12.33ID:fVXVPz7Eアンインストール作業が苦痛なんですよ
makeだけでアンインストールさせてくださいよ
0543538
2015/05/26(火) 00:30:58.55ID:VHuDuKFu> 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、
> まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。
これが GitHub flow な。
元が「 >>522 Pushしたブランチは書き換えてはならん」への反論だから、
そうでない運用もごく一般的、という主張をしたということ。
0544デフォルトの名無しさん
2015/05/26(火) 08:35:26.55ID:n+9g7Zguこれじゃ>>522への反論になってないっていうか、>>522が言ってることそのままだな
0545デフォルトの名無しさん
2015/05/26(火) 17:27:09.33ID:sKFLbSMMそうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。
0546デフォルトの名無しさん
2015/05/26(火) 17:39:03.82ID:sKFLbSMM個人用ブランチは作成者だけが見るわけじゃないから>>522とは違うな。
>>522は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？
単に極論言って煽ってるだけかもしれないけどね。
0547デフォルトの名無しさん
2015/05/26(火) 18:06:24.50ID:2IsijlAj規約任せかツールかスクリプトか
0548デフォルトの名無しさん
2015/05/26(火) 18:23:29.30ID:O0gIeBts0549デフォルトの名無しさん
2015/05/26(火) 20:10:30.68ID:qT5tL8rR一回オプション総ざらいしてみよう
0550デフォルトの名無しさん
2015/05/26(火) 22:07:42.46ID:1ouiCH4Fで、>>519が言ってる「プロジェクトの規模が小さい場合には
それができる」って話につながってくるのか…。
0551デフォルトの名無しさん
2015/05/26(火) 23:55:53.54ID:2IsijlAjそれブランチごとじゃなくて一律だからアクセス制限にはならないぞ
0552デフォルトの名無しさん
2015/05/27(水) 12:17:18.05ID:98FdFg1Vhttps://github.com/git/git/releases/tag/v2.4.2
0553デフォルトの名無しさん
2015/05/31(日) 20:55:03.14ID:2hiQrePQa.txtをHEAD@{12}のa.txtの内容にしたいんです
git reset HEAD@{12} a.txtじゃ戻りませんでした
0554デフォルトの名無しさん
2015/05/31(日) 21:23:55.63ID:q0XD6tk+0555デフォルトの名無しさん
2015/06/01(月) 22:34:02.79ID:6w2KJtLOgit add -A
このaddを取り消したいんですがgit reset HEADをやると
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
ってでます
git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？
0556デフォルトの名無しさん
2015/06/01(月) 22:37:39.31ID:wXX1PCBE0557デフォルトの名無しさん
2015/06/01(月) 22:37:41.39ID:60FC1uF10558デフォルトの名無しさん
2015/06/01(月) 22:43:38.24ID:wXX1PCBEぐぐると git rm --cached が使えるみたいだな
■ このスレッドは過去ログ倉庫に格納されています