4

私は他の4人の開発者のチームに所属しており、GITを学び、中央リポジトリとしてgitflowモデルとgithubを使用しています。これまで、githubに中央リポジトリを作成しました。機能を作成し、それらを中央リポジトリにプッシュして、そこからプルして相互に変更を加えることができます。

すべての開発者はローカルマシンで作業しますが、開発、ステージング、本番の3つのサーバーをセットアップしています。

開発とは、誰もがお互いの変化を見ることができる場所であり、満足したらステージングに移行します。ここで、最終的にWebサイトを本番環境で公開する前に、すべてが正常であることを確認するためのテストが行​​われます。

Webサイトは現在完成しており、開発サーバーにリポジトリのクローンを作成し、すべてのWebサイトファイルをプルして、そこですべての変更を確認できるようにしました。ただし、現在、ステージングに展開し、最終的に本番環境に展開する必要があるかどうかはわかりません。

  1. 最初にローカルでリリースブランチを作成し、中央リポジトリにプッシュしますか？
  2. ステージングサーバーと本番サーバーに中央リポジトリのクローンを作成しますか？
  3. もしそうなら、私たちは彼の中央リポジトリからプルしますか、それとも本番サーバーでGITを使用するべきではありませんか？フックだけでなくrsyncの使用についても読んだことがありますか？！

誰かが次のステップを説明してくれるか、それを説明している場所を教えてください。それは本当に役に立ちます。

ありがとう

4

1 に答える 1

4

さまざまなサーバーへの展開、特にステージングと本番を担当する人が1人います。そうすれば、リリースブランチを作成するときに、このブランチがステージングサーバーにデプロイされます。リリースブランチが終了したら、マスターブランチを本番サーバーにデプロイします。

リポジトリをステージングと本番環境に複製できます。.gitディレクトリに適切なセキュリティがあることを確認してください（.htaccessはあなたの友達です:)）。これにより、開発者以外の人はそのディレクトリにアクセスできなくなります。

本番サーバーでgitpullを使用します。rsyncとフックについても読んだことがありますが、gitだけで問題なく動作します。

サーバーでgitを許可しないクライアントで作業しているときに、ftpを使用することがあります。githubにはgit-ftpというPyhtonプログラムがあり、 git-flowに対応するために少し調整しました。私はそのバージョンをgithubに置いていません、多分そうすべきです。

最初のコメントのフォローアップとして
ステージングおよび本番リリースを行う人は、自分のローカルマシンで次の手順を実行します。

git flow release start -F 1.0

バージョン番号を更新するなど、いくつかの作業を行います。githubに公開します

git flow release publish 1.0

ステージングサーバーの場合：

git pull origin release/1.0

ステージング期間が終了した後、ローカルマシンで

git flow release finish 1.0

本番サーバー上

git pull origin master
于 2012-11-16T14:32:53.197 に答える