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/
0409デフォルトの名無しさん
2015/05/07(木) 08:48:51.64ID:NXZBxN2S図星なんだな
0410デフォルトの名無しさん
2015/05/07(木) 09:28:18.61ID:SJ9cQ9MA変なダメージ入るわ
0411デフォルトの名無しさん
2015/05/07(木) 10:32:48.57ID:3s/cPLTB個人同士で開発するときにはgit超便利だけど
0412デフォルトの名無しさん
2015/05/07(木) 18:23:51.20ID:/fyjA82q俺は、総務にバージョン管理を、役員にMSプロジェクトを、それなりに真剣に薦めた事があったが、何も実行されなかった。
0413デフォルトの名無しさん
2015/05/07(木) 21:06:06.49ID:K4zbhPtLどのレスに反論しろって言ってるんだ？
0414デフォルトの名無しさん
2015/05/07(木) 23:49:15.84ID:NXZBxN2Sレスするなら反論しろってこと
>>403、>>404、>>408、あたりだね。
レスしてるってことは、何か言いたいことがあるってこと。
でも、その言いたいことが何も書いてない。
「どのレスに対する反論しろ」っていう話じゃなくて
レスするなら、自分の意見を書きなさいってこと。
0415デフォルトの名無しさん
2015/05/07(木) 23:50:08.72ID:NXZBxN2S賛成でもいいよ。
どちらにしろ、自分の意見が書いていないレスは
ゴミ同然だろう？
0416デフォルトの名無しさん
2015/05/08(金) 00:00:17.12ID:ZHeXF73S0417デフォルトの名無しさん
2015/05/08(金) 00:05:38.96ID:SsabnSp5言いたいことは、「お前はマヌケだな」ってことじゃないのか？ｗ
0418デフォルトの名無しさん
2015/05/08(金) 00:24:24.90ID:k44MRK8xそういう話をしているの。
0419デフォルトの名無しさん
2015/05/08(金) 00:36:25.10ID:SsabnSp50420デフォルトの名無しさん
2015/05/08(金) 00:54:02.88ID:k44MRK8xカッコつきで引用してみて。
0421デフォルトの名無しさん
2015/05/08(金) 00:56:53.00ID:P0RHYnr30422デフォルトの名無しさん
2015/05/08(金) 01:02:15.84ID:SsabnSp50423デフォルトの名無しさん
2015/05/08(金) 01:04:13.32ID:k44MRK8x何も言い返してこないのね。
最近こんな奴が多いね。
ま、言い返してこないなら、
願ったり叶ったりだけど。
じゃ、次。
0424デフォルトの名無しさん
2015/05/08(金) 01:04:34.82ID:ZHeXF73S0425デフォルトの名無しさん
2015/05/08(金) 01:10:04.42ID:k44MRK8x幼稚じゃなければちゃんと会話のキャッチボールができるはず。
0426デフォルトの名無しさん
2015/05/08(金) 01:11:40.05ID:dtfwKzs4excelのブックやあるいはVBなどのプロジェクトをフォルダ単位で…とかって出来るんですか？
ソースコード管理というとなんかテキストで保存みたいに聞えるんですが
バージョン管理触ったことがないんで、ちょっとお聞きしたいです
0427デフォルトの名無しさん
2015/05/08(金) 01:24:17.86ID:k44MRK8x取り出す方法（つまりdiff）ができないとだめ。
excelはそれが出来ないので無理。（正確に言うと意味が無い）
VBは一部にバイナリデータがあったと思うが、大部分はテキストなので可能。
（バイナリデータは保存することしかできないが）
勘違いしてはいけないのは、バージョン管理ツールは
バージョンを管理するものであって、
バックアップをするためのものじゃないってこと。
バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、
その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。
特殊な形式のバイナリが標準化されれば、バージョン管理できるかもしれないが
現時点ではテキストファイルしかバージョン管理できない。
excelなんかはバージョン管理（差分を抜き出すなど）する意味が無いので
別のバックアップツールを使った方がいい。
0428デフォルトの名無しさん
2015/05/08(金) 01:27:36.31ID:dtfwKzs40429デフォルトの名無しさん
2015/05/08(金) 02:06:08.07ID:ZHeXF73Sそれでも使うのは構成管理用か管理上ソースと不可分であるときくらい
事務用でも月次年次確定データや契約書決裁書等重要書類が紛失変更されないようロックするには都合がいい
バックアップファイルの管理とバックアップツールの保守が不要になる
タイムマシンしたいなら無駄無駄無駄普通にバックアップソフト使え
0430デフォルトの名無しさん
2015/05/08(金) 07:14:07.27ID:IAWQ0LFr> バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、
> その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。
幼稚なオレオレ定義乙
>>426
単純に最新版管理したいとか、たまに過去バージョンを取り出したりしたいだけなら Subversion の方がいい
Excel ってことはたぶん Windows だろうから TortoiseSVN インストールすればほぼ GUI で使えるし
詳しく知りたいなら続きはこちらで
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
0431デフォルトの名無しさん
2015/05/08(金) 09:22:21.26ID:samEA3DJ0432デフォルトの名無しさん
2015/05/08(金) 09:44:23.49ID:SsabnSp5＞幼稚な奴がいるんでしょ？
それがお前だな
0433デフォルトの名無しさん
2015/05/08(金) 11:34:00.00ID:Yhmm5THUTIME MACHINE はよく知らんからわからんけど Windows バックアップとかとは別物
一時間の間に 10回変更したら 10回バックアップとる訳じゃないでしょ
0434デフォルトの名無しさん
2015/05/08(金) 11:41:31.10ID:samEA3DJバックアップだって自分でトリガひける
0435デフォルトの名無しさん
2015/05/08(金) 12:19:48.40ID:Yhmm5THU0436デフォルトの名無しさん
2015/05/08(金) 12:55:19.05ID:SsabnSp50437デフォルトの名無しさん
2015/05/08(金) 19:41:28.50ID:dtfwKzs4426です。Subversionってのを調べてみます。情報多謝m(_ _)m
0438デフォルトの名無しさん
2015/05/08(金) 20:05:19.99ID:9kJl+Khzこまかくpushするほうがよい
たとえば足し算の結果を表す機能と引き算の結果を表す機能を作るとしたら２つのコミットを作れば良い
この２つを１つのログにまとめるべきではないのだ
何でもかんでも１つにまとめるのがかっこいいという間違った思想を持った人間がいるので困った。
0439デフォルトの名無しさん
2015/05/08(金) 20:18:03.21ID:ZHeXF73Sよくそれでコード書いてるな
目的ごとにブランチ切ってコミットあたり1ハンクだけで済むようにするのがベストプラクティスだ
0440デフォルトの名無しさん
2015/05/09(土) 00:45:24.25ID:oI9IuS7a> バグを埋め込んでしまった場合、コミットをまとめるとリーディング量が増えるからまとめないほうがよいという結論に達した
具体例かける？
書けるはずだよね。書いて。
0441デフォルトの名無しさん
2015/05/09(土) 00:56:47.31ID:bOQm//LK0442デフォルトの名無しさん
2015/05/09(土) 00:58:05.96ID:oI9IuS7a0443デフォルトの名無しさん
2015/05/09(土) 13:31:25.76ID:MqwqSntJ戻る時ってgit reflogで最新の履歴を確認してgit reset HEAD@{n}しました
こういうやり方であってますか？
0444デフォルトの名無しさん
2015/05/09(土) 13:38:29.58ID:P/ABm+5N0445デフォルトの名無しさん
2015/05/09(土) 13:38:44.30ID:8PoBBRDQ0446デフォルトの名無しさん
2015/05/09(土) 13:41:01.09ID:oI9IuS7atigコマンドを使う。
0447443
2015/05/09(土) 19:11:08.54ID:hILIDw1ntigも調べてみます
0448デフォルトの名無しさん
2015/05/12(火) 16:17:37.50ID:pNASC22d元のブランチに戻りたいのですがこのままだとできません
git reset --hard HEADとかgit checkout .とかして更新をなかったことにできません。
元のブランチに戻るためには更新されてない状態に戻す必要があると思うんですがどうやるのですか？
0449デフォルトの名無しさん
2015/05/12(火) 16:23:44.14ID:KgdwQEvt今度からは、修正したいときは新しくブランチを作ってからやるんだよ
git checkout -b edit_branch head^^
で、修正するも捨てるも良し
0450デフォルトの名無しさん
2015/05/14(木) 08:09:17.45ID:aOO0/Ibj0451デフォルトの名無しさん
2015/05/14(木) 08:11:21.04ID:aOO0/Ibj0452デフォルトの名無しさん
2015/05/14(木) 08:43:10.59ID:U5lm4ek90453デフォルトの名無しさん
2015/05/14(木) 12:28:03.63ID:dw1HaLxu*
!*.txt
!data/
data/.*
!data/*.txt
mkdir data
touch data/a.txt
touch data/.b.txt
git init
git add .
これでdata/.b.txtもインデックスに追加されてしまいます
.gitignoreでどういうふうに指定したら.から始まるファイルを除外できますか？
0454デフォルトの名無しさん
2015/05/14(木) 12:59:28.26ID:7ksZOIpVdata/*.txtにdata/.b.txtがマッチするのはちょっと妙に感じるかもしれないけど
data下の.ではじまるファイルを全部除外したいなら、
ルールの!data/*.txtとdata/.*の順番を入れ替えればいいのかな
0455デフォルトの名無しさん
2015/05/15(金) 11:59:16.15ID:XocOnm+Lブランチを削除してもレビューやコメントを残す方法は何かないでしょうか？
0456デフォルトの名無しさん
2015/05/15(金) 20:00:20.09ID:p2cJvo/x0457デフォルトの名無しさん
2015/05/16(土) 01:25:17.31ID:+UC07Y5Wgithubは知らないけど、gitlab（最新版）なら
ちゃんと残る。
正確にはコメントやレビューはマージリクエスト（githubのプルリク相当）に書かないとダメ。
ブランチ（コミット）に対してのコメントであれば見れなくなる。（今は残ってる気もするけど）
0458デフォルトの名無しさん
2015/05/16(土) 17:17:39.54ID:AD3UxZEYありがとうございます。Gitlabを使ってるのでバージョン上げてみます。オフィシャルブログの更新内容をみてもそれらしき更新がなくダメだと思ってました。
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のブランチって使いづらくね？
■ このスレッドは過去ログ倉庫に格納されています