部署git分支
在努力解决并整理出使用 git 进行 Web 开发的工作流程后，我的任务是在最后一秒添加临时服务器。我们在本地开发/测试并推送到存储库，现在需要在两者之间有一个沙箱，以便其他部门的人员可以在不破坏内容的情况下尝试新事物。
远程仓库需要两个长期运行的分支（本着 nvie 分支模型的精神）、master 和development。
我们需要能够推送到一个存储库，并将开发分支签出到 test.site.com docroot，准备好后，将开发合并到 master 并将 master 签出到 site.com docroot
所以在服务器上......
git init
git add .
git commit -m "Initial commit"
git checkout -b "develop"
以及在我们的本地机器...
git clone [email protected]:/repos/repo1.git
???
git push origin/develop (??? Updates test.site.com docroot)
并返回服务器以使代码生效
git checkout "master"
git merge develop (??? Updates site.com docroot)
git checkout -b "develop"
并在本地
git pull
帮助问号或替代建议表示赞赏。
编辑： 到目前为止，我正在尝试一些答案。在此期间我想出了一个完全hacky的想法，并认为我应该分享：
一个接收后挂钩来统治它们。
我们克隆一个裸存储库并跟踪开发。将开发推至起源/开发。
接收后 - 将 GIT_WORK_TREE 设置为 test.site.com，签出 -fdevelopment
如果提交消息包含“merge_master”，则将 GIT_WORK_TREE 设置为 site.com docroot，
git checkout master
git merge develop
git checkout -f master (this would be for hotfixes)
将 master 合并回开发并本地拉取
尘埃落定后，发送电子邮件difflog，拧紧双手，喝一口烈性的东西。
有多少种不同的方式可以打破这个？
After struggling with and sorting out a workflow for web development with git, I've been tasked with adding in a staging server at the last second. We develop/test locally and push out to a repo, and now there needs to be a sandbox in between so people in other departments can play around and try out new things without breaking stuff.
Remote repo needs two long-running branches (in the spirit of nvie's branching model), master and develop.
We need to be able to push to one repo, and checkout the develop branch to test.site.com docroot, and when ready, merge develop into master and checkout master into site.com docroot
So on the server...
git init
git add .
git commit -m "Initial commit"
git checkout -b "develop"
And on our local machines...
git clone [email protected]:/repos/repo1.git
???
git push origin/develop (??? Updates test.site.com docroot)
And back to the server to make code live
git checkout "master"
git merge develop (??? Updates site.com docroot)
git checkout -b "develop"
And locally
git pull
Help with the question marks or alternative suggestions appreciated.
Edit:
Am experimenting with some of the answers so far. Had come up with a completely hacky idea in the interim and thought I'd share:
One post-receive hook to rule them all.
We clone a bare repo and track develop. Push develop to origin/develop.
Post-receive - Set GIT_WORK_TREE to test.site.com, checkout -f develop
If the commit message contains "merge_master", sets GIT_WORK_TREE to site.com docroot,
git checkout master
git merge develop
git checkout -f master (this would be for hotfixes)
Merge master back into develop and pull locally
After the dust settles, send email with difflog, wring your hands and have a sip of something strong.
How many different ways could that break?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 git 中，您通常永远不会推送到已签出的存储库。完全没有。您可以推送到其中一个，除非您无法推送到已签出的分支，但通常不应该这样做。主要是为了让事物清晰分开，并避免在 Web 服务器损坏并需要修复时破坏中央存储库。
因此，您应该有一个裸（用于没有工作树的存储库的术语）中央存储库。每个人都会使用该存储库。它应该存在于您的内部网络上，并且不应位于公共或测试服务器的文档根目录中。事实上，我强烈建议不要将其放在任何一台服务器上，而是放在单独的（可能是虚拟的）机器上。
现在您有了网络服务器。它们可以是工作副本，也可以只是使用 git archive 创建的导出，并且可以通过 cron 或中央存储库中的更新后挂钩进行更新。
工作副本由
site.com服务器上的git fetchcentral-repo-url master和git pullcentral-repo-urldevelop更新test.site.com服务器（好吧，其他答案中建议的获取+重置可能更好，因为您确定那里没有任何更改）。导出通过使用
git archive获取 zip 或 tar 包并解压来更新。工作量有点大。Cron 只是定期运行命令。它更容易设置，但缺点是推送和内容出现在服务器上之间存在延迟。
post-update钩子设置起来比较复杂，但没有延迟（显然有一些延迟，因为下载数据也需要一些时间）。基本上，您创建一个脚本来运行更新，可以通过服务器上的 ssh 或 Web 请求触发。与在中央存储库中放置脚本hooks/post-update相比，这将触发服务器上的脚本。出于安全原因，不应向它们提供任何参数，并且该机制不应允许运行除这些脚本之外的任何其他代码。您可以通过查看推送了哪个分支（请参阅 git 文档以了解找到它的位置）并仅触发正确的服务器来使挂钩更高级。比
git push origindevelop将导致test.site.com被更新（但间接地，通过脚本）并使代码生效（在开发中）机器；从不在服务器上工作！）git checkout master
git 合并 开发
git push origin master
和最后一个命令将导致
site.com再次通过脚本间接更新。In git, you normally never push to repository that has checkout. At all. You can push to one except you can't push to the checked out branch, but you usually shouldn't. Mainly to keep things clearly separated and to avoid disrupting the central repository if the web server breaks and needs to be fixed up.
So you should have a bare (term used for repository without work tree) central repository. Everybody will be using that repository. It should live on your internal network and should not be in docroot of either public or test server. In fact I would strongly suggest not putting it on either server at all, but separate (possibly virtual) machine.
Now you have the web servers. They can be either working copies, or just exports created using
git archiveand can be updated either by cron, orpost-updatehook in the central repository.Working copy is updated by
git fetch central-repo-url masteronsite.comserver and bygit pull central-repo-url developontest.site.comserver (ok, the fetch + reset suggested in the other answer is probably better, because you are sure you don't have any changes there).Export is updated by getting a zip or tar pack with
git archiveand extracting it. It's a bit more work.Cron just runs the commands periodically. It's easier to set up, but the disadvantage is that there is a delay between push and the content appearing on the servers.
post-updatehook is a more complicated to set up, but does not have that delay (there is obviously some delay since downloading the data takes some time too). Basically you create a script to run the update, that can be triggered either by ssh or web request on the servers. Than in the central repository you put scripthooks/post-update, that will trigger the scripts on the servers. There should be no way to give them any parameters and the mechanism should not allow running any other code than those scripts for security reasons. You can make the hook more advanced by looking which branch was pushed (see git doc for where you find it) and triggering only the correct server.Than
git push origin developwill cause thetest.site.comto be updated (but indirectly, via the scripts) and to make code live you'll do (on development machine; never work on server!)git checkout master
git merge develop
git push origin master
and the last command will cause
site.comto be updated, again indirectly via the scripts.我的建议是让两个文档根都是 git 工作副本。
之后你有两个选择
post-update钩子，每次有人推送某些内容时都会执行上述操作。不幸的是，我手头没有这方面的有效示例。My suggestion is to have both docroots be git working copies.
After this you have two options
git fetch development-repo; git reset --hard development-repo/branchfor both. I've done stuff like this before, and the hard reset is a must: it'll nuke any random changes that have crept into your docroot somehow.post-updatehook in the development repo do the above every time somebody pushes something. Unfortunately I don't have a working example of this at hand.