1

私が今やりたいのは、本番サーバーのプライベートリポジトリをアプリのwwwフォルダー(例:/var/www/app.com/web/)に初期化し、それをステージングリポジトリとしてテストサイト(例: :/var/www/test.com/web/app.com/)そして最終的にステージングからローカルにクローンを作成してコードを操作します。

私はそれを正しい方法で計画していますか?

「gitserver」の設定とプライベートリポジトリの初期化について詳しく知るために、これらのチュートリアルに従っています。

最後の質問ですが、成功したGit分岐モデルに関するこのチュートリアルはどこに適用されますか?メインのプライベートリポジトリ(本番サーバー)、ローカル、または混合?まだ完全には読んでいません。できるだけ早く読みます。

編集:

  • 重要な場合は、ISPConfig構成を実行しているサーバーでそうしようとしています。
  • 「より健康的な」方法があれば、上記のように働く/行動する必要はありません...それについて学んでうれしいです。

このhttp://www.howtoforge.com/the-perfect-subversion-server-debian-lenny-ispconfig-3とこのhttp://www.howtoforge.com/installing-subversion-and-configuring-access-through-異なるプロトコル-on-ubuntu-11.10からGITバージョンは、私がちょっと考えていたものです

4

2 に答える 2

5

私はそれを正しい方法で計画していますか?

カスケードリポジトリは非常に複雑に聞こえ、正常ではありません。

コミットしているベアgitリポジトリのクライアント/サテライト/子のチェックアウトを検討してください。ステージングと本番インストールは、特定のブランチの読み取り専用チェックアウトである必要があります。おそらく、git-flowに精通している可能性があります(ほとんどすべてのgit質問がそれにリンクしているためです。この質問も例外ではありません)。ブランチを設定して、適切にチェックアウトします。

Gitサーバーのセットアップ

このチュートリアルは、おそらくあなたが従う必要がある唯一のチュートリアルです。

/home/gitにホームを持つgitユーザーをセットアップし、そこにリポジトリを作成する/home/git/project.git場合、絶対パスは必要ないことに注意してください。つまり

(server) $ cd /home/git
(server) $ mkdir project.git
(server) $ cd project.git
(server) $ git --bare init

次に、必要な場所で:

(home) $ git clone git@server:project.git

もちろん、gitリポジトリを好きな場所に配置し、gitユーザーのホームディレクトリ(in /etc/passwd)を変更して同じことを実現することもできます。

プッシュで更新

リポジトリにプッシュするたびにチェックアウトを更新する場合は、受信後のフックが必要です。まず、自分自身を正しく設定します。

(server) $ cd /var/www/app.com/web/
(server) $ git clone -b production-branch /home/git/project.git . # it's local - use a file path
(server) $ cd /var/www/test.com/web/app.com/
(server) $ git clone -b staging-branch /home/git/project.git .

次に、/ home / git / project.git / hooks/post-updateを作成します。

cd /var/www/test.com/web/app.com
git --git-dir /var/www/test.com/web/app.com/.git pull #> /dev/null 2>&1 & #uncomment after testing

確認しておいて:

  • フックファイルは実行可能であり、gitが所有しています
  • Gitは(また)チェックアウトされたファイルの所有者と同じグループに属します。そうでない場合、プッシュするとパーミッションエラーが発生します

上記のように、コマンドの出力はプッシュするたびに送信されます。これにより、プッシュが遅くなります。正しく機能することが確実な場合は、バックグラウンドで実行できます。ステージングチェックアウトがすべてのプッシュをプルしていることは問題ではありません-それが指しているブランチに変更がない場合、それは何もしません。

ライブサイトを自動的に更新することはおそらく良い考えではありません。その代わり

(home) $ git checkout production-branch
(home) $ git merge staging-branch
(home) $ git push # updating production-branch
(home) $ git checkout feature/i-was-working-on-this
(home) $ ssh server 'cd /var/www/app.com/web/; git pull'
# Manual Post update checks

これを自動的に行い、たとえば更新によって本番サイトが使用できない状態になった場合は、わからない可能性があります(「本番サイトがオフラインです」というpingdomアラートが表示されるまで)。かなりのテストカバレッジと自動展開プロセスがある場合は、ライブサイトの更新を自動化しても安全ですが、実行する前に歩いてください:)。

ダイレクトプッシュ

あなたが設定した場合、あなたが本当に裸ではないチェックアウトにプッシュしたい場合はできます

[receive]
    denyCurrentBranch = ignore

プロジェクトの.git/configファイルで、作業コピー(iirc)も更新する必要のあるローカル変更がない場合。

于 2012-03-21T23:57:10.620 に答える
2

それは良い考えですが、もう少し作業が必要です。

post-updateチェックアウトされたブランチがプッシュされたときに実行するフックを定義git reset --hardし、チェックアウトされたブランチにプッシュすることに対するデフォルトのチェックを無効にすることによって支援しない限り、Gitは非ベアリポジトリにプッシュするときに作業コピーを更新しません(私はしません正確なオプションを覚えておいてください。git-configのマニュアルページを見てください)。

これを行うgit reset --hardと、ローカルの変更が取り消されることに注意してください。ローカルの変更を保持するようにフックを作成するのは少し注意が必要ですが、実行することもできます。ただし、本番サーバーでローカルに変更を加える必要はありませんよね?

適切なフックを配置すると、サーバーの数が少ない場合の小規模なセットアップに非常に適したワークフローになります。

大規模なセットアップの場合、別のサーバーにベアリポジトリがあり、フックにより、git pullを使用して本番リポジトリでが実行されssh triggerます。利点は、サーバー上の中央リポジトリに外部からアクセスできないため、セキュリティを強化できることです。

于 2012-02-24T14:00:23.217 に答える