Gitで複数プロジェクトの管理方法。おすすめは？

Question

Git初心者です。

こちら（http://qiita.com/yuba/items/3670235cf87be335fb39）のサイトと（たぶん）同じ質問なのですが、
例えば、Server側とClient側の２つのアプリで構成される製品のソース管理をしたいとします。
もちろんServerとClientアプリは組み合わせて使うのですが、Server/Clientそれぞれについてメンテナンスをして、個別にバージョン付けをし、個別にリリースするものとします。

ここまでなら、Server/Clientアプリのそれぞれについて、個別のGitリポジトリを作って、個別にコミットやタグ付けをすればよいと思うのですが、
Server/Client間のプロトコル変更などの理由で、あるServerバージョンとClientバージョンで通信互換性が無くなるような場合を想定して、そのようなServer/Client間の関係性もGit上でうまく管理して、Gitコマンド一発で互換性のあるServer/Clientバージョンを正しくチェックアウトできるような方法はないでしょうか？

私が思いつくのは、Server/Clientそれぞれについて同じ名前のタグをつけて、必要があったら、それぞれについてそのタグ名でcheckoutする方法くらいです。これだとgitコマンド２発で済みますが、ソースツリーの種類（製品群のなかのアプリの数）が５個／10個と増えてきたらちょっと面倒ですし、人的ミスも起こり得そうです。

別の想定要求としては、すべてのアプリについて、ある日時（2015年7月1日とか）時点での状態を基にしてブランチを切って、派生バージョンを作りまとめてコミットする、ということも考えられます。
こういうこともまとめて実現できるgit上の管理手法があれば、教えていただきたいです。

ポイントは、Server/Client間の関連性も含めて何らかの方法で履歴管理しつつ、個別のアプリは個別にバージョンタグをつけたり、ブランチしたいということです。

ちなみにsubversionを使ってきましたが、こちらではソースツリー上の特定のサブディレクトリについてブランチやタグ付けができたので、そういう対応をしていました。おかげでリポジトリがグチャグチャですが・・・。

ご意見よろしくお願いします。

Answer 1

実際そういう運用をしたことはないですけれども、git submodule で管理してはどうでしょうか？

Server や Client とは別に、その２つをサブモジュールとして追加したリポジトリを設けて、Server と Client をセットにしたバージョンをそのリポジトリにコミットする、という感じです。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

gitはまだ初めて間もないのでsubmoduleはよく知らなかったのですが、この際少しテストしながら調べてみました。
サーバ側とクライアント側の現在の状態（ハッシュ）を紐付けして覚えてくれるという点では、単にタグを打つだけでなく、ブランチを管理する場合にも魅力的な方法に思えました。
しかし、サーバ／クライアントを統括する側のリポジトリをcheckout/commitするだけでは、submodule側もcheckout/commitしてくれない仕様なのですね。この点で、人為的なミスが起きそうですね。

例えば、最新masterから少し戻ったところでブランチを切って、hotfixを作るとします。
統括リポジトリでgit checkout HEAD^5としたところで、サーバ／クライアント側submoduleは最新のままですね。ここからソースの変更作業に入ってしまった場合は、たぶん人が気づくと思います。「あれ？バージョンが戻ってないぞ」と。このミスは、この段階でgit submodule updateすれば大した問題でもなさそうです。

一方、このhotfixが完成したとしてこれをcommitする段階で、統括リポジトリ側だけでcommitしてしまうと、変更がされていない状態のsubmoduleのハッシュで、新しいhotfixブランチができてしまいます。先にsubmodule側をcommitしなければいけないのに。これに気づかずに進んでしまうと、ダメージが少しありそうです。
これも、すぐに気づくのかな。実際にそういうケースになったことがないので分かりませんが。

submoduleもケースによっては有効そうですが、今回の場合は単にサーバ側／クライアント側の現在の変更状態をまとめて管理したいだけなので、この点では普通のタグ／ブランチで良いような気がしてきました。

ありがとうございました。

Answer 2

