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分支上repoRemote，问题就解决了，而不是demo。为什么会这样？

4

6 回答 6

3

Edit, Dec 2016: people are still finding this old answer, and now, 3 years later, I truly understand what the real issue is. The problem occurs when you use a post-receive hook to deploy multiple different branches. If you only ever deploy one branch from a bare repository, you will have fewer problems. Git keeps evolving and the "best" solution for automatic deployment of several branches may vary depending on which Git version you have. See also Git post-receive deployment stops working at random points.

(Original answer below line.)

I've found that git checkout -f always needs a branch name; allowing it to use HEAD in bare repositories is not very predictable.

You may also run into issues with the index (git will write one in the bare repo, but it gets confused at times). It works best to git checkout -f deployment-branch into a new, fresh, empty directory. (It should work to set an index file per deployment-branch, I've just never gotten around to experimenting with this.)

If your bare repo will be fairly active on other branches than the one(s) used for deployment, it's a good idea to wrap the code with fancier shell-scripting that checks whether the deployment branch in question has actually been changed. That is, if someone updates web-devel, there's no point re-re-re-deploying deployment-branch, which they did not update this time.

于 2013-11-12T12:10:28.803 回答
1

从上面关于针对特定分支的可靠性的评论中，我发现了这个要点，它从 post-receive 挂钩中针对 master 分支。

#!/bin/bash 
set -eu

TARGET="/deployment-location-here"
GIT_DIR="/trigger-location-here"
BRANCH="master"

while read oldrev newrev ref
do
        # only checking out the master (or whatever branch you would like to deploy)
        if [[ $ref = refs/heads/"$BRANCH" ]];
        then
                echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
                git --work-tree="$TARGET" --git-dir="$GIT_DIR" checkout -f
        else
                echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
        fi
done
于 2019-11-13T04:02:15.960 回答
1

在 Git 2.13（2017 年第二季度）中确定并修复了导致接收后挂钩问题的另一个可能原因：如果GIT_WORK_TREE设置为无效路径。

请参阅Johannes Schindelin ( )的提交 ce83ead和提交 aac3eaa（2017 年 3 月 8 日） 。（由Junio C Hamano 合并——在提交 ba37c92中，2017 年 3 月 13 日）dscho
gitster

示例（仅在 Git 2.12 上会崩溃）

GIT_WORK_TREE=/.invalid/work/tree &&
export GIT_WORK_TREE &&
git rev-parse
# dies with error code 128

该错误是在 Git 2.12 中引入的。

于 2017-03-14T22:21:36.517 回答
0

我在我的网站上这样做：

#!/bin/sh
unset $(git rev-parse --local-env-vars)
cd /var/www/example.com
git pull
于 2013-11-12T10:25:30.037 回答
0

使脚本可执行：

chmod +x .git/hooks/post-receive
于 2013-11-12T12:13:42.017 回答
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 回答