blocks|key|3719097|text|如果走这条路，我会建议你拉而不是推。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3719098|始终拉出成品，不要在实时服务器上进行合并，因为如果存在冲突，您将争先恐后地修复它们。在您的测试环境中执行所有合并等操作。一旦一切正常，将完成的结果推送到生产分支的‘裸’代码库中，然后从生产机git+pull中进行推送。|offset|length|style|CODE|3719099|是的，这可能是另一个失败点，但我认为好处大于坏处。|3719100|entityMap^0|0|2N|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I would recommend pulling rather than pushing if going this route. 

Always pull the finished product and do not do merges on the live server, for if there are conflicts you will be scrambling to fix them. Do all your merging, etc on your testing environment. Once all is good there, push the finished results to your 'bare' repo for the production branch and then from the production machine <code>git pull</code> from it.

Yes it could be another point of failure however I think the benefits outway the cons.

blocks|key|1648463|text|VCS不应该是一个部署工具(参见Using+git+below+web+root+in+production.)：一个文件(用git+archive创建)的简单ftp就足够了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1648464|如果你想使用Git，在服务器端使用一个空的repo来推送，并使用一个post-receive+hook来更新一个代表你的站点的工作树。|1648465|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/3144670/using-git-below-web-root-in-production/3144865#3144865|1|http://progit.org/book/ch7-3.html^0|1R|B|G|13|0|0|Y|C|1B|4|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

A VCS isn't supposed to be a deployment tool (see <a href="https://stackoverflow.com/questions/3144670/using-git-below-web-root-in-production/3144865#3144865">Using git below web root in production.</a>): a simple ftp of one file (created with <code>git archive</code>) would be enough.

If you want to use Git, use a bare repo on the server side to push to, and a <code>post-receive</code> <a href="http://progit.org/book/ch7-3.html" rel="nofollow noreferrer">hook</a> to update a working tree which would represent your site.

blocks|key|28067|text|听起来您是脚本化部署的候选者。我强烈建议研究一下Capistrano和Webistrano。使用这些工具，您可以轻松地从公开可用的git存储库进行部署，并且只更新服务器上需要的代码。存储库的缓存副本保存在服务器上，因此您只传输更改集。我提到的两个工具还允许您轻松地回滚更改，管理数据库迁移等。Webistrano本质上是Capistrano的web前端，Capistrano是一块ruby+gem。我也听说过关于Vlad的好消息，但我对它不是很熟悉。祝你好运。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|28068|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/capistrano/capistrano|1|https://github.com/peritor/webistrano^0|O|A|0|Z|A|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

It sounds like you are a candidate for scripted deployments. I would highly suggest looking into <a href="https://github.com/capistrano/capistrano" rel="nofollow">Capistrano</a> and <a href="https://github.com/peritor/webistrano" rel="nofollow">Webistrano</a>. With these tools, you can deploy from a publicly available git repo easily and update only the code necessary on the server. A cached copy of the repo is held on the server, so you are only transmitting the change sets. The two tools I mentioned also allow you to easily roll back changes, manage database migrations, etc. Webistrano is essentially a web front-end to Capistrano, which is a ruby gem. I've also heard good things about Vlad, but I'm not as familiar with it. Best of luck.

blocks|key|2178260|text|我这样把我的本地开发“推”到Live+Server上：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2178261|1.-在服务器.git/hooks/post-receive上配置一个钩子|offset|length|style|BOLD|2178262|++including+this+lines:|code-block|syntax|javascript|2178263|+++++git+pull
+++++git+reset+--hard|2178264|警告:+reset+--hard将删除活动工作区上的所有更改。(见下文)|2178265|2.-授予文件的可执行权限|2178266|+chmod+%2Bx+.git/hooks/post-receive|2178267|3.-允许直播服务器上的非裸仓库接收推送|2178268|+git+config+receive.denyCurrentBranch+ignore|2178269|我处理我的本地副本(用于开发)，它是直接从实时服务器克隆的。和部署，只需|2178270|+git+push+|2178271|为了避免冲突，我有这样的约定:总是在推送之前拉，从不在活动站点上工作，或者在服务器上提交。|2178272|我希望你会发现这个方法很有用。|2178273|entityMap^0|0|7|N|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@$D|1A|E|1B|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|1C|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|J|7|1D|8|@]|9|@]|A|$K|L]]|$1|O|3|P|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1G|8|@]|9|@]|A|$K|L]]|$1|U|3|V|5|6|7|1H|8|@]|9|@]|A|$]]|$1|W|3|X|5|J|7|1I|8|@]|9|@]|A|$K|L]]|$1|Y|3|Z|5|6|7|1J|8|@]|9|@]|A|$]]|$1|10|3|11|5|J|7|1K|8|@]|9|@]|A|$K|L]]|$1|12|3|13|5|6|7|1L|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1M|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|17|$]]

I "Push" my local development to the Live Server this way:

1.- Configure a hook on the server
 .git/hooks/post-receive 
 including this lines:

<pre><code> git pull
 git reset --hard
</code></pre>

Warning: reset --hard will remove any changes on the live workspace. (See below)

2.- Give Executable rights to the file

<pre><code> chmod +x .git/hooks/post-receive
</code></pre>

3.- Allow the "non-bare" repository on the live server to receive the Push

<pre><code> git config receive.denyCurrentBranch ignore
</code></pre>

I work on my local copy (for development), which was cloned directly from the live server.
and deploy by just

<pre><code> git push 
</code></pre>

In order to avoid conflicts I have the convention of:
 Always Pull before pushing
 Never work on the live site or commit on the server.

I hope you find this method useful.

My partner and I have been dabbling with the idea of pushing and pulling from a repo that affects files viewable by the general public as opposed to storing the repos in a hidden location and just FTPing files when we feel they're good to go. While being able to directly push to the "live site" would be extremely convenient, I'm wondering what negative repercussions (if any) this would incur. 

Thanks a lot!

Git "Live Server" Best Practices

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我和我的合作伙伴一直在尝试从存储库中推送和提取会影响公众可查看的文件的想法，而不是将存储库存储在隐藏的位置，并在我们认为可以使用它们时只存储FTPing文件。虽然能够直接推送到“活动站点”将是非常方便的，但我想知道这会引起什么负面影响(如果有的话)。非常感谢!

问Git "Live Server“最佳实践
EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Git "Live Server“最佳实践EN

回答 4

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Git "Live Server“最佳实践
EN