Webシステムを作ったんだけど、クライアントの依頼によって機能追加して提供したい。こういうのを管理する時、どう管理すればいいの？Gitで初期バージョンのリポジトリ作成して、機能追加の依頼があればブランチしていくパターン？それともクライアント毎にリポジトリを作成してそこで完結するようなスタイルがいいの？
機能ごとに派生ブランチ切って開発終了したらMasterにマージしてデプロイすりええ。クライアント毎ってのはわからんけど、普通ならリポジトリ別にするのでは？
開発元のファイル類があるんだけど、それをリポジトリするんじゃなくて、クライアント毎（プロジェクトごと）にリポジトリ作るってこと？.ファイル構成で言うと/home/username/public_html/system_nameが開発しているWebシステムのあるディレクトリだとする。今までは機能追加をしたら/home/username/public_html/system_name_ecとかにしていた。（つまりディレクトリ分けして中身をコピー
そう。プロジェクトごとにリポジトリを作る。public_html内で機能のブランチごとにディレクトリ分ける必要ないし、プロジェクト間で共有したいならシンボリックリンクでいいのでは？
コアが変わったら派生システムも変更したいだろうから、サブツリーとかの方がお得だと思う。いずれにしても仕様がわかんないから、どこまでいっても一般論しか出ないと思う。
構成は上のコメに書いたような感じです。コア（上の例ではsystem_name）の派生システム（上の例ではsystem_name_ec）なんだけど、コア自体を変更したら、派生システムの方も変更する必要があって、ややこしくなってる。
コアの部分だけ分けるっていう運用が可能なら、バージョン管理上は一番手っ取り早いね。共用サーバーでないなら意外と簡単だよね。/home/core/app
クライアント毎にコアを変更するひつようがあるなら別リポジトリにしたほうがいいだろうね。出来ればコードは全クライアント共通で、クライアント別に必要な機能については設定ファイル一個いじればいいようにするのが理想的。
みんなの回答 3 件
機能ごとに派生ブランチ切って開発終了したらMasterにマージしてデプロイすりええ。クライアント毎ってのはわからんけど、普通ならリポジトリ別にするのでは？
コアが変わったら派生システムも変更したいだろうから、サブツリーとかの方がお得だと思う。いずれにしても仕様がわかんないから、どこまでいっても一般論しか出ないと思う。
クライアント毎にコアを変更するひつようがあるなら別リポジトリにしたほうがいいだろうね。
出来ればコードは全クライアント共通で、クライアント別に必要な機能については設定ファイル一個いじればいいようにするのが理想的。
関連するトピックス