22693
会社において、gitで成果報告書の管理を行おうとしています。

私の所属する会社では、現在、報告書や実験データを共有サーバーに保存し、共有サーバー上のファイルを直接開いて編集しています。  
結果、バージョン管理がファイルコピペやoldフォルダ運用になっています。

これを、私個人が使用するリモートリポジトリを共有サーバーに作成し、git pushすることで更新したいと考えています。  
しかし、レビュー会議のPCからExplorerでgitリポジトリ内に格納されたファイルは直接参照できません。  
non-bareリポジトリを無理やり共有することはできますが、リポジトリ上のファイルを直接書き換えられてしまうとアウトです。

非常に簡単な解決法としては、 **チームにgitを導入して、会議用PCでgit cloneし、議事録などと合わせてgit pushすればいい**
のですが、以下の観点から導入に反対される可能性がとても高いです。

・ソフトウェア開発の現場ではないため、そもそも新しいツールの導入ハードルが高い  
・チームの他のメンバのバージョン管理に関する認識が甘く、導入してもExplorer経由でアップロードされるなどルールを容易に逸脱されかねない  
・「WindowsのExplorerから直接参照できないから、見たい時に見れない」「他のチームの人が簡単に見れない」等と上司からクレームがつき、説得できない可能性が非常に高い

そこで、次善の案として考えているのが、「 **bareリポジトリに閲覧専用のフォルダを設ける** 」ことです。  
他の人や会議用PCからはsamba経由でそのファイルを閲覧できるようにして、議事録は別途保存しておいて後から自分でcommit/pushする運用です。  
しかし、このような運用はgitで可能なのでしょうか？

以上のような背景において、ファイルサーバー側に追加ソフトウェアを導入することなく、上記の問題を解決できる手段は何かございませんでしょうか。

2016/3/1 Edited:  
コメントで改行が反映されないので、こちらに書きます。

一応、解決法はgitにこだわってはいません。コピペ・oldフォルダ突っ込み管理が改善できれば手段にこだわりすぎる必要は無いと思っています。

回答の通り、owncloudは良い解決法だとは思います。しかし、それでも共有フォルダを持つサーバー側にサービスをインストールする必要があったと思います。その許可すらとれるかどうか怪しいです。  
また個人的に使っていた時にコンフリクトが大量発生したので、あまりいい印象がありません…。

皆様: 残念ながら、サーバー側で何か実行するのは難しいと思っています。  
アイディアの解決法としては十分に思います。  
サーバ側でスクリプトを書いて、特定のフォルダ(.git等)を一定間隔で監視し、更新されたらgit
pull/cloneするようにすれば、閲覧用フォルダとしては使えそうです。

問題は、私にgitをインストールする権限があるのやら、という点と、他の人にその閲覧用フォルダの中身を編集されたことに気づかなかった場合、消滅してしまうことですね…。

なお、報告書はExcel(xlsx)やWord(docx)も含む(フォルダ内のファイルはそちらがメイン)ですが、Webからでも内容を閲覧できるものなのでしょうか？
CC BY-SA 3.0
2016-02-26T08:28:28.317
22567
2016-03-01T07:51:41.513
2016-03-01T05:39:30.820
9814
9814
question
git
gitの共有リポジトリに閲覧専用のフォルダを設けたい
git にこだわる理由はありますか？ [ownCloud](https://owncloud.org/)( Dropbox の OSS
クローンのようなもの) を立てるなどする方が、ご自身で挙げられた人に関する問題を一気に解決できるように思いますが。。

(ownCloud は API も多分あるはずなので、スクリプトなどによって自動化したければ、それも可能なはず)
CC BY-SA 3.0
2016-02-29T17:40:01.960
22676
2016-02-29T17:40:01.960
754
22567
answer
「gitで」という前提からはずれてしまいますが、以前私が似たようなことを実施した際には、 `Subversion` を利用していました。

共有のファイルサーバーに Subversion リポジトリを作成し、各々の環境から commit を実施していました。

この方法であれば、

  * リポジトリのファイルをそのまま閲覧できる
  * Windows なら `tortoisesvn` などのクライアントを利用すれば、簡単に操作できる

と言ったようなメリットがあると思います。

git のように、ブランチ作成 -> merge といったオペレーションではなく、コンフリクトを避けるにはロックなどの利用をすることにはなるかと思いますが。

人数の規模が少ないし、ドキュメントの変更を行う人も限られていたためコンフリクトが発生することはありませんでした。
CC BY-SA 3.0
2016-03-01T07:36:09.557
22690
2016-03-01T07:36:09.557
7949
22567
answer
> non-bareリポジトリを無理やり共有することはできますが、リポジトリ上のファイルを直接書き換えられてしまうとアウトです。

既存の履歴が失われることはありませんし、頃合いを見てあなたがコミットすればいいように思います。連続した編集を個別に履歴に残せないのと、別名保存されたら手動で直す必要がありますが。

他の人に直接編集させたくないとなると閲覧用フォルダというのも頷けますが、それならリポジトリはあなただけがアクセスできるところ、なんとなればローカルに置いておいて、あなたがコミットする環境上で閲覧用フォルダに同期するバッチなりフックなりを走らせればいいのではないでしょうか。

Git標準ではpush後にローカルで実行するフックはないので（pre-
pushでもいいですけど）、「pushして閲覧用フォルダを更新する」というスクリプトを用意して、push代わりにするという手があります。

**ただし、どちらにせよ他の人はエクスプローラ上で過去の版を見ることができません。**

もし履歴を見る必要がある場合、閲覧用フォルダという考え方が使えなくなります。git等の使い方を覚えてもらうか、もしくはブラウザ上で履歴が見れるツールなどを導入することになりますが、どちらも困難でしょう。もしこの必要があり、OSSなんかインストールできないというのであれば、有償のグループウェアなどしか手がないように思いますが・・・。DropboxとかGoogleDriveとか使えれば簡単なんですけどね。

なお素のGitの場合、一部のフォルダの履歴を見たい場合や、ひとつのファイルに手を加えたい時にも全体をcloneする必要があります。過去の版の整理にもrebaseやfilter-
branchが必要です。サーバー上で直接リポジトリを操作したり、Webツールを使えばこの限りではありませんが、Gitを素直にDVCSとして使うにはあまり向かない対象だと思います。

> 他の人にその閲覧用フォルダの中身を編集されたことに気づかなかった場合、消滅してしまう

閲覧用フォルダを更新するバッチでチェックをするというのが無難でしょう。

可能であれば、あなた以外書き込めないよう共有フォルダのアクセス権を設定すると確実かと。
CC BY-SA 3.0
2016-03-01T07:51:41.513
22693
2016-03-01T07:51:41.513
8000
22567
answer