7

私は現在、テクノロジー以外の小さな組織に勤務しており、組織の Web サイトのコーディングを担当しています。私はこの仕事を楽しんでおり、ウェブ開発で多くのことを学びましたが、誰かが私を助けてくれるか、少なくとも正しい方向に向けてくれることを望んでいるいくつかの問題に遭遇しました.

少し背景:

私が取り組んでいるサイトにはサブドメインがあり、それぞれに個別の WordPress がインストールされています。これは、コンテンツ (など) の更新を担当するタイプのユーザーにとって最も簡単な「バックエンド」管理パネルであるためです。

組織内で、私はマーケティング マネージャー (MM) の下で働いており、彼のスタイル ガイドとワイヤー フレームに従ってコーディングしています。

今年の初めから 1 つのサブドメインのみで作業を行ってきましたが、プロジェクトは比較的単純でわかりやすいものでした。ただし、最近、元のサブドメインが他のサブドメインにコピーされたため、ワークフローは少し複雑になっています。新しいサブドメインのそれぞれは、スタイルシートのマイナーな編集を受け取ります (たとえば、背景の異なる写真、あちこちでわずかに異なる色など)。

問題：

現時点では、すべての異なるサブドメインを管理することは「耐えられる」ものでしたが、CEO が最終製品を見た今、MM が要求したわずかな逆転は、現時点でラクダの背中にブレーキをかけているストローでした。スタイルシートのリバートで私が抱えている問題は、ある週、CEO が "X" を変更するのが好きだと述べ、次に MM として私がサイトを変更し続け (現在は "Z" に)、別の週に次のように述べるということです。彼は、「X」を「W」に変更することを望んでいますが、「Y」で行われたほとんどの変更を保持します。

私が探しているのは、次のことを可能にするものです。

  • ファイルの変更の追跡
  • 行った変更を元に戻す (または、'e' から 'a' に戻すが、'b' と 'c' の変更を含む)
  • 必要なファイルをそれぞれの WP テーマのインストールに簡単にアップロードする

これらの問題に対処するのに近いものはありますか? もしそうなら、何？

助けてくれてありがとう！

PS - 私は現在 Git を学んでおり、「ファイルの変更の追跡」をうまく行っているようです。ただし、変更を元に戻すビットについてはまだ学んでいません。最後のポイントとして、ファイルをフォルダーに自動的にアップロードするシェル スクリプトを作成することを考えています。Gitもこれを行いますか？

補遺 (alexbbrown)

私も同様の問題を抱えていました: バージョン管理されたコア (svn を使用) にさまざまな拡張機能をインストールした mediawiki のカスタム バージョンを実行しました。各拡張機能には、confit ファイルのセクションが必要でしたが、confit ファイルには、いくつかの展開ごとにローカル構成も必要でした。インクルードを使用して実装することもできましたが、バージョン管理されません。毎回ブランチをリベースするのは面倒です。git で適切な回答をすると +50 経験値。

4

3 に答える 3

5

Git を使用すると、必要なことを実行できます。

私の経験では、これによりサブドメイン間で変更を最も簡単な方法で移動できるため、各サブドメインをブランチとして含む単一のリポジトリを使用します。

ここでは、ブランチが 1 つあり、それぞれに独自のローカル変更を維持するcoreいくつかのブランチがある構造を想定しています。また、コアの変更を行うブランチがsubdomainXあると仮定します。develop

実行できるようにする必要があるいくつかの重要なアクションがあります。

すべてのサブドメインに適用する必要がある開発に変更を加えました

変更を開発からコアにプルする

git checkout core
git merge develop

サブドメイン ブランチに変更を適用します。サブドメインごとに実行

git checkout subdomainX
git rebase core

または、リベースよりもマージを好む場合（このケースは非常に面倒です-しかし、他の人は同意しないかもしれません）

git checkout subdomainX
git merge core

多くのサブドメイン ブランチがある場合は、これをスクリプト化します。これにより、名前に「サブドメイン」を含むすべてのローカル ブランチが にリベースされcoreます。

for i in $( git branch | cut -b 3- | grep subdomain ) ; do
   git checkout $i
   git rebase core
end

他のすべてのサブドメインにプルしたいサブドメインに変更を加えました

最初に、適用する変更の SHA が必要です (まだチェックインしていない場合はチェックインします)。

次に、その変更だけを開発ブランチにプルしてから、core

