2

私は自分のウェブサイトに更新を送信するためにこのアプローチを実装しています:

プッシュ先のベアリポジトリを作成

$ mkdir website.git && cd website.git
$ git init --bare

そして、次のフックを追加しました:

$ mkdir /var/www/example.com
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/var/www/example.com git checkout -f
$ chmod +x hooks/post-receive

ローカル リポジトリから website.git にプッシュすると、更新は正常に機能します。しかし、ファイルは に追加されません/var/www/example.com。ここで何が問題なのかを調査するにはどうすればよいですか? ログか何か？

編集 - - - - - - - - - - -

ではなく、masterブランチにプッシュすると、問題は修正されます。どうしてですか？repoRemotedemo

4

6 に答える 6

3

編集、2016年12月: 人々はまだこの古い答えを見つけています.3年経った今、私は本当の問題が何であるかを本当に理解しています. post-receive フックを使用して複数の異なるブランチをデプロイすると、問題が発生します。ベア リポジトリからブランチを 1 つだけデプロイする場合は、問題が少なくなります。Git は進化し続けており、複数のブランチを自動デプロイするための「最適な」ソリューションは、使用している Git のバージョンによって異なる場合があります。Git post-receive デプロイメントがランダムなポイントで機能しなくなるも参照してください。

（元の回答は行の下にあります。）

git checkout -fには常にブランチ名が必要であることがわかりました。ベアリポジトリでの使用を許可することHEADは、あまり予測できません。

また、インデックスの問題が発生する可能性もあります (git はベア リポジトリにインデックスを書き込みますが、時々混乱します)。git checkout -f deployment-branch新しい、新鮮な、空のディレクトリに移動するのが最適です。(デプロイメントブランチごとにインデックスファイルを設定することはうまくいくはずです。私はこれを試したことはありません。)

ベア リポジトリが、展開に使用されるブランチ以外のブランチでかなりアクティブになる場合は、問題の展開ブランチが実際に変更されたかどうかを確認する、より手の込んだシェル スクリプトでコードをラップすることをお勧めします。つまり、誰かが更新した場合、今回更新しなかった をweb-devel再再展開しても意味がありません。deployment-branch

于 2013-11-12T12:10:28.803 に答える
0

私は自分のサイトでこれを行います：

#!/bin/sh
unset $(git rev-parse --local-env-vars)
cd /var/www/example.com
git pull
于 2013-11-12T10:25:30.037 に答える
0 
cd .git/hooks
mv post-receive post-receive-inner

新しいを作成しますpost-receive：

#!/bin/bash
set -x
./post-receive-inner "$@" 1>/tmp/git.log 2>&1

この実行可能ファイルを作成して再試行すると、結果は次のようになります。/tmp/git.log

于 2013-11-12T09:12:40.927 に答える