2

私のオフィスには、自家製のコンテンツ管理システムがあります。ゆっくりと、しかし着実に、CMSの60のインスタンスをセットアップしました。はい、私たちは大企業です。NGO。

ほとんどのオフィスでは、現在の形式でCMSを使用しています。一部のオフィスでは、色、フォント、基本的にスキンをカスタマイズしました。他のいくつかは、時々私たちがコアに持ち込む新しい機能を構築します。私はソースをより効率的に管理する任務を負っています。

たとえば、私は「コア」を管理しており、オフィス「A」とオフィス「B」があります。Office Aは色のみをカスタマイズしますが、Office Bはコアにいくつかの変更を加え（それほど多くはありません）、コードはコアとは異なります。「コア」だけを担当したいです。新しい機能を開発するときは、（受け入れ次第）これらの変更を他のオフィスと同期させたいと思います。

マスターとマージされないブランチを作成することを考えました。しかし、私がマスターで行った変更はブランチに行くことができませんか？私が取るべきアプローチは何ですか、そして私は何に注意すべきですか？

4

1 に答える 1

1

これは1つの可能なアプローチです。

マスターに適用するオフィスブランチのコミットについては、マスターの上にチェリーピックするだけです。自分が何をしているのかがわかっている場合は、マスターの上に一連のコミットをリベースすることもできます。

逆に言えば、マージは確かに適切です。マスターをオフィスブランチにマージする必要がありますが、その逆はできません。コアの変更を適用するオフィスブランチをチェックアウトしますgit merge master。これはマージを試みますが、オフィスブランチにのみ影響します。マスターブランチは移動されません。

また、デフォルトの色のリストを提供することを検討し、それらをオーバーライドするために新しいファイルを作成できるようにすることもできます。.gitignoreこれらの変更がGitリポジトリにコミットされないように、オーバーライドファイル名をリストします。マスターのデフォルトを更新してそれをオフィスブランチにマージすることはできますが、展開されたコピーを除いて、オフィスの色の上書きは表示されません。

于 2012-11-09T03:34:25.043 に答える