バージョン管理システムについて語るスレ10

1 ：デフォルトの名無しさん：2014/02/23(日) 18:17:11.03

バージョン管理システムについて語りましょう

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
バージョン管理システムについて語るスレ8
http://toro.2ch.net/test/read.cgi/tech/1295493964/
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

132 ：デフォルトの名無しさん：2014/03/09(日) 23:33:39.91

gitとは関係なしに
バージョン管理システムにおけるセキュリティの問題って何？

133 ：デフォルトの名無しさん：2014/03/09(日) 23:49:30.33

>>132
フォルダ毎にアクセス制限かけたりとかかな
外注さんとやってると、ここは見せたくないとかあるから

134 ：デフォルトの名無しさん：2014/03/10(月) 00:07:57.53

>>133
そういう需要があるのは理解できるけど
フォルダ毎のアクセス制限を管理するのと
最初からリポジトリとかフォルダより上位のモジュールで分けて管理するのと
どっちが合理的かというと微妙な気が……

セキュアだけどまともに運用できるかという点で
SELinuxのそれと似た印象を受ける

139 ：デフォルトの名無しさん：2014/03/10(月) 06:08:27.66

>>134
> どっちが合理的かというと微妙な気が……

状況次第でしょ？
リポジトリ分ければいいじゃんとか言ってる奴いるけど、プロジェクトの一部が社外には出せないと言う状況で、全部を社内で開発してる時と外注さんに任せる時でリポジトリの構成変えるの？

140 ：デフォルトの名無しさん：2014/03/10(月) 06:24:12.14

>>139
えとさ、どういうディレクトリ構成なのさ？
それ言ってくれんとわからん。

なんか、話を聞いていると、一つのディレクトリのあちこちに、
社内に公開できる部分、出来ない部分があってごちゃごちゃ
混ざってるように思えるんだけど？

もしそうだとしたら、それ人為的ミスで間違って
ファイルわたしてしまう可能性があるから修正した方がいいよ。

簡略化するとこういう感じ
root
├メインプロジェクト（自社開発）
└外注さんに任せるライブラリ

もしくは

root
├メインプロジェクト（外注さんと共同開発）
└自社専用ライブラリ

ライブラリ部分はgitで言えばsubmoduleという機能を使えばいい。
submoduleは外部のリポジトリを自分のリポジトリに埋め込む機能。
もちろん別々のリポジトリとして扱える。

submoduleはルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。

142 ：デフォルトの名無しさん：2014/03/10(月) 07:51:24.77

>>140
> もしそうだとしたら、それ人為的ミスで間違ってファイルわたしてしまう可能性があるから

そのためのセキュリティなんだが...、git 脳には伝わらんか。

143 ：デフォルトの名無しさん：2014/03/10(月) 08:38:35.22

>>142
お前、セキュリティ単語いってるだけじゃん。
具体的に何をしているのかいえって。

俺のセキュリティならなんの問題もない（笑）

144 ：デフォルトの名無しさん：2014/03/10(月) 10:17:47.96

>>143
プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ？
理解できない？
派遣の外注さんに応援頼むんだけと、社外秘のソースとかとかお客さんとの契約でここは関係者以外には見せちゃダメとか、色々あるんだわ。
お前んとこでそんな状況になったこと無いから問題なしとか言うならいちいちでしゃばってくんなよ。

145 ：デフォルトの名無しさん：2014/03/10(月) 10:33:11.63

>>144
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。

特定の人、グループの管理をするという発想は当然あって、
もちろん用意されている。gitで言えば、Git-サーバー-というのが
そういうことをしてくれる。

あんたの言ってることは、みな想定の範囲内の
すでに解決済みの話だよ。

148 ：デフォルトの名無しさん：2014/03/10(月) 10:56:10.55

