- 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/
- 962 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:25:31.35 ID:MzN5Zxxd.net]
- > 無駄な編集開始を避けようと思ったら
> (つまりロックしようと思ったら)
> 人間同士のコミュニケーションは避けられない
無駄な編集開始になぜロックが必要になるのか？
別な方法で、無駄な編集開始を避けられるのなら
ロックは必要ない。
君、作業分担にツールは何も使ってないの？
たとえばgithubのIssueとかさ
チケット管理システムとかさ
そういうのだよ。
普通一つのシステムを作る時に、それをいくつかのサブ機能に分けて
担当者を決めると思うけどさ、どうやってるの？
- 963 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:30:48.20 ID:MzN5Zxxd.net]
- 根本的な原因がわかってきたんじゃねーの？
バージョン管理以前の問題だって。
無駄な編集開始を避けるのに使うのはチケット管理システム。
作業を開始する前、作業中。
そのどちらであっても、ソースコード以外の
コミュニケーションツールが必要。
たとえば、仕様の確認とかバグ詳細の確認とかさ、
（まさかいちいちメールでやってるわけないよね？ｗ）
コミュニケーションツール出やるべきことを
ソースコード管理ツールでやろうとするのが根本的な間違い。
無駄な編集開始を避ける話しは、ここまでの話だよ。
- 964 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:32:07.50 ID:gbb+IGlp.net]
- >>947
> 無駄な編集開始になぜロックが必要になるのか？
ロックが必要だと言ってるのは >>936 だよ
>
> 別な方法で、無駄な編集開始を避けられるのなら
> ロックは必要ない。
>
> 君、作業分担にツールは何も使ってないの？
> たとえばgithubのIssueとかさ
> チケット管理システムとかさ
> そういうのだよ。
そうそう、無駄な編集開始を避けたいなら
そういうツールなりでコミュニケーションとれよって話。
「Gitにロックがあれば」なんて話にもっていくのはおかしい、
って俺は言っている。
- 965 名前：デフォルトの名無しさん [2014/04/12(土) 12:44:54.37 ID:BW6c4MFF.net]
- >>948
＞（まさかいちいちメールでやってるわけないよね？ｗ）
お前がメールに親を殺されたか、恋人をNTRされたか分からんがメールへの
恨みだけは他の誰にも負けないことは分かったから黙ってろ。
- 966 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:47:55.69 ID:DvVB/wNe.net]
- >>950
次スレ建てろ
すぐやれ
- 967 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:48:02.86 ID:s4x1CSLN.net]
- とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
あと、分散では原理的に実現できないと言うのもいいよね。
これに反対する奴はいないと思うんだが、いいかな？
>>948 とかが不用意にソースコードとか書くから話がおかしくなってるので、確認させてくれ。
- 968 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:51:17.45 ID:gbb+IGlp.net]
- >>952
おｋ
- 969 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 12:51:58.82 ID:MzN5Zxxd.net]
- > とりあえずロック云々の話しはバイナリ (=マージができないもしくはコストが非常に大きい) の話でいいんだよな。
ちょっと違うな。バイナリがマージできなかったとして、
自分の修正を取るか、相手の修正を取るかの二つしか選択できない。
それはgitであってもできること。
ロックで防げるのは、無駄な編集開始を避ける事ではあるが、
それはチケット管理ツールを使うべき話。
バイナリであったとしても、どちらかを取ればいいので
ロックを使う理由はない。
- 970 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:07:00.16 ID:BW6c4MFF.net]
- >>951
無理だった。
ＥＲＲＯＲ：Lvが足りなくてスレッド立て(ら)れません。
Git 9
名前： デフォルトの名無しさん
E-mail：
内容：
ソースコード管理を行う分散型バージョン管理システム、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 8
toro.2ch.net/test/read.cgi/tech/1389701817/
- 971 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:22:55.97 ID:B/06XIsq.net]
- >>902
>>880=>>815なんだが。
そのあとろくにgit-annexについて考察もしないのに「都合の悪いレス�
- 972 名前：ﾇみ飛ばすな」とか批判する資格ないだろ。
大体git-annexにだって問題点は沢山あるわけで。つーかgit-annexで解決してるならもういいだろ。
単にgitにロックがないということで無駄な論争を起こそうとしてるとしかおもえない。 [] - [ここ壊れてます]
- 973 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:23:23.64 ID:s4x1CSLN.net]
- >>955
立てといた
Git 9
toro.2ch.net/test/read.cgi/tech/1397276540/
- 974 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:31:12.71 ID:s4x1CSLN.net]
- >>954
> ロックで防げるのは、無駄な編集開始を避ける事ではあるが、
ここまでは同意。
> それはチケット管理ツールを使うべき話。
ロックの対象はファイルなので、SCM の方がより適切と思う。
あるファイルを編集する時にロックされてないかを確認するのにどのチケット見ればわかるの？
該当のファイルが複数のチケットから参照されてるとかのケースもあるよね？
- 975 名前：デフォルトの名無しさん mailto:sage [2014/04/12(土) 13:36:24.72 ID:s4x1CSLN.net]
- >>956
本人なのか。
マジで何を言いたいのかよくわからんのだが。
- 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 名前：過去ログ ★ [[過去ログ]]
- ■ このスレッドは過去ログ倉庫に格納されています
|
 |
