gitでなぜbareリポジトリを使うのかという質問を受けたので、自分なりの答えを書いてみる。ちなみに、質問受けた時も後述の内容で回答しました。書いてるうちに半分くらい前職の愚痴になってしまいました…

目次

  1. bareリポジトリとnon bareリポジトリ
    1. bareリポジトリ
    2. non bareリポジトリ
  2. 中央リポジトリ
  3. なぜ、中央リポジトリをbareリポジトリにするのか
    1. ファイルを直接編集させない
    2. 容量が減る
  4. 前職の話の続き
  5. その他どうでもいいこと

どうでもよくないですが、質問を受けて私が以前より考えていた内容(後述)以外に何か適切な回答があるかと思ってさっと調べましたが、言及してる記事は見当たりませんでした。さっと調べた範囲なので、ガッツリ調べたわけじゃないけど。そもそも、公式と思われるドキュメントにも「慣習だから使いましょーね」くらいのレベルでしか記述されてないです。

なので、以下つらつらと私が考えるbareリポジトリを使用する理由を記述します。たぶん、おおよそ間違ってないと思うけどこれ以外の理由があったら知りたい。

bareリポジトリとnon bareリポジトリ


まず、bareリポジトリとnon bareリポジトリが何かをさっと書きます。

bareリポジトリ

bareリポジトリは「ワーキングディレクトリ」が存在しないリポジトリを指します。要するに実態のファイルが存在せずに、履歴情報やブランチ・タグとかそういった情報のみのリポジトリ。慣習的にディレクトリ名の末尾を.gitにします。

GitLabとかGitBucketとかも、gitの機能だけに言及すれば中身はこの末尾に.gitが付いたbareリポジトリをユーザーとかグループごとに管理して、Webページで表示しているだけ。GitHubももちろんそのはず。

リポジトリに対する操作はnon bareリポジトリから行います。

non bareリポジトリ

対してnon bareリポジトリはワーキングディレクトリが存在するリポジトリ。普通はこのリポジトリで作業します。

中央リポジトリ


gitは分散型リポジトリなので、厳密には中央リポジトリは存在しません。が、それだと複数人、複数マシンで開発するときに不便なので「このリポジトリを中央にしましょ~ね~」というルール上のリポジトリを設けることになります。それが中央リポジトリ。

従って、別に個人で 履歴管理だけ したいなら、別にnon bareで管理しても問題ないです。

ちなみに、リモートリポジトリっていうのは自分のリポジトリ以外の全てのリポジトリを指すので、別にnon bareリポジトリでなくても自分のリポジトリ以外は全てリモートリポジトリと呼ぶ。ハズ。

なぜ、中央リポジトリをbareリポジトリにするのか


で、中央リポジトリは一般的にbareリポジトリにするのだが、以下その理由。

ファイルを直接編集させない

これが個人的に一番大きい理由だと思ってます。

中央リポジトリをnon bareにすると、ファイルの編集ができてしまう。これのなにが問題かというと、サーバーのファイルを勝手に編集(あるいはコピーして編集)する輩がでてくるんですよ。信じられないですが。

ええ、前職の愚痴が混じるんですが、突如声を掛けられるんですよ。「YoshinoriN、このファイル編集したけどどうしらいいかな?」とかね。

もう「???」ですよ。「バージョン管理してます。」って言ってるんですけどね。平気でマージ() しろとか言ってくるし。しかも、ソースコードみたいなテキストだとまだいいんですが、パワポとかExcelでやられると「目視マージ」とかいうクソアンクソ作業が発生するわけです。

その作業やるの私ですから!!!

そもそもドキュメントに関してですが、図が必要ないところはMarkdownとかでいいと思うんですが、往々にしてこういう事態が発生する現場でMarkdownとか使ってるわけがないので、精神を消耗しながらクソマージを行うわけです。

「バージョン管理システム使ってるから勝手に編集するな」あるいは「バージョン管理システムを使って手元で編集してください」というのがまっとうなんですが、バージョン管理の概念の無い現場でそんなことは到底困難です。残念ながら。まず、「使い方わかんねえ」からはじまって「オレにそんな意味の解らんもんを使わすな」になるんですよ。経験したことのある人しかわからないと思うけど。

ただ、これに関しては私も「使ってくれそうな人 or 使う頻度が明らかに高い人」にしか指導しなかったのは努力不足だったとちょっと反省してます。

話が前職の愚痴になりましたが、中央リポジトリをbareにすることでこういった「サーバーのファイルを直接編集、あるいはコピーして編集されるという」不毛な問題を解決できるわけです。

私は退職時に置き土産にこの辺りのデメリットをつらつら書いた引継ぎ資料を作成し、あらゆる資産を中央リポジトリ(GitBucket)に放り込んで退職しました。(もちろん、時間をかけてちゃんと説明しましたよ。)

容量が減る

bareリポジトリはワーキングディレクトリがない分、non bareに比べて容量が減ります。これには前職の時のようなケースだとメリットがあります。以下も前職の愚痴ね。

プロジェクト都合うんちゃらで、外注さんにソースコードとかドキュメントを渡す必要が頻繁にあったのですが…。残念ながら、前職のように石器時代のような大手SIer(誤解の無いように書きますがSIerの全てがそうと言いません)だと、クラウドに中央リポジトリを置いてそこに対してpull、pushとかできないんですよ!(いちおう、私の退職間際にようやく承認が通って今はクラウドでやってるみたいですが)

で、クラウドがない前はgitのリポジトリをそのまままるごと渡してました。この時にbareだとnon bareに比べて容量が少ないのでやり取りが楽です。

以上。

前職の話の続き


で、以下はせっかくなので前職の話の続き。gitを使う前はどうしていたかというとSubversionを使っていました。しかし、これだとネットワークがつながっていないと使えないんですよね。Subversionは中央管理型なので。

ではSubversionの時はどうやって外注さんとやり取りしていたか…

必殺!ライブラリアンですね。もちろんライブラリアン(笑)はワタシです。

必要なソースコードとかドキュメントのリストを記載した申請書(笑)を私が受け取って、チェックして、渡すんですね。もちろん、外の開発はSubversionが使えないので、戻ってきたコードとかドキュメントをどうするかというと…ソースコードに残してある修正コメント(笑)とWinMergeを駆使して、手作業でマージ(笑)するわけです。

という、クソないきさつがあって、gitに移行したのですが、そのあともいろいろもめましたね。機会があれば書くけど。

その他どうでもいいこと


書いてるうちにヒートアップして半分くらい前職の話になってしまいました…。ちなみに、前職の内容が多いので前職タグをつけてみました。退職記事を書こうと思ったままほったらかしなので、前職のエピソードが混じるときは使っていきたいと思います。