将代码更改从 DEV 到 STAGING 到 PROD 的最佳方式

Question

恐怕这个问题可能有点宽泛，但我对将我在开发分支中所做的更改带到暂存分支然后到生产分支的正确方法有点困惑。

为了给你更多的背景信息，我正在开发一个网络应用程序，假设我开发了一个新功能（大小无关紧要），现在我想将该代码应用到暂存分支，以便我可以在将其推送到 prod 之前在 staging 上对其进行测试。现在，我可以将 dev 分支合并到 staging 中，但这似乎不是一个好方法，因为我有大量仅用于开发的代码，例如 console.logs 或其他注释掉的实验性内容等。 ，并且我不想将它们推入暂存状态，也不想将它们删除并重做下一次。

那么，我怎样才能将 dev 代码保留在 dev 分支中，并且只将功能部分添加到 staging 中？

我不确定我是否在这里缺乏 git 知识，是否有更好的方法来操作分支，或者我目前正在做的架构设计可能是错误的？

Answer 1

我们必须保持简单的 git 分支策略，让团队成员能够轻松一致地遵循。

分支和命名约定

1. trunk 或 mainline ：它应该是存储库的默认分支，集成了未来版本的所有更改。 （例如：master、develop 或 main）

2. 发布分支：创建发布（例如：release/v1.0、release/v1.1等）

3. 功能分支：处理问题（例如：ticket-200、ticket-201 等）

默认分支最初应该在github中配置。默认分支不应该用于发布

A.如何着手解决问题？

1. 开发者必须创建主分支的问题分支（master or develop）

2. 开发人员将更改提交到问题分支（功能分支）。

3. 合并到主分支 针对默认分支创建拉取请求。进行代码审查等。此时您必须删除不必要的调试代码/日志记录等。让 CD 过程和代码审查过程完成。然后合并到默认分支中

B.如何发布？ 当主分支（默认分支）中的源代码达到稳定点时，会创建一个发布分支。并且发布版本部署在您的暂存环境中进行测试。