git checkout develop
git cherry-pick THE_SHA_OF_YOUR_CHANGE
git checkout core
git merge develop

次に、上記のスクリプトを実行して、すべてのサブドメイン ブランチに変更をプッシュします。

どこでも元に戻す必要があるいくつかの変更を git しました

git checkout develop
git revert THE_BAD_SHA
git checkout core
git merge develop

次に、スクリプトを実行します。

2 つのサブドメインを比較したい。

2 つのブランチが呼び出されsubdomainA、subdomainB実行できる場合

git diff subdomainA subdomainB

subdomainA にある変更を確認したいがcore、ローカルの変更は確認したくない。

ファイルへの変更は、次の方法で取得できます。

git diff subdomainA core

変更セットの実際のリスト

git log core..subdomainA

取り扱いディストリビューション

これを処理するには、次の 2 つの方法があります。

  • 各ブランチのファイルをコピーする小さなスクリプトを作成します (rsync既存のファイルのコピーを避けるために使用します)。これの利点は、高速であり、デプロイ先のサーバーで git を必要としないことです。
  • 各サブドメイン ファイルを git リポジトリのコピーにします。次に、スクリプトは各ボックスに ssh し、ファイルをプル/マージします。これの利点は、ライブ サーバーで変更を行い、それらをリポジトリに簡単に戻すことができることです。bare欠点には、すべてのリポジトリのオリジンとしてリポジトリを設定する必要があり、より多くのスペースが必要になることが含まれます。(ただし、この場合の利点は欠点を上回り、私が使用するのはこのアプローチです)。
于 2012-08-30T05:56:15.000 に答える
0

git を実装するための良いアイデアです。開発プロセスに不可欠なツールであることは間違いありません。おっしゃったように、git は「ファイルの変更の追跡」の問題を確実に解決し、他の問題も解決できます。git には優れたリソースがたくさんありますが、git とは何か (およびそうでないもの) とそのしくみについてよりよく理解したい場合は、Git を下から上に読むことをお勧めします。

変更を元に戻すことは、git を使用して非常に簡単に行うことができます。最初に、元に戻したいコミットを見つけるために、おそらくコミットの履歴を表示する必要があります。これは、git logコマンドを使用するだけで簡単に実行できます (git によって追跡されるディレクトリにいることを確認してください)。詳細については、こちらをご覧ください。元に戻したいコミットがわかったら、その特定のコミットに関連付けられたハッシュを利用して、コミットの一意のハッシュがgit reset --hard 6e3e02050aどこにあるかを実行するだけです。6e3e02050aあなたがそれでできるいくつかのクールなことを含む詳細情報は、こちら. これにより、追跡されているすべてのファイルがその特定のコミットにすぐに戻ります (個々のファイルも元に戻すことができます)。

信じられないかもしれませんが、git は必要なときにコードをサーバーに自動的にプッシュするのにも役立ちます。これはもう少し高度で、post-receive hook. これにより、開発サイトから本番サイトへの展開が容易になります。私が言及したように、これはより高度なので、ここではその詳細には触れませんが、wp.tutsplus.comで必要なものを正確に含む優れたチュートリアルがあります(具体的にはステップ 4)。

単一のインストールではこれらすべてを簡単に実行できますが、多くのサイトがすべて同じ開発プロセスに関連付けられている場合は、少し複雑になります。繰り返しますが、git にはいくつかのオプションがあります。

この時点で、あなたは について少し知っているかもしれませんがbranching、そうでない場合でも、そこにはたくさんのリソースがあります。ブランチを使用すると、メインの「マスター」ブランチから探索的プロジェクトや完全に別のプロジェクトに移行することができます。これは、すべて同じマスター コードに基づいているすべての異なるインストールで、まさにあなたが望んでいることのように思えます。分岐のもう 1 つの利点は、必要に応じて、ブランチをマスターに変更を加えて最新の状態に保ち、マージして戻すことができることです。別のオプションはクローン作成です。これは、現在持っているものから分岐するだけでなく、実際にリポジトリ全体をコピーしているという点で異なります。詳細については、こちらをご覧ください。

すべてをセットアップするための最良の方法を見つけるには時間がかかるかもしれませんが、何らかのプロセスが整ったら、git が提供するオプションと安心感に非常に満足することを保証できます。

于 2012-08-30T04:34:27.393 に答える