git-在生产中实现功能分支

生产部署

没有 正确的 回答这个问题,因为这取决于您对生产环境的偏好、约束和需求。根据此环境的敏感程度(听起来您所说的是一个拥有少量用户的不敏感系统),您需要确保部署的任何新功能都经过了良好测试,并且不会破坏预期的功能。您可以实现这一点,例如使用登台环境、设置持续集成、使用 Blue/Green deployments 或 Canary Releases 等。

也许下面的文章将是一个很好的起点: Deploy to Production -同样,您可以在堆栈溢出和InterWeb的其他部分找到许多关于CI/CD主题的提示。

GIT分支

一般来说,我建议使用Git工作流,例如 Vincent Driessen's branching model ,使用git标记并确保特性分支保持较小,即每个特性或错误修复都有一个分支。这将限制同时将许多更改合并到主分支的不确定性,并帮助您测试代码。

对于您的特定情况,为什么不在主分支上创建一个git标记,并在测试后合并到特性分支中呢?然后您可以创建一个新标签并将其发布到生产环境中。如果在部署后遇到任何错误,则可以始终回滚和部署上一个标记,或者创建bug修复分支来解决问题。

Create a tag in GitHub repository

这很好,对吧?

在生产中手动部署永远都不好。如果您的特性已经准备好上线,那么它应该合并到master并继续发布过程。如果在特性上线后出现意外错误,则恢复过程将开始工作。当我说“还原过程”时,我的意思不是“Git还原”,以前的工作版本被存档在某个地方,可以快速轻松地切换回生产环境。这是底线,也是最坏的情况。通常,您应该确保特性在生产之前工作(比如测试和登台环境)。

回到Git部分。如果您使用Git分支作为我上面提到的“备份存档”(虽然在生产环境中不建议使用),那么如果您的代码没有冲突结果(例如,DB记录/磁盘文件/etc),它就会工作。