質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.98%

共有フォルダでgitを使えるか

解決済

回答 5

投稿 編集

  • 評価
  • クリップ 6
  • VIEW 13K+

matobaa

score 2208

ファイルサーバ上の共有フォルダ(cifs)で複数人でgitを使うことを画策していますが、どんな問題があるでしょうか。経験に基づくエピソードを教えて下さい。

ユーザ企業システム部門に支援で参画しています。

ファイルサーバの中身が混迷を極めています。ファイル名に日付や_r1やFinalのようなオマケをつけていたり、前世代をとりあえずoldに放り込んだり、Excelファイルを複製して各自で編集したものを若手が頑張って統合していたり、といった状態です。扱うファイル形式は xlsxやdocxが中心です。

Subversionの経験があるメンバもいますがマイノリティにとどまっています。混迷を打開するためにTortoiseGitの導入を画策しています。

共有フォルダをremoteとするのはちょっと教育コストが高そうなので、まずは共有フォルダ自体を単一のローカルリポジトリとして扱い、まずは add, commit から始めるのがいいかしらと考えているところです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

+2

Subversionの経験があるメンバもいますがマイノリティにとどまっています。

この一文が非常に気になります。

混迷を打開するためにTortoiseGitの導入を画策しています。

その直後になぜGitに繋がるのでしょうか。

例えば、細かいことはおいて、以下の2つを等価なものとしましょう。

  1. Subversionでどこかに管理場所を用意して共有フォルダのみにチェックアウトしてVer管理(個人PCにはチェックアウトしない)
  2. Gitで共有フォルダのみを単一のローカルリポジトリとしてVer管理(個人PCにクローンしない)

1ができないなら、2もできません。
2ができるなら、1もできるでしょう。

Excelファイルを複製して各自で編集したものを若手が頑張って統合していたり

将来的にもこれは解決できない可能性が高いです。共有フォルダを直接開き、Officeの排他機能を使いましょう。
Gitは基本的にテキストファイルのみマージでき、Excelファイルを整合性を取ってマージする機能がないためです。

複数人でgitを使うことを画策していますが、どんな問題があるでしょうか

最後になりましたが、本題について、共有フォルダ自体を単一のローカルリポジトリとして扱う前提で書きます。

  • そもそも単一のローカルリポジトリを複数人で同時に操作することを想定されて作られていない可能性があり(すいませんがそこまで詳しくは知りません)、同じファイルについて同時に操作するとデータ不整合が起きる可能性がある(起きたことはないですが)
  • 更新アイコンが出ているファイルをどのタイミングでコミットするかの判断が面倒(リビジョンに意味を持たせても、毎日の業務でそのうち疲れてくる。1日1回と決めるとそれ以上の頻度でバックアップ出来ない)
  • ファイルを管理対象へ追加するのが面倒(教育含め)
  • ファイル名を変更する(と管理対象から外れる)のが面倒(教育含め)
  • ファイルパス上のフォルダ名を一部でも変更する(と管理対象から外れる)のが面倒(教育含め)
  • 全てを管理対象とすると容量が肥大(一部分を管理すると追加時の判断が面倒)
  • 全てを管理対象とするとアイコンオーバーレイが重くなる
    (一部分を管理すると追加時の判断が面倒)

など、もっとあったかもしれませんが、忘れてしまいました。

追記します。
どうも管理対象がプレーンテキストのソースコードではなくOfficeファイルのようなので、少し視野を広く持って、シャドウコピーによる定期的なバックアップ運用も比較検討対象に加えられるのが良いと思います。
目的はトータルでの作業負荷の軽減であって、手段にとらわれて余計なことを覚えさせられ、現場に混乱を招くことではないでしょうから。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/01/20 10:03

    私もmatobaaさんがSubversionの経験がマイノリティのユーザ企業システム部門に支援で参画(あと何ヶ月いらっしゃるのでしょう)でなければ、こんな否定的な回答をしたくはなかったのですが・・・ はぁ、心中お察しします。

    キャンセル

  • 2016/01/20 12:07 編集

    参考になるご指摘、大変助かります。ありがとうございます。

    > その直後になぜGitに繋がるのでしょうか。
    ミスリードしてしまい誤解を招いたようで申し訳ありません。気心知れたパイロットチーム5人へSubversionを導入した際は理解も早く、割とうまくいきました。一方でそれを部門ルールに昇華させる(あるいはサーバメンテナを置く)のは気負いしてしまって取り組めていなかったものです。Subversionではご指摘の面倒さ(ファイル名変更を追跡できないなど)があり、このさいGitにすれば解決できそうだ、しかし remote の概念は難しい、というところで答えを探しているところです。

    シャドウコピーのご提案は、なるほど、と思いました。ありがとうございます。

    キャンセル

  • 2016/01/25 18:17

    > Subversionではご指摘の面倒さ(ファイル名変更を追跡できないなど)があり、このさいGitにすれば解決できそうだ

    これはどの辺からそう感じられたのでしょうか。
    「ファイル名変更を追跡」の意図するところを正確には理解していないかもしれませんが、Mercurialには(頻繁に実行するなら面倒となる)名前変更の推定の機能がありますが、gitにあるかは知りません。
    http://tortoisehg.readthedocs.org/ja/latest/guess.html
    基本的には同じ面倒さと思いますよ。

    > シャドウコピーのご提案は、なるほど、と思いました。ありがとうございます。

    フォルダを右クリックして「以前のバージョン」で参照できれば、教育コストは低くてすみますね。

    キャンセル

