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

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

ただいまの
回答率

90.49%

  • Git

    1335questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。

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

受付中

回答 4

投稿

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

z_9

score 15

Git初心者です。

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

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

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

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

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

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

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

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

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 4

+2

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

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

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/08/07 14:32

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

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

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

    キャンセル

+1

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

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

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

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

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/08/07 13:51

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

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

    キャンセル

+1

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

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

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2015/08/07 13:40

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

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

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

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

    キャンセル

-1

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

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

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

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


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

言い直します。

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

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

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

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

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

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

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

関連した質問

同じタグがついた質問を見る

  • Git

    1335questions

    Gitはオープンソースの分散バージョン管理システム(DVCS)です。