使用merge或rebase维护部署分支

Question

我主持AWS,这意味着我无法使用环境变量来控制我的生产和暂存部署.因此,我被迫使用单独的分支进行部署,并且想知道是否有最佳实践方法来维护它们？

如果我将更改合并到我的生产分支中,则包含我的生产设置的提交将在分支历史记录中丢失,从而使调整这些设置变得更加困难.

但是我已经读过在这种情况下你不应该使用rebase,因为它会使回滚更改变得更加困难.

Answer 1

我在最近的项目中实施git也面临很多挑战.经过太多的谷歌搜索我发现这个博客,这是一个很好的维护git分支模型的方式.

一个成功的Git分支模型 中央仓库拥有两个主要分支,具有无限的生命周期:

• 主
• 开发

每个Git用户都应熟悉源的主分支.与主分支并行,另一个分支称为develop.

我们认为origin/master是主要分支,其中HEAD的源代码总是反映生产就绪状态.

我们认为origin/develop是主要分支,其中HEAD的源代码始终反映了下一版本中最新交付的开发更改的状态.有些人称之为"整合分支".这是建立任何自动夜间构建的地方.

支持分支机构

我们可能使用的不同类型的分支是:

• 功能分支
• 发布分支机构
• 修补程序分支

功能分支:功能分支(或有时称为主题分支)用于为即将发布或未来发布的版本开发新功能.

5月分支:发展

必须合并回:开发

分支命名约定:除master,develop,release-或hotfix之外的任何内容

发布分支机构:发布分支机构支持准备新的生产版本.它们允许最后一刻点缀我和交叉t.

5月分支:发展

必须合并回:开发和掌握

分支命名约定:release-*

修补程序分支:修补程序分支非常类似于发布分支,因为它们也用于准备新的生产版本,尽管是计划外的.它们源于必须立即采取实际生产版本的不良状态.

可能会分手:主人

必须合并回:开发和掌握

分支命名约定:hotfix-*

您可以从博客中找到有关此Git分支模型的更多详细信息.用于分支模型的命令也列在博客中.查看博客了解更多详情.我在我的项目中成功实现了分支模型,并对博客中提到的模型进行了一些更改.Git是一个强大而灵活的工具,这只是使用Git的一种方式.

Answer 2

您可以对两个设置文件进行版本控制（一个用于开发，一个用于生产）

然后你可以在“”之后留下一个“ elasticbeanstalk/hook”脚本来为你编写实际的设置文件git aws.push。

您可以在“ How to get Elastic Beanstalk nginx-backed proxy server to auto-redirect from HTTP to HTTPS? ”中看到类似问题的示例，关于 Node 应用程序（这可能不是您的具体情况），其中 .ebextensions /config 文件将写入/opt/elasticbeanstalk/hooks/configdeploy/enact/myscript.sh.

最后一个脚本是一个可以在部署时运行的挂钩，并且可以更新环境的实际配置文件。