在多阶段部署中使用git流

在这里完成我的部署方案时出现空白。在发布了这个问题之后，我已经了解了部署到本地回购的要点

我的本地开发服务器上有一个git流存储库，我可以推送到它，它将更新一个外部工作树

我已经用git flow设置了我的回购协议，下面是我的origin remote的外观：

$ 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流，跟踪开发分支，并将其推出给其他部门查看/QA。然后我们可以在内部进行发布，将更改推送到staging，然后简单地将主分支推送到生产

我想我的问题是——我这样做对吗？谈到git和git流，我是一个真正的新手。我仔细研究了所有可用的资源，这是迄今为止我能想到的最好的

---

非常感谢在多阶段部署中使用git流的人员提供的任何见解

这是我最后做的，这是我在上面提出的建议的一个微小变化，源于我在这里发布的另一个问题：

一根柱子被钩子钩住，统治着所有的柱子# Post接收钩子查看refname：

如果refname=“refs/heads/master”（推送到主分支）：

然后，我使用git附带的post receive电子邮件钩子发送一封关于提交的漂亮的小电子邮件。目前正在为我们的问题追踪器开发一个API，以便我们可以通过提交等方式解决问题

当refname=“ref/heads/develope”（推动开发）时也会发生同样的情况：

加分 3个分支-生产、开发（分期）和一个用于小型ish项目的问题跟踪分支。但有时，我们有更大的项目需要长期开发，而不能妨碍日常开发

您可以修改post-receive钩子以查找refs/heads/（.*），如果您执行类似于git-push-u的长期分支，将触发该钩子

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

进行日常开发，问题解决滚动并获得绿灯（每周计划合并到生产），准备就绪后可以合并长期分支

我确信我用这种部署策略冒犯了Git诸神的敏感度，但我们已经用这种方法成功地部署了一个大型应用程序大约5个月了，除了偶尔的合并冲突之外，没有任何问题

---

希望这有帮助。

如果您只想部署主机，可以使用以下代码段：

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."
fi

---

你的情况如何？这对我来说似乎是一个非常合理的安排，对我来说也很好。我们的做法与您描述的相同，但也将生产推送分支，这样，如果出现最新的产品，您只需回滚到该分支即可。

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."
fi