【问题标题】:What is the process of deployment to the correct github branch?部署到正确的 github 分支的过程是什么?
【发布时间】:2020-05-18 19:44:37
【问题描述】:

我有3个分支,分别是master分支、branch staging和branch prod

另外我有两台服务器,即暂存服务器和生产服务器

当我在本地主机上完成开发过程后,我会将其推送到分支 master。之后,我将请求拉到暂存分支,然后合并到暂存分支。然后部署到登台服务器。测试人员将在登台服务器上进行测试。如果测试结果ok,我会把请求拉到prod分支,合并到prod分支。然后部署到生产服务器

我的方法对吗?

【问题讨论】:

标签: git github branch git-workflow


【解决方案1】:

这个过程是绝对正确的,这也是整个行业理想地遵循的方式。但是,它需要稍作修改。

为 master 分支中的每个新功能/错误创建一个功能分支,然后在完成后将其合并回 master。这样做是为了简化功能的并行开发。然后你可以按照你提到的工作流程。

要管理一些关键项目,您可能希望主存储库是干净的,因此您允许您的开发人员在他们自己的分支上工作(主存储库的个人副本)。完成任务后,您可以将 PR 提升到主 repo 的主分支,然后按照通常的工作流程。

还有一种情况,您可能需要另一种方法,即修补程序。什么是修补程序

任何一种微小的变化都是非常关键的。例如。您将代码推送到生产环境,其中一个 API 仍然指向“localhost”。此类问题需要立即关注,并且您不希望您的用户放弃。因此,您可以使用修补程序直接将代码推送到生产环境。

注意:Git 工作流程可能会因最适合不同个人或组织的需求而有所不同。因此,项目的重要性以及您可以承受的复杂工作流程完全取决于您。

【讨论】:

  • @happy forever 您对上述答案满意还是在寻找其他东西?
  • 我想确认一件事。正确的顺序是什么?从分支 master -> branch staging -> branch production 开始的顺序是否正确?还是分支暂存 -> 分支生产 -> 分支主控?
  • master -> staging -> 生产。原因是我们通常会在暂存和生产环境中实施 CI。因此,建议我们在合并后在本地测试代码,然后在 staging 和 production 上进行测试。
  • 我阅读了一些参考资料,顺序是开发 -> 登台 -> 生产/主控。所以生产和主人是一样的
  • 不同的组织可能采用不同的方法。我个人更喜欢我上面提到的方法,我确实有一个理由。因此,您必须了解遵循这些方法的原因并分析更适合您的方法。记住,这里没有对错。这只是个人选择。
猜你喜欢
  • 2019-06-13
  • 1970-01-01
  • 1970-01-01
  • 2013-03-23
  • 1970-01-01
  • 2017-02-15
  • 1970-01-01
  • 2019-10-16
  • 1970-01-01
相关资源
最近更新 更多