在多阶段部署中使用git-flow

Question

在此处完成我的部署方案,绘制一个空白.在发布这个问题之后:将没有VCS的生产站点迁移到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)

我试图做的是设置2个伪环境.一个用于分期,一个用于生产.我希望他们的行为如下:

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"

通过这种方式,我们可以在本地开发并推送到我们的小型内部开发服务器并拥有所有历史记录.然后,当我们清楚地进行分段/生产时,我们就会推出适当的分支.

我尝试使用单独的工作树创建裸存储库,就像我使用开发服务器一样(参见帖子开头的链接),然后简单地做了:

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的人的见解都将受到高度赞赏.

Answer 1

这是我最终做的,这是我上面提出的一个细微的变化,源于我在这里发布的另一个问题:部署git分支

一个post-receive钩子来统治它们.#

post receive hook查看refname:

如果refname ="refs/heads/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/heads/develop"(推动开发)时也会发生同样的情况:

奖励积分

3个分支机构 - 生产,开发(分期)和小型项目的问题跟踪分支.有时候,我们有更大的项目,需要长期开发,不能妨碍日常开发.

您可以修改post-receive挂钩以查找refs/heads /(.*？),如果您执行类似git push -u crazy-experimental-long-term-branch的操作会触发

这使我们可以创建一个长期项目分支,用-u推送它,并通过一些简单的脚本在crazy-experimental-long-term-branch.site.com上自动设置子域.

发生日常开发,问题解决方案滚动并获得绿灯(每周计划合并到生产),疯狂的实验性长期分支可以在准备好时合并.

我确信我用这种部署策略冒犯了Git Gods的敏感性,但是我们已经用这种方法成功地部署了一个大规模的应用程序大约5个月,除了偶尔的合并冲突,还没有任何的问题.

希望这是有帮助的.