在这里最终确定我的部署方案是一片空白。在发布了这个问题:Migrating a production site with no VCS at all to Git之后,我得到了部署到本地存储库的要点。
我的本地开发服务器上有一个git-flow存储库,我可以推送到该存储库,它将更新外部工作树。
我用git-flow设置了我的repo,下面是我的原始遥控器的样子:
$ git remote show origin
* remote origin
Fetch URL: ssh://user@host/var/git/dev/repo.git
Push URL: ssh://user@host/var/git/dev/repo.git
HEAD branch (remote HEAD is ambiguous, may be one of the following):
develop
master
Remote branches:
develop tracked
master tracked
Local branch configured for 'git pull':
master merges with remote master
Local refs configured for 'git push':
develop pushes to develop (up to date)
master pushes to master (up to date)我尝试做的是设置两个伪环境。一个用于试运行,另一个用于生产。我希望它们的行为如下所示:
git push staging #pushes to remote staging repo with a post-receive hook "git checkout develop -f"
git push production #pushes to remote production repo with a post-receive hook "git checkout master -f"这样,我们可以在本地开发,并推送到我们的小内部开发服务器,并拥有所有的历史。然后,当我们可以进行试运行/生产时,我们只需推出适当的分支即可。
我尝试使用单独的工作树创建简单的repos,就像我在开发服务器上所做的那样(请参阅本文开头的链接),并简单地做到了:
git push staging develop
git push production master下面分别是遥控器:
$ git remote show staging
* remote staging
Fetch URL: ssh://user@host/var/git/dev/staging.git
Push URL: ssh://user@host/var/git/dev/staging.git
HEAD branch: develop
Remote branch:
develop tracked
Local ref configured for 'git push':
develop pushes to develop (up to date)
$ git remote show production
* remote produdction
Fetch URL: ssh://user@host/var/git/dev/production.git
Push URL: ssh://user@host/var/git/dev/production.git
HEAD branch: master
Remote branch:
master tracked
Local ref configured for 'git push':
master pushes to master (up to date)因此,从理论上讲,我们可以在内部使用git-flow,跟踪开发分支,并将其推送给其他部门查看/QA。然后我们可以在内部发布,并将更改推送到登台,然后简单地将主分支推送到生产。
我想我的问题是--我这样做对吗?当涉及到git和git-flow时,我是一个真正的新手。我已经仔细研究了所有可用的资源,这是到目前为止我能想到的最好的资源。
在多阶段部署中使用git-flow的人的任何见解都将非常感谢。
发布于 2012-03-10 01:15:25
这是我最终要做的,这是我在上面提出的建议的一个细微的变化,源于我在这里发布的另一个问题:Deploy git branches
一个post-receive钩子来管理它们。
Post接收钩子查看refname:
如果refname =“refs/head/ master”(推送到master分支):
echo "Updating production document root..."
GIT_WORK_TREE=/data/hosts/production/web/ git checkout -f master
echo "Production document root updated"然后,我使用git附带的post-receive-email钩子发送一封很好的关于提交的电子邮件。目前正在为我们的问题跟踪器开发一个API,这样我们就可以关闭提交等问题。
当refname =“ref/head/develop”(推动开发)时,也会发生同样的情况:
加分
3个分支-生产、开发(阶段)和小型项目的问题跟踪器分支。但有时,我们有更大的项目,需要长期的开发,不能阻碍日常的开发。
您可以修改post-receive钩子以查找refs/head/(.*?),如果您执行类似于git push -u疯狂实验长期分支之类的操作,则会触发该钩子
这让我们可以创建一个长期项目分支,使用-u将其向上推送,并通过一些简单的脚本在疯狂实验长期分支网站上自动设置一个子域。
日复一日的开发,问题解决滚动并开绿灯(每周计划合并到生产),疯狂的实验性长期分支可以在准备好时合并。
我确信我的这种部署策略冒犯了Git Gods的敏感性,但我们已经用这种方法成功地部署了一个大规模的应用程序,大约5个月了,除了偶尔的合并冲突之外,没有任何问题。
希望这能对你有所帮助。
发布于 2014-05-06 21:19:04
如果您只想部署master,您可以使用以下代码片段:
read oldrev newrev refname
branch=$(git rev-parse --symbolic --abbrev-ref $refname)
if [ "$branch" = "master" ]; then
echo "Deploying new master"
GIT_WORK_TREE="$DEPLOYDIR" git checkout -f master
echo "Finished."
else
echo " No commit to master. Deploying nothing."
fihttps://stackoverflow.com/questions/7262148
复制相似问题