gpt4 book ai didi

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

转载 作者:IT王子 更新时间:2023-10-29 01:13:48 26 4
gpt4 key购买 nike

在此处完成我的部署方案后空白。发布此问题后:Migrating a production site with no VCS at all to Git ,我已经掌握了部署到本地存储库的 Gist 。

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

我用 git-flow 设置了我的 repo,这是我的 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

这里分别是 Remote :

$ 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,跟踪develop分支并推送出去,供其他部门查看/QA。然后我们可以在内部进行发布,将更改推送到暂存区,然后简单地将 master 分支推送到生产环境。

我想我的问题是 - 我的处理方式是否正确?说到 git 和 git-flow,我是一个真正的新手。我仔细研究了所有可用资源,这是迄今为止我能想到的最好的资源。

非常感谢在多阶段部署中使用 git-flow 的人们的任何见解。

最佳答案

这是我最后做的,这是我上面提出的一个细微变化,源于我在这里发布的另一个问题:Deploy git branches

一个 post-receive 钩子(Hook)来控制它们。#

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 钩子(Hook)发送一封关于提交的漂亮的小电子邮件。目前正在为我们的问题跟踪器开发一个 API,以便我们可以通过提交等方式关闭问题。

当 refname = "ref/heads/develop"( push 开发)时同样发生:

奖励积分

3 个分支 - 生产、开发(暂存)和一个用于小型项目的问题跟踪器分支。但有时,我们有更大的项目需要长期开发并且不能妨碍日常开发。

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

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

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

我敢肯定我用这种部署策略冒犯了 Git 大神,但我们已经用这种方法成功部署了大约 5 个月的大型应用程序,除了偶尔出现的 merge 冲突之外,还没有没有任何问题。

希望对您有所帮助。

关于git - 在多阶段部署中使用 git-flow,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7262148/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com