Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。2,816件3517ソース管理、バージョン管理について知恵をお貸しください。結局のところユーザーごとにカスタマイズすることが多く、ソースの管理に手を焼いております。Foundationを利用し始めております。基本プロジェクトとしてベースとなるプロジェクトを作成し、それをユーザーごとに新しいプロジェクトとしてコピーした後にカスタマイズしております。しますと、当然ながらバグがあった場合にすべてのプロジェクトに手作業にてパッチ当て作業が発生しますので、ユーザー数手間がかかることになります。管理のしやすいプログラム構成の良い方法等がございましたらご教示いただけませんでしょうか?宜しくお願いいたします。個の銅バッジ他の回答も出なさそうですので、一旦承認してはいかがでしょうか?もし他にベストな回答が出たときには承認を付け替えることも出来ますので、よろしくお願いします。票45gitでお客さん毎にブランチを作ったこともありますが、10顧客の時点でギブアップでした。結論としては顧客ごとの管理は実は管理ではなく問題の先送りをしているだけで、技術的負債を積み上げるだけなのでやらない。ソースは一本だけで、顧客固有の機能はプラグインなどで実装する、となりました。コアのブランチ、カスタム機能のブランチ、さらにお客さん毎のブランチなどとしていれば、理論的には管理可能なのです。そのうち「取り急ぎ」のコミットが顧客ブランチにされるし、バグが見つかれば、他のお客さんの稼働中のコード全部の開発ブランチを作って、テスト&マージになり、その間に先の「取り急ぎコミット」がコンフリクトを起こしたりします。マージも毎回数百のコミットの検証をしないといけない。仮にうまく管理できていたとしても、先に稼働開始したv1.0のソースを1年後にいじるのは厳しいです。書類上のバグ管理ができていたとしても、自信を持ってマージ一発とはいかないです。ソース以外にもデータの移行もありますね。「管理が甘い」「数百コミット程度でギブアップはヘタレ」「ユニットテストをきちんと書いていれば問題ない」という意見もあるかもしれませんが、個人的にこう言う仕事のやり方はスケールしないし、管理に手間を掛けるのは生産的だと思えません。ウェブサービスの時代に逆行していると思います。従って最初の結論になりました。プラグイン化するとは結局内部のAPIの設計をすることで、APIのバージョンのメジャー番号が同じ(v1.x)時は下位互換性を担保します。すればお客さんの管理はv1系列、v2系列というメジャー番号だけで管理できますね。v1系列ならパッチは簡単にあたるけど、v1->v2は移行作業が必要とすぐわかります。個の銅バッジご回答ありがとうございました。うなずきながら拝読させて頂きました。固有機能はプラグインで実装、参考にさせてもらいます。貴重なご意見ありがとうございました。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。