1

git を使用した Web 開発のワークフローに苦労して整理した後、最後の 1 秒でステージング サーバーを追加することになりました。私たちはローカルで開発/テストし、レポにプッシュします。他の部門の人々が何かを壊すことなく遊んだり、新しいことを試したりできるように、その間にサンドボックスが必要です。

リモート リポジトリには、マスターと開発の 2 つの長期実行ブランチ (nvie のブランチ モデルの精神による) が必要です。

1 つのリポジトリにプッシュし、develop ブランチを test.site.com docroot にチェックアウトし、準備ができたら、develop を master にマージし、master を site.com docroot にチェックアウトできるようにする必要があります。

では、サーバー上で...

git init
git add .
git commit -m "Initial commit"
git checkout -b "develop"

そして、私たちのローカルマシンでは...

git clone user@site.com:/repos/repo1.git
???
git push origin/develop (??? Updates test.site.com docroot)

サーバーに戻ってコードをライブにする

git checkout "master"
git merge develop (??? Updates site.com docroot)
git checkout -b "develop"

そして地元で

git pull

疑問符または別の提案を歓迎します。

編集： これまでのところ、いくつかの答えを試しています。その間に完全にハックなアイデアを思いついたので、共有したいと思いました：

それらすべてを支配する 1 つの post-receive フック。

ベアレポのクローンを作成し、開発を追跡します。開発をオリジン/開発にプッシュします。

受信後 - GIT_WORK_TREE を test.site.com に設定し、チェックアウト -f 開発します

コミット メッセージに「merge_master」が含まれている場合、GIT_WORK_TREE を site.com docroot に設定します。

git checkout master
git merge develop  
git checkout -f master (this would be for hotfixes)

マスターを開発にマージし、ローカルでプルします

ほこりが落ち着いたら、difflog で電子メールを送信し、手を絞って、強いものを一口飲みます。

それはいくつの異なる方法で壊れる可能性がありますか?

4

2 に答える 2

2

gitでは、通常、チェックアウトのあるリポジトリにプッシュすることはありません。まったく。チェックアウトされたブランチにプッシュできない場合を除いて、1つにプッシュできますが、通常はプッシュしないでください。主に、物事を明確に分離し、Webサーバーが壊れて修正が必要になった場合に中央リポジトリを混乱させないようにするためです。

したがって、ベア（作業ツリーのないリポジトリに使用される用語）の中央リポジトリが必要です。誰もがそのリポジトリを使用します。内部ネットワーク上に存在し、パブリックサーバーまたはテストサーバーのdocrootに存在しないようにする必要があります。実際、どちらのサーバーにも配置せず、別の（場合によっては仮想）マシンに配置することを強くお勧めします。

これで、Webサーバーができました。それらは、作業コピー、またはを使用して作成されたエクスポートgit archiveであり、cronによって更新するかpost-update、中央リポジトリにフックすることができます。

作業コピーはサーバー上およびサーバーgit fetch central-repo-url master上で更新されます（他の回答で提案されているフェッチ+リセットの方が、変更がないことが確実であるため、おそらくより良いでしょう）。site.comgit pull central-repo-url developtest.site.com

エクスポートは、zipまたはtarパックを取得しgit archiveて解凍することで更新されます。もう少し手間がかかります。

Cronはコマンドを定期的に実行するだけです。設定は簡単ですが、プッシュとサーバーに表示されるコンテンツの間に遅延があるという欠点があります。

post-updateフックの設定はより複雑ですが、その遅延はありません（データのダウンロードにも時間がかかるため、明らかに遅延があります）。基本的に、更新を実行するためのスクリプトを作成します。このスクリプトは、サーバー上のsshまたはWeb要求のいずれかによってトリガーできます。中央リポジトリにスクリプトを配置hooks/post-updateするよりも、サーバー上でスクリプトをトリガーします。それらにパラメータを与える方法はないはずであり、セキュリティ上の理由から、メカニズムはそれらのスクリプト以外のコードの実行を許可してはなりません。どのブランチがプッシュされたかを調べ（どこにあるかについてはgit docを参照）、正しいサーバーのみをトリガーすることで、フックをより高度にすることができます。

を更新し（ただし、スクリプトを介して間接的に）、コードをライブにするよりも（開発マシンで、git push origin developサーバーで作業することはありません！）test.site.com

gitチェックアウトマスターgitマージ開発gitプッシュオリジンマスター

最後のコマンドはsite.com、スクリプトを介して間接的に更新されます。

于 2011-11-30T15:25:43.197 に答える
1

私の提案は、両方のdocrootをgit作業コピーにすることです。

この後、2つのオプションがあります

  1. cronジョブgit fetch development-repo; git reset --hard development-repo/branchに両方のようなことをさせます。私は以前にこのようなことをしました、そしてハードリセットは絶対必要です：それはどういうわけかあなたのdocrootに忍び込んだランダムな変更を無効にします。
  2. 誰かpost-updateが何かをプッシュするたびに、開発リポジトリにフックして上記を実行します。残念ながら、これの実用的な例は手元にありません。
于 2011-11-30T15:11:48.983 に答える