用于网站暂存的 Git 接收后挂钩
我正在尝试设置 Git 来暂存我的网站,以便我可以 git pull
使当前版本在本地运行,然后 git push
将更改推送到远程服务器。我已经将其设置为按照我想要的方式工作,但是在推送后,我必须手动运行 git checkout -f 或 git reset --hard HEAD< /code> 在远程服务器上。
我尝试将它们放入 shell 脚本中作为服务器上的 post-receive 挂钩,但它似乎没有任何效果。我知道脚本正在运行,因为我在推送后看到“更改已推送到服务器”。这是接收后挂钩:
#!/bin/sh
git reset --hard HEAD
echo "Changes pushed to server."
I'm trying to set up Git for staging my website so that I can git pull
to get the current version to work on locally and then git push
to push the changes to the remote server. I've got it set up so that it works the way I want it to, but after I push, I have to manually run git checkout -f
or git reset --hard HEAD
on the remote server.
I've tried putting these into a shell script as the post-receive hook on the server, but it just doesn't seem to have any effect. I know that the script is running because I'm seeing "Changes pushed to server" after I push. Here's the post-receive hook:
#!/bin/sh
git reset --hard HEAD
echo "Changes pushed to server."
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
您的问题的答案在这里:http://toroid.org/ams/git-website-howto
简而言之,您要做的就是向裸存储库添加一个“分离的工作树”。通常,您认为工作树包含
.git
目录。根据定义,裸存储库没有工作树,但只要它位于与裸存储库不同的目录中,您就可以创建一个工作树。post-receive 挂钩只是一个简单的 git checkout -f ,用于将存储库的 HEAD 复制到工作目录中。 Apache 使用它作为其文档根目录,您就完成了。每当您推送到裸存储库时,Apache 都会立即开始为其提供服务。
我通常使用它来自动推送到临时服务器,以查看“真实”环境是否会影响我的更改。部署到实时服务器是一个完全不同的故事。 :-)
The answer to your question is here: http://toroid.org/ams/git-website-howto
In short, what you want to do is add a "detached work tree" to the bare repository. Normally you think of your work tree as containing the
.git
directory. Bare repositories do not have a work tree by definition, but you can create one as long as it's in a different directory than the bare repo.The post-receive hook is just a simple
git checkout -f
to replicate the repository'sHEAD
into the work directory. Apache uses that as its document root, and you're all set. Any time you push to the bare repository, Apache will immediately start serving it.I generally use this to automatically push to a staging server to see if the "real" environment will puke on my changes. Deploying to the live server is a completely different story. :-)
2015 年 3 月更新
正如我在“将更改推送到远程存储库时这个 Git 警告消息是什么?”中提到的,您实际上现在可以直接推送到非裸存储库(Git 2.3.0+,2015 年 2 月):
这将使您避免任何接收后挂钩。
(原始答案:2010 年 10 月)
GitFAQ 建议 < a href="http://sitaramc.github.com/concepts/bare.html#all_about_bare_repos_what_why_and_how_to_fix_a_non_bare_push" rel="nofollow noreferrer">非裸仓库此更新后挂钩:
(它可能会为您提供有关挂钩执行中实际发生的情况的更多线索。请注意,这是更新后挂钩,而不是接收后)
为此,您仍然需要专门允许将更改推送到使用以下配置设置之一来当前分支:
或
Update March 2015
As I mentioned in "What is this Git warning message when pushing changes to a remote repository?", you actually can push directly to a non-bare repo now (Git 2.3.0+, February 2015) with:
That would allow you to avoid any post-receive hook.
(Original answer: Oct 2010)
The GitFAQ recommends for non-bare repo this post-update hook:
(it might give you more clue as to what is actually going on in the hook execution. Note this is a post-update hook, not a post-receive)
For this to work, you would still need to specifically allow pushing changes to the current branch by using either one of these configuration settings:
or
我有完全相同的问题。在对此链接的回复中: http://toroid.org/ams/git-website-howto -以下命令已完成此操作:
我们错过了首先配置这些内容的
sudo
权限。I had the exact same issue. In a reply to this link: http://toroid.org/ams/git-website-howto - The following command has done it:
We missed a
sudo
permission first configured the stuff.VonC 脚本的修复版本对我有用(绝对不能保证)。
Fixed version of VonC's script, works for me (absolutely no guarantees).
用于设置此 git 部署的简单脚本:
准备接收后挂钩:
允许推送到此存储库,尽管它不是裸露的:
Simple script for setting this git deployment:
Preparing post-receive hook:
Allowing push into this repository, though it is not bare:
我只是猜测,但这可能是一些权限问题(需要完整路径?
cd
?)。检查日志文件中到底发生了什么。然而,通过 git 发布文件始终只是发布过程的一项任务。您通常需要复制一些文件、删除其他文件、设置、更新权限、生成文档等。
对于复杂的解决方案,构建脚本可能比任何 git hook 更好。可以很好地处理这些任务的工具:
(我意识到这不是您期望的答案,但作为评论发布太长了)
I'm just guessing, but this may be some permission issue (full path needed?
cd
?). Check what is really happening in the log files.However publishing the files via git is always just one tasks of the publishing process. You usually need to copy some files, delete other, setup, update permissions, generate docs etc.
For a complex solution a build script might be better than any git hook. Tools which can handle those tasks very well:
(I realize this is not the answer you are expecting, but it's too long to post as a comment)