- 1 名前：デフォルトの名無しさん mailto:sage [2014/01/14(火) 21:16:57.41 .net]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
◆前スレ
Git 7
toro.2ch.net/test/read.cgi/tech/1381929347/
- 976 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:41:55.23 ID:kSIcd9mI.net]
- 見てて結構面白いんだけどレッテル貼りだけは負け逃げみたいだからアカンよ。
- 977 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:49:00.36 ID:EipzA34R.net]
- >>958
ロックしなくて問題ない。
作業がかぶっていなければ、修正内容がかぶることはない。
かぶったらコンフリクトを解消すればいいだけ。コンフリクトを解消するのは、小さな作業。
（コンフリクトを解消した、つまり修正後のテスト等はロックがあっても結局やるべきことだから違いはない）
たとえロックしていたとしてもコンフリクトは発生する。
バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ
それはロックしなくてもできること。
> 該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。
複数のチケットで、たとえば画像を赤くしろ、青くしろなんてのがあったら
作業前にどちらのチケットをやるかを決めるべきこと。
ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。
だからこれはチケットで解決するべき問題。
複数のチケットから参照されてるなんて、具体的でないケースを言うからわからなくなる。
複数のチケットで、同じものに対する修正があるとき、それをどうするかはチケットで解決するべき問題だってわかるはずだ。
- 978 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:54:07.45 ID:EipzA34R.net]
- 考えれば考えるほど、ロックの意味がなくなってきたな。
AとBを同時に修正して、AをマージしてからBをマージするか
Aを修正してマージしてから、Bを修正してマージするかの違いしかないじゃないか。
この場合コンフリクトはどちらでも起こりうるし、
単に修正作業が直列化したに過ぎない。
（マージだけを見ればどちらも直列化している）
- 979 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:02:32.23 ID:s4x1CSLN.net]
- >>961
> バイナリファイルにおいてのコンフリクト解消とはどちらかを取るだけ
はあ？
どっちかの編集の労力を捨てろって言ってるの？
> ソースコードが複数のチケットから参照されていても、内容がかぶらなければマージすればいいだけ。
だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？
実際の運用考えてないのか？
> ロックがあったとしても、画像を赤くしてから、青くすれば、結局赤くした修正はなくなる。
上半分と下半分の両方が修正されるというケースは思い付かないのか。
- 980 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:05:42.24 ID:EipzA34R.net]
- > どっちかの編集の労力を捨てろって言ってるの？
その為にチケット管理しろって言ってるの。
どのファイルを修正するかなんて
作業前にわかるだろ。
- 981 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:06:23.64 ID:s4x1CSLN.net]
- >>962
> 単に修正作業が直列化したに過ぎない。
当たり前だろ、直列化するための仕組みなんだから (w
普通にやるとそうならない場合があるから困ってるわけで...
- 982 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:09:32.79 ID:s4x1CSLN.net]
- >>964
お前が一人で修正するならな。
あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？ についても、書いてね。
- 983 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:10:19.82 ID:kSIcd9mI.net]
- まあ平行作業しないで済むならそれに越したことはないよね
- 984 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:10:25.33 ID:EipzA34R.net]
- > だからそのケースで、ロックしてるっ言う情報はどこに記録するんだ？
要らない。
チケットベースで作業管理していて、作業内容が違うから、
内容はかぶらないのですんなりマージできる。
まれにマージできない場合だけコンフリクト解消するだけでOK
それよりも問題なのは、マージできない場合＝ロックする必要がある時に
本当にロックしてしまうと、並列で作業できるはずのことが
並列で作業できなくなってしまう。
それは開発の遅れを引き起こす。
ロックしないから並列で開発できる VS ロックするから並列で開発できない
こういいう話。
> 上半分と下半分の両方が修正されるというケースは思い付かないのか。
上半分を青くして、下半分を赤くする修正の二つが終わった時、
本当に、上半分を青くしてといった人の意図したとおりなっているかはわからない
やっぱり修正を始める前に、チケットで解決しておくべき問題だったな。
- 985 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:11:50.26 ID:EipzA34R.net]
- >>966
> あと、複数のチケットから参照されるケースについて、ロック情報をどこに書くんだい？ についても、書いてね。
書かなくていいというか、書いたらダメ。
書いたら並列で開発できなくなる。
"一人で開発しているから" 並列で開発することは出来ないからどうでもいいが、
"複数人で開発しているなら" 並列で開発できなくしてはいけない。
並列で開発できなくなったら待ちが発生する。
- 986 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 14:20:20.28 ID:gbb+IGlp.net]
- スレ立て乙
しばらく離れるのでまた次スレで。
- 987 名前：デフォルトの名無しさん [2014/04/12(土) 14:24:48.81 ID:UapBJj1i.net]
- Git 9
toro.2ch.net/test/read.cgi/tech/1397276540/
- 988 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:05:13.12 ID:s4x1CSLN.net]
- >>968-969
マージできるファイルの話ならいちいちレスしなくてもいいよ。
誰もマージできるファイルにロックが必要とは言ってないから。
- 989 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:23:49.87 ID:qyNsAYgL.net]
- とりあえずだ。
gitにロックが必要か？という問題については、答え、必要ない。
バージョン管理にロックが必要か？については、答え、必要なこともある。
ってことでいいな。
つまり、ロック機能がほしいファイルを分散型のバージョン管理に突っ込むなということだ。
gitにロック機能必要といってるやつは、まず分散型の仕組みから復習しろ
- 990 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:39:46.69 ID:s4x1CSLN.net]
- >>973
> gitにロックが必要か？という問題については、答え、必要ない。
そうなんだろう、お前の中ではな。
- 991 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:45:39.17 ID:zMh1JnO5.net]
- 必要かどうかってより、gitのような分散型バージョン管理でロック実装はひどいことになるんじゃないの
- 992 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 15:54:45.04 ID:8wXT0UMc.net]
- 何でもできて重くもないツールにできるんだったら、
分散型でも集中型でも管理できてロック使用要否も選択できてissue管理もできて
ってすればいいよ
自分もExcelやWordを後からマージ作業はやりたくないからロックありで管理したいものがあるのはわかるけど
それをソースと同じくgitで管理したい、とは思わない
別のツールでいいじゃん
- 993 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:16:06.70 ID:iNxrw8O2.net]
- ume
- 994 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:19:24.13 ID:s4x1CSLN.net]
- >>975
分散だと原理的に無理だと思う
ただ、分散諦めても普段使い慣れた git を使うという選択肢があってもいいと思う
企業内だとそういう使い方は多いと思うしね
>>976
> それをソースと同じくgitで管理したい、とは思わない
仕様書を Word/Excel で管理していたり、リソースとかはソースと一緒に管理したい人もいるんよ
- 995 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:52:24.54 ID:U3ze+O2N.net]
- まだ一人でがんばってんのか。無駄に。
- 996 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 16:59:26.37 ID:zuiRAUii.net]
- officeドキュメントの管理は、本来ならSharePointを使った方が良い
ただ、ソースコードと一緒にドキュメントも管理したい場合もあるのは確か
svnでもgitでもhgでもドキュメントの管理にはあんまり向いてるとは思わないが、あえて言えばsvnが一番使いやすいと思う
ロックもそうだし、Windowsクライアントが優れてたり、日本語ファイル名とか、部分チェックアウトとか
- 997 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:04:58.66 ID:qyNsAYgL.net]
- >>978
そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。
リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、仕様書だけ、必要な人の方がおおい。
まぁ、まだ個人的にしかやったこと無いから、pj単位で運用したときはどうなるかわからんけど。。。
試してみるなら、リビジョンの不整合にはよう注意な。
ブランチ運用をちゃんとやらないと、svn側が大変なことになる。
- 998 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:11:43.01 ID:1eEiGLxS.net]
- なんでもエクセル使って書くバカと同じで
なんでもVCSで管理しようとするバカがいるのだろうか？
VCSはソースコードを管理するために作られたツールだ
ソースコード以外を入れようと考えるな。
そもそもバイナリを入れるという考えが間違いであることに気づけ。
- 999 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:22:34.14 ID:1G+VXwG6.net]
- >>982
間違ってはないと思うが。
- 1000 名前：デフォルトの名無しさん [2014/04/12(土) 17:28:45.84 ID:UuzLKOtw.net]
- レポジトリa,bがあり、bはaのサブモジュールになっています。
aのブランチを切り替えると、bの一部ファイルが消えるのですが、原因はわかりますか？
bでコミットをしたら、aでbについての「subproject commit ハッシュ」という変更もコミットする必要があるのでしょうか？
- 1001 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:34:28.48 ID:1eEiGLxS.net]
- >>984
サブモジュールについての理解が甘いようだね。
サブモジュールはライブラリなど自分以外の
誰かが作っているリポジトリだと考えよう。
誰かが作っているということは、勝手にバージョンが上がるということだ。
そしてだ、君のそのコード。
それはサブモジュールのライブラリの
どのバージョンのコードで正しく動くのだ？
他人が作っているライブラリのバージョンが変わった時、
勝手に新しいバージョンを使ったら困るだろう？
- 1002 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:36:55.18 ID:NV9wCwyl.net]
- >>981
> そゆときは、svnなりcvsのリポジトリを別に作っておいてgitの中にチェックアウトしたディレクトリも全部取り込んじゃえばいい。
ごめん、それなんの意味があるのかさっぱりわからん。
管理だけなら git svn の方がいいと思うけど。
> リソースはともかく、仕様書なんて同じタイミングでコミットするものじゃないし、
なんで？
コミットは別かもしれないけど、一緒に管理してもいいと思うけど。
>>982
はいはい (w
- 1003 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:38:50.24 ID:1eEiGLxS.net]
- 仕様書というのは膨大である。
仕様書はバージョンが有り
更新されると、一部だけが変わる。
その更新はどうやって知るか？
バイナリでは比較が困難なので
テキストで書くのが良い。
仕様書はテキストで書くべきというのが正解。
- 1004 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 17:45:50.74 ID:kSIcd9mI.net]
- テキストだけより図とかも使った仕様書の方がわかりやすくて好きだなあ
- 1005 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 18:09:05.83 ID:1rmX5tVh.net]
- >>987
> 仕様書はテキストで書くべきというのが正解。
自分だけで閉じる奴はそうしてる (ascildoc + graphviz)
- 1006 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 18:18:17.28 ID:zMh1JnO5.net]
- リポジトリにバイナリ突っ込んでるけどなあ、複数人が同時に編集するようなもんほぼないけど
- 1007 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 19:07:55.75 ID:U3ze+O2N.net]
- バイナリでも自分と相手のデータをアプリで開いてマージするだけだな。ロックがあろうとなかろうと。
作業が被るかどうかはプロジェクトマネジメントの領域で、同じ作業でも違うファイル名で新規に作ったりしたらロックしようがない。
- 1008 名前：984 mailto:sage [2014/04/12(土) 21:32:17.16 ID:UuzLKOtw.net]
- >>985
そうだったんですね、勘違いしてました。
a,bともに自分のレポジトリで、
a,bわけて管理したいときはどうすればいいのでしょうか。
aのディレクトリにbが存在しています
- 1009 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 21:36:24.94 ID:1eEiGLxS.net]
- >>992
別人になったつもりで作業すればいいだけ。
- 1010 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 21:53:11.54 ID:gbb+IGlp.net]
- まだ埋まってなかったのか。
ロック必要だよ派はまだ居る？
(宗旨替えした結果いなくなったのなら、それはそれで良いけど)
- 1011 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:21:13.23 ID:gbb+IGlp.net]
- 早ければ来週あたり 2.0-rc0 がでるっぽい。
これで新機能追加はほぼ終わり。
つっても 2.0 正式リリースまでまだ1ヶ月以上あるだろうけど。
- 1012 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:27:45.81 ID:gbb+IGlp.net]
- つーか今朝の6時か7時ごろ 1.9.2 がリリースされてるな。
- 1013 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:28:49.82 ID:gbb+IGlp.net]
- ちがった。2日くらい前か。
- 1014 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 22:47:13.21 ID:qyNsAYgL.net]
- >>986
仕様書とソースじゃ工程が違うからコミットは当然別々になる。もし一緒にコミットしているならレビューのやり方がおかしい。
んで、バージョン管理されるファイルはコミットされたタイミングで全体の整合性が取れているべきなので、ソースと同じところに仕様書の類があるとどっちを信じていいかわからなくなるよ。
というわけで、僕は参照リポジトリの位置付けで、チェックアウトしたしたsvnとかのモジュールを取り込んでる。
ソースをコミットしたタイミングの仕様書も記録できるから。。。
変更するときは、大本だけどねー
- 1015 名前：デフォルトの名無しさん mailto:sage [2014/04/13(日) 01:01:16.17 ID:pwayVEBU.net]
- 梅
- 1016 名前：デフォルトの名無しさん [2014/04/13(日) 01:04:55.07 ID:pwayVEBU.net]
- 1000なら日本国の少子化問題が解決する
- 1017 名前：１００１ [Over 1000 Thread.net]
- このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
- 1018 名前：過去ログ ★ [[過去ログ]]
- ■ このスレッドは過去ログ倉庫に格納されています
|
 |