>>145-146
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ？ とは思うが、git 脳だと当たり前なんだろうな (w

154 ：デフォルトの名無しさん：2014/03/10(月) 11:49:36.89

一体どういう管理方法をしてるんだろうな。
gitの批判をする前に、具体的にどういった
やりとりをしているのか書いてほしいね。

まずは、ディレクトリ構造と
それをどうやってアクセス制限をかけているのかを

173 ：デフォルトの名無しさん：2014/03/10(月) 15:14:06.52

>>154
>>144 みてわからないなら、諦めてくれ。

171 ：デフォルトの名無しさん：2014/03/10(月) 15:02:36.91

制限が必要ならgitoliteだかそんなのいくつかあるだろ

178 ：デフォルトの名無しさん：2014/03/10(月) 15:25:06.58

>>171
> gitolite

ブランチをうまく使えばいいかと思ったけど、見せないって言うのは無理なんだな。
まあ各自がリポジトリ自体を持ってしまう git だと難しいし、そもそも OSS だと必要性は薄いからなぁ。

176 ：デフォルトの名無しさん：2014/03/10(月) 15:18:19.61

>>173

>>144なら普通にgitでもできるよ。
これで問題解決したよね。

180 ：デフォルトの名無しさん：2014/03/10(月) 15:27:28.08

>>176
見せないこともできるの？
リポジトリを分けることについては、>>148 の後半見てね。

179 ：デフォルトの名無しさん：2014/03/10(月) 15:26:38.21

>>178
話し聞いてる？

gitは普通のディレクトリをそのままgit管理できるの。
だからそのサブディレクトリ単位で公開非公開も設定できる。

このやり方はgitをちゃんと使ったやり方よりも劣るが、
単なるディレクトリよりはマシ。

なんどでも言うよ？

182 ：デフォルトの名無しさん：2014/03/10(月) 15:29:55.85

>>180
リポジトリを分ければもっと柔軟に管理できる。

だけど、分けなくても出来ないことはない。
gitのリポジトリはただのディレクトリ上位互換。
ディレクトリでできることは全部gitリポジトリで出来る。

それはちゃんとgitを使ったやり方より劣ったやり方だけど
ただのディレクトリよりは優れている。

まあ、君の技術が追いつくまではこれ使っていればいいんじゃない？
俺からすれば不便だけどさ。あれもできないこれもできない。

181 ：デフォルトの名無しさん：2014/03/10(月) 15:27:33.91

ブランチを使うという発想自体が
すでに間違ってるよね。

道具を間違った使い方をして
使いにくいと言っているだけ。

こういうのも「技術力」だからね。

187 ：デフォルトの名無しさん：2014/03/10(月) 15:39:45.39

>>181
なら >>144 を実現するための正しい方法を書いてくれ。
今のところ >>140-141 ぐらいしかやり方出てないようだけど？

>>182
> ディレクトリでできることは全部gitリポジトリで出来る。

だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね？
git でどうやるの？

193 ：デフォルトの名無しさん：2014/03/10(月) 17:21:18.71

>>187
> だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね？
> git でどうやるの？

お前根本的な所がわかってないじゃないか。
gitでもディレクトリ使ってるんだよ。
gitはディレクトリ＋αと考えればいい。
だからディレクトリでできることは全てgit使っていても出来る。

195 ：デフォルトの名無しさん：2014/03/10(月) 17:26:12.69

>>193-194
ご託はいいから、具体的なやり方書いて。

196 ：デフォルトの名無しさん：2014/03/10(月) 17:44:57.14

>>195
だから普通のディレクトリと全く同じやり方だよ。
これでわからないの？

197 ：デフォルトの名無しさん：2014/03/10(月) 18:36:20.57

先ほどからやたらとgitを否定する方がいらっしゃいますが、git使えなくて
後輩にバカにされた腹いせに書き込んでるのでしょうか？
git脳なんて言ってるけどgit使えない脳の方が問題ですね。

199 ：デフォルトの名無しさん：2014/03/10(月) 19:05:48.64

>>196
それ君が設定してから push して外注さんが clone したら、指定したフォルダは外注さんに見えなくなるの？
まさか、ローカルで見えないから OK とか恥ずかしいこと言ってないよね？

>>197
ごめんな、git 普通に使ってるんだわ。
でも、他も使ってるから粗が見えちゃうんだな。
まあ適材適所なんだが、この手の奴はあまりバラバラにあっても管理がめんどいから、可能なら統合したいんだな。

206 ：デフォルトの名無しさん：2014/03/11(火) 05:17:40.62

>>199
なんで普通のディレクトリではできないことの話をしてるんだ？

何回も言ってるだろう？ gitのディレクトリは普通のディレクトリだ
だから"普通のディレクトリと同じこと"はできると

お前が言ってるpushやらcloneなんてのは普通のディレクトリでは出来ないことだ。
そんなことをしたいなら、ディレクトリを使うな（gitを使え）という話になる。

212 ：デフォルトの名無しさん：2014/03/11(火) 08:04:16.45

>>206
はあ？
>>144 をやりたいって話なのは理解してるんだよね？
ファイシステム云々は >>179 とかが言い出した話だよ？
俺は >>144 が git でできるって言うならやり方示して、って言ってるだけ。
まさか、これがそのまま来るとは思わんかったわ (w
> ローカルで見えないから OK とか恥ずかしいこと言ってないよね？

213 ：デフォルトの名無しさん：2014/03/11(火) 08:07:55.75

>>212
> プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ？
やりたいのはこれだよね？
なんども答え出てると思うけど、

gitは普通のディレクトリを使うので、
一部のフォルダを特定の人/グループに見せないかいうのは
ディレクトリと全く同じ設定をすればよい。

さらにもっと高度な管理がしたければ、gitサーバーを使うことで
柔軟なアクセス制限を書けられる。

submoduleを使うことで、プロジェクトの一部を
別リポジトリにすることだって可能。

216 ：デフォルトの名無しさん：2014/03/11(火) 08:15:43.08

>>213
> なんども答え出てると思うけど、

リポジトリ分ける以外の答あったっけ？

> さらにもっと高度な管理がしたければ、gitサーバーを使うことで
> 柔軟なアクセス制限を書けられる。

だからそのやり方書いてよ。

220 ：デフォルトの名無しさん：2014/03/11(火) 08:25:26.44

>>216
> > さらにもっと高度な管理がしたければ、gitサーバーを使うことで
> > 柔軟なアクセス制限を書けられる。
>
> だからそのやり方書いてよ。

お前が、gitサーバーで柔軟なアクセス制限できるという事実を素直に認めたらな。

お前が今知るべきなのやり方ではなく、gitサーバーがお前の目的を
叶えてくれる道具だということを知ることだから。

http://git-scm.com/book/ja/Git-サーバー-サーバー用の-Git-の取得
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E7%94%A8%E3%81%AE-Git-%E3%81%AE%E5%8F%96%E5%BE%97

ちょっとしたセットアップ
小規模なグループ、あるいは数名の開発者しかいない組織で Git を使うなら、
すべてはシンプルに進められます。Git サーバーを準備する上でもっとも複雑なことのひとつは、
ユーザー管理です。同一リポジトリに対して「このユーザーは読み込みのみが可能、
あのユーザーは読み書きともに可能」などと設定したければ、アクセス権とパーミッションの設定は多少難しくなります。

SSH アクセス
開発者全員が SSH でアクセスできるサーバーがすでにあるのなら、リポジトリを用意するのは簡単です。
先ほど説明したように、ほとんど何もする必要はないでしょう。より複雑なアクセス制御をリポジトリ上で行いたい場合は、
そのサーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。

リポジトリに対する書き込みアクセスをさせたいメンバーの中にサーバーの
アカウントを持っていない人がいる場合は、新たに SSH アカウントを作成しなければなりません。
あなたがサーバーにアクセスできているということは、すでに SSH サーバーはインストールされているということです。

229 ：デフォルトの名無しさん：2014/03/11(火) 10:40:50.83

>>220
user = {dev1, dev2, co-dev1}
がいるときに、
/proj/src/app/
/proj/src/lib/
/proj/src/else
/proj/else
というディレクトリ構成で、
* dev1,dev2は全てのディレクトリ以下を参照できる
* co-dev1は/proj/src/lib以下を見ることができない。それ以外は全部参照できる
という設定をするとき、
dev-group = {dev1, dev2, co-dev1}
lib-dev-group = {dev1, dev2}
というグルーピングをし、
chgrp -R /proj dev-group
chgrp -R /proj/src/lib
chmod -R 770 /pro/src/lib
とすれば実現できるが、これをgitではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

244 ：デフォルトの名無しさん：2014/03/11(火) 13:58:09.47

>>229
gitでの話。

drwxrwx--x dev-group:dev-group /proj ← ここ以下をgitで管理
drwxrwx--x dev-group:dev-group /proj/.git ← gitデータディレクトリ
drwxrwx--x dev-group:dev-group /proj/src/app/
drwxrwx--- lib-dev-group:lib-dev-group /proj/src/lib/
drwxrwx--x dev-group:dev-group /proj/src/else
drwxrwx--x dev-group:dev-group /proj/else

dev-group = dev1, dev2, co-dev1
lib-dev-group = dev1, dev2

こうすればいい。お前が言ったことを分かりやすく図にしただけ。
（これだと新規ファイル作成時に問題があるがね。気づいてないでしょ？慣れてないことするからｗ）

gitは普通のディレクトリなのだから、同じようにやればいいと言ってる。
これが下記のgitの使い方の一つとして述べられてる「ファイルベールのリポジトリ」

この欠点はdev-groupはgitを使えるが、それ以外はgitを使えないということと
gitを使う時に多少考える必要が有ること、gitの本領を発揮できないということ。
だがgitを使いたくなった時は、ただのディレクトリではダメな作業が
できたということなので即刻ディレクトリをやめろという話になる。

4.1 Git サーバー - プロトコル
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

利点
ファイルベースのリポジトリの利点は、シンプルであることと既存のファイルアクセス権や
ネットワークアクセスを流用できることです。チーム全員がアクセスできる共有ファイルシステムがすでに存在するのなら、
リポジトリを用意するのは非常に簡単です。ベアリポジトリのコピーをみんながアクセスできるどこかの場所に置き、
読み書き可能な権限を与えるという、ごく普通の共有ディレクトリ上での作業です。

283 ：デフォルトの名無しさん：2014/03/11(火) 15:27:00.67

一人だけ完全にずれてることにまだ気づかない奴

284 ：デフォルトの名無しさん：2014/03/11(火) 15:28:42.86

そもそも最初からgitだとsubmodule使うしかないねって話なのに。

285 ：デフォルトの名無しさん：2014/03/11(火) 15:50:06.26

ディレクトリ共有とか、もう何年もその発想忘れてたわ

287 ：デフォルトの名無しさん：2014/03/11(火) 17:39:26.04

>>283
もうわざとでしょ、彼にとってはバージョン管理なんかより git でもアクセス制御ができると言えることが最重要なんだよ、例えそれに意味がなくても (w

>>284
現状ではそれが一番みたいですな。

>>285
特に SCM 使ってたら直接共有する必要ないしな。

290 ：デフォルトの名無しさん：2014/03/11(火) 17:48:26.46

最初に俺がサブモジュールというちゃんとした答えを言って
サブモジュールを使うより劣るけど、git＋共有ディレクトリでもやれなくてはないよ。
（だから共有ディレクトリでやれるアクセス制限はもちろん出来る）
って話をしているのに、わかってないんだな。やっぱり馬鹿か。

http://peace.2ch.net/test/read.cgi/tech/1393147031/l50/../