1. server ブランチと client ブランチを2本用意して、それぞれでサーバー、クライアントの開発を進める
2. 相手ブランチを適宜マージし合う
3. server ブランチ、client ブランチ上で互換性を保っている状態でないとタグ付けはしないというポリシーにする

みたいな感じではどうでしょう？
特定のタグをチェックアウトしたタイミングでは、3が守られていれば必ず互換性がある状態になっているはず。。。
3が守れていることを保証する仕組みは別途作るか各自が気をつけるかですね

Comments

[退会済みユーザー]

ご回答ありがとうございます。

リポジトリは製品全体で１本とし、サーバ／クライアントでディレクトリ分けはするにしても、変更するときはサーバ側ブランチとクライアント側ブランチでそれぞれ作業する、ということですね。
サーバ側ブランチで作業するときは、（基本的に）クライアント側ディレクトリは変更しない、その逆もしかり、としておけば、競合もしないはずですね。

他の方の回答もそうですが、サーバ／クライアントの互換性の有る無しは機械的には判断できませんから、ここは人間がしっかり判断しなければならない（タグ打ちのタイミング）という点は避けられませんよね。
チェックアウト時はタグ指定一発でサーバ・クライアントが取り出せるので、この方法は分かりやすくていいと思いました。

ありがとうございました。

Answer 3

gitの管理手法（パターン？）といえば、「A successful Git branching model」が筆頭だと思いますが、これでも製品：プログラム＝１：Nのケースについては触れられていませんね。

もうすでにSubversionでリポジトリを管理なさっているようなので肌で感じられていると思いますが、複数人、特に新人やgitに明るくない人がいるチームでのリポジトリ管理方法は、シンプルなのが良いと思います。

共有するコードが多い場合は一緒のリポジトリにすることも考えた方がいいかもしれませんが、たいていの場合、別々に管理するのがシンプルではないでしょうか。

APIのバージョンによる親和性についてリリース管理者の負担になりますが、チーム全体の負担を軽減することを考えれば、リポジトリ管理者が楽をするルールはなるべく少ないほうが良いように思います。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

シンプルな方が良いという意見には強く賛同します。gitを知り始めたところなので、いろんな機能を使いこなせば、あんなこともできる、こんなこともできるんではないかと、少し考え過ぎであったことを気づかせていただきました。
ありがとうございます。

Answer 4

まず、ブランチ戦略で有名な方針として、git-flowがあります。
＜他にもググってみて！＞

クライアントの変更でも、サーバの変更でも、インターフェイスの変更でも、都度featureブランチを作成して、整合性がとれだ段階で、developにマージします。
developからfeatureを選択的にブランチしたreleaseブランチを作り、バージョンタグを更新します。
releaseブランチでテストが通るとmasterにマージします。
このように、git-flowのブランチ戦略であればどのステージングであれ常に整合性のとれたコードが
取り出せます。

ブランチとは関係ありませんが、インターフェイスを変更したら、コンパイルエラーになるようにすれば確実になります。

あとは、タグを元に更新した方をデプロイするように自動化すれば完璧だと思います。

---

追記

読み返したら用語が多すぎてわかりずらいですね。すみませんでした。

言い直します。

毎回ブランチを作成するといいということです。subversionのブランチの場合、ブランチを作ると別のフォルダーに保管して、マージするときは変更点を上書きするイメージだと思います。gitの場合は変更点を管理するイメージなので、変更完了後、マージされたブランチはなくなると考えて下さい。

変更単位にブランチを切って、マージ後ブランチを閉じるので変更単位がクライアントどちらでもサーバ一緒くたにあつかって問題ありません。

バージョン番号はリリース時に更新します。どちらを更新したかで変えていけばいいのです。

DBMSやマルチプレイゲームのサーバなど複数のバージョンのサーバがあり、それぞれバージョンの合うクライアントを接続する場合は、バージョンごとにブランチを作成する必要があります。これも基本は同じですが、かなり複雑なブランチ戦略を必要としますので、お勧めしません。