プロジェクトにおけるGIT管理のフォルダ構成について考える

最近色々な仕事を同時進行で行う事があり、その多くがシステム開発やホームページ制作なので、ソースやデータ管理をgitで行っている。 企業クライアントがほとんどなので、githubなどは使わず、独自サーバーに構築しているgitリポジトリサーバーなので、容量制限はほぼ無い。 しかし、これまで１つのプロジェクトについて、１つのgitリポジトリにこだわっていたんだけれど、打ち合わせや資料などのドキュメント管理と、各種プログラムのソースコードの更新が、ゴッチャになるのが気になっていた。 ブランチを切り分けてもいいんだが、クライアントから無造作にタイミング構わず飛んでくる資料などは、いちいちブランチ切り替えを行うなんて作業をしている暇は無い。 そこで今回、思い切って仕事におけるgitのリポジトリ構成について、考え直してみる事にした。

プロジェクトの主なgit分類

・ docs ・ src

基本的にはこの２つの分類で成り立つ。 srcがフロントエンドとバックエンドなど、複数サーバーでの管理をする場合は、もちろんリポジトリを分けるので、適宜ソース管理リポジトリは用途に応じて増やしていくので問題ないだろう。

docs

Documentsの略で、これまでdocsフォルダを作っていたので、そのままの名称で、使うとして、以下の様なリポジトリ名にする。

プロジェクト名_docs

その中に毎回フォルダを作って、資料をもらった日、打ち合わせをした日、何かしらのデータが発生した日みたいな分類でやると、事後にあの時あーだったという記憶がフラッシュバックしやすい。（個人的に） サンプルとしては以下のような感じ

docsリポジトリ/ 20240901_初回打ち合わせ/ README.md 20240902_素材一式受信/ 素材.zip

できればdocsリポジトリは、srcリポジトリの場所などを明記しておくことで、迷子になることは無くなるはず。 もちろん、srcリポジトリ側にもdocsリポジトリを明記しておくに越したことはない。 Githubを利用する場合は、wiki機能を使うことで、無駄にリポジトリを増やさなくても良くなるケドね。

src

プロジェクト名でgitリポジトリをまとめられる様に、以下の様なリポジトリ命名にする。

プロジェクト名_src

srcリポジトリの中身は、ホームページ制作の場合、いきなりrootにindex.htmlが来るのはよろしく無い。 .gitフォルダがdocument_rootに入ってしまうと、サイト脆弱性につながるので、必ずpublicなどのフォルダを作るのがいいだろう。 ※サーバーでのdocument_rootの設定は.htaccessやnginxで行えばいいのだが、できない場合は、適宜対応すること。 FTPなどでアップロードするような構成の場合も、publicフォルダを作っておくと非常に扱いやすくなるよ。

srcリポジトリ/ public/ index.html mochup/ index.html

あと、マルチバージョンの管理も同時にできてしまうので、便利に使える。 ブランチで管理してもいいが、どうしてもファイルで管理したほうが便利な場合もある。 しかし、gitのlogなどを整えたい人には、別バージョンをフォルダ配置で行うのはあまりお勧めできない

動画などの大容量の管理について

動画データは、とにかくGB単位でデータが爆発します。 他にも、クライアントから送られてくる、意味不明なパワポデータ（容量がめっちゃ大きい）や、何が入っているか怖くなるzipデータなど、 これらももちろん、リポジトリを分けておく方がいいかも。 そもそも、githubでは、50MB制限があるし、（正確には50MBで警告が出て、100MBでpushブロックされます） Git LFS（Large File Storage）ツールを使って、回避しようとしても、上限容量が、freeの場合は2GB、エンタープライズで5GB。 動画ファイルなんて、これじゃ済まない場合も結構あるので、もはやgithub使えませんがな・・・やはり独自gitリポジトリの存在は大きい様だ。 動画編集者は、そもそも、データ管理をどうしているんだろう？と疑問に思ってしまう・・・ まあ、そんな場合は、バージョン管理しない方がいいと判断してもいいかもね。

他人との共有

プロジェクトメンバーがいる場合は、docsは全員共有するリポジトリでいいんだけど、 srcが複数ある場合は適宜必要なリポジトリのみを共有するのが良い。 リポジトリを分けることで、必要な箇所のみのデータのみで済むので、docsなども領域が多岐にわたる場合は、分割するのも悪くない。 とにかく、他人とのリポジトリ共有は、会社であれば情報漏洩に気をつけないといけないので、その視点を忘れてはいけない。 残念ながら、gitは、一度共有してしまうと、相手のローカル環境から強制的にデータを消し去ることはできないので、何かしら別の方法で管理することも検討した方がいいかも。 とりあえず、今の時点ではあまり他人とのリポジトリ共有は無いので、これについてはそのうち考えていく事にする。

あとがき

実は今回のgitのリポジトリ構成も個人的には良い方法だとは思っていません。 だって、１つのプロジェクトで複数のリポジトリが発生するなんて、をれらをまとめて管理する何かしらの方法がないと、複数のプロジェクトが溜まって行った時に、リポジトリ一覧が乱雑になるからね。 でも確かに色々な会社のプロジェクトを見てきたが、フロントエンドとバックエンドのフレームワークごとにリポジトリを分けているケースは多い印象がある。 でもそれって、その会社のプロジェクトは、ほぼワンサービスで運用しているベンチャー企業だからなんだよね。 リポジトリがいくつ増えても、githubでのアカウント内で管理できちゃうので、さほど困らないんですよ。 それにくらべてホームページ制作って、プロジェクトがたくさんたまるので、今回の様に思考を凝らしておく必要があるんですよね。 独自に構築しているgitリポジトリシステムに、便利なdocs機能が備わればいいのかもしれないが、リポジトリ管理だけをまとめる事ができるwebサービスを独自に立ち上げるという手もあるな・・・と書いていて考えてしまった。 何にせよ、似た様な事で独自の方法でやっている人がいたら、教えてくださいませ。