+2

gitではありませんが、windowsでmercurialを共有フォルダで利用でいていました。

適当に思いついたことをだらだらと書きます。ご存知の内容もおおいとおもいますが・・・

共有フォルダを直接利用していた際はファイルの変更ステータスを検知できなかったりしたので、ローカルから、ファイルサーバでプッシュしていました。

ローカルにファイルを置くことでの問題は共有ファイルにpushを忘れること以外の問題はないと思いますので、是非ともそのようにしてください。

ローカルへのクローン・ブランチの作成と切り替えマージはmatobaaさんが行い、pushをそれぞれが行うようにすれば問題ない気がします。

複数の変更要求に平行して対応するため、変更ごとにクローンをローカルに作っておく必要があります。これはブランチの替えが理解できない人のための処置です。(すぐに不要になりますが・・・)

これは加えて、夜間のhotfixの際のマニュアル(コマンド類はコピペかダブルクリックで済むようにすること)は用意したほうが良いでしょうね。

初めてのgitであればgit-flowで運用しましょう。シンプルで運用の負荷が少ないです。

とにかく必要なコマンドは、用意しておきましょうおいおい教えていけばよいです。

導入して最初にやることは、どんどん不要と思われるファイルを消しましょう。消しても問題ない(戻せる)ことを証明して、不要なものを消すとこへの躊躇をなくすのです。

winmargeにはexcelファイルの比較ができるアドオンがあります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/01/20 09:39

    あと、commitの際は最初はすべて追加でいいでしょう。

    また、コミットログの教育が一番大変です。最初は、毎回指定したほうがいいかもしれません。

    キャンセル

checkベストアンサー

+1

表題の「共有フォルダでgitを使えるか」については、使えません(そのような利用方法は想定されていません)。
以下のページ前半部分「(非推奨)ノンベアリポジトリのみで管理」も参考になるかと思いますが、non-bareリポジトリは同時に1ユーザのみが操作することしか想定されていません。

以下質問の本題からは外れますが、誤解があるようなので説明を記載します。


そもそもgitやsvnといったバージョン管理システム(以下、VCS)のメリットの1つとして、ファイルの実体を共有せずとも複数人で協調作業が行える、というものがあります。
そのメリットをスポイルするのであれば、VCS導入のメリットが薄くなります。
共有ディレクトリ上で運用するのが最善策であると考えられているのであれば、導入すべきはVCSではなく世代管理可能なバックアップシステムではないでしょうか。


(共有ディレクトリ運用を止め)VCSを導入する場合においても、Excelファイルのようにマージ不可能なファイルをバージョン管理したい、そしてVCSに不慣れなエンドユーザがいるのであれば、以下の理由でgitよりsvnが向いていると考えます。

  • (TortoiseSVNを導入すれば)gitよりWindowsフレンドリーである
  • Excel差分表示ツールなども標準でインストールされる
  • VCSがファイルロックをサポートしているので同時編集による競合を防げる

更に話は逸れますが、

Subversionではご指摘の面倒さ(ファイル名変更を追跡できないなど)があり

とありますが、ファイル名変更を追跡できるのはsvnです。
gitが行っているのは(tanagaさんが書かれているhgと同じく)ファイル名変更の推測です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/01/25 21:49

    すごくややこしくて申し訳ないのですが、Mercurialの名前変更の推定の機能は、リポジトリから行方不明となっているファイルと新規追加されたファイルを相似度を見ながらマッチングしていく(その後リネームとしてコミットするための)機能なのですね。

    ファイル名変更を管理したいけど面倒が嫌なユーザのために、とりあえずMercurialを通さずにファイルとしてリネームしてからリネーム後を新規追加(add)しておいて、コミット寸前にファイルの類似度から推定してリネーム扱いにする機能です。

    キャンセル

0

今更ですが、Gitのドキュメントには共有ファイルシステムを使った方法が書かれています。
「Local プロトコル」の部分だけ読めば十分です。
https://git-scm.com/book/ja/v1/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
この場合の利点は、「シンプルであることと既存のファイルアクセス権やネットワークアクセスを流用できることです」とあります。
実際にWindows8系のTortoiseGitでやってみましたが、共有ファイルシステム上にリモートリポジトリを作成し、他のマシンからこれをクローンするだけでいいんです。クローンする際に、リモートのURLを、file:///\\ServerName\Share\Remote.git のように指定すればOKでした。
アクセス権は共有ファイルのがそのまま有効となりますので、Git側ではパスワードも何もありません。また共有ファイル上で普通のファイルとして編集等ができてしまうかも知れませんので、
その辺は合意が必要でしょう。
的を外していたらごめんなさい。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/07/29 22:14

    コメントありがとうございます。
    「共有フォルダをremoteとするのはちょっと教育コストが高そうなので」と思っていたのですが、結局のところ、コメントいただいたこの方法に落ち着きました。詳細な手順書が必要でしたが、事故って破損するリスクをとるより安かったと思っています。

    キャンセル

-1

※ご希望に沿うような回答が出来なかったので、削除しました。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/01/20 08:46

    ごめんなさい、回答になってないです。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.98%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる