2017-10-09 Git > 検討 > 共有ファイルのバージョン管理 > git subtree | git submodule | 自前の仕組み ?

背景

様々なプロジェクトにユーティリティなどの共有したいファイルが数十個あるとする。
その共有ファイルは以下のような条件で保持したい。

• プロジェクトA (出荷済み):
  • v1.0のまま保持
• プロジェクトB (出荷済み):
  • v1.2のまま保持
• プロジェクトC:
  • 最新バージョンを適用しつつテストする

gitでどうするか

共有ファイルの取扱いに関して、gitの場合、以下の方法があるようだ。

• git subtree
• git submodule

参考: 【手順】git subtreeコマンドの使い方

Git subtree
→外部リポジトリを現在のリポジトリのものとして取り込み、手を加えていくときに使用する。
Git submodule
→外部リポジトリを現在のリポジトリの外のものとして取り込み、今後編集しない時に使用する。

上記のプロジェクト構成の場合、Git subtreeは使えない。
Git submoduleはどうか。

Git: Submodule地獄からの脱出
などを見ると、使い方をきちんと理解しないと失敗しそう。
学習コストと使用による効率を考えると、使うのがいいのかどうか迷いつつ、今まで使っていない。

こうしている

2017年10月9日現在、以下のようにしている。

• 共有ファイルだけのリポジトリを作成
• 各ファイルごとにバージョンを付加
  • UtilScreen.cpp: v0.2
  • UtilEncodeDecode.cpp: v0.5
  • etc
• 各ファイルに変更があった時にコミットする
  • 複数ファイルのコミットにしないことで、個々のファイルの過去バージョンを取出せる
    • タグでなくコミットで過去バージョンを検索
• 新しく作るプロジェクトはこのリポジトリから最新ファイルを取得
  • 問題がある場合はバグ修正をしてバージョンを上げる
• 古いプロジェクトはバグ修正以外ではバージョンはそのまま
  • バグ修正時は動作確認済みバージョンを適用
    • 最新版とは限らず、古いバージョンとする場合もありうる

余談

Microsoft Visual SourceSafeには「ファイル共有」という機能があった。
一つのプロジェクトで修正した内容は、瞬く間に他のプロジェクトに波及する。

過去のプロジェクトの一部の機能変更時にビルドしなおすと、共有されたファイルの変更も入り、場合によってはエンバグすることになる。

こういう背景もあるため、安易に「（自動）共有」はしたくはない。