我的“功能”分支有重大变化，这个“功能”分支是从主分支更新的：
git checkout feature
git pull origin master
虽然已经过全面测试，但我还是要稳妥行事。我还是不想合并到master分支。
所以在生产中，我想只在“功能”分支上结帐，所以如果出现阻止用户继续进行的错误，我可以立即结帐到主分支。
请注意，这个主要实现不会影响任何现有的数据库例程。
这很好，对吧？ 有什么想法吗？
【问题讨论】：
标签： git deployment
这样就好了吧？
在生产环境中手动部署永远不会很好。如果您的功能已准备好上线，则应将其合并到 master 并继续发布过程。如果该功能上线后出现意外问题，恢复过程将开始工作。当我说“revert process”时，我不是指“git revert”，以前的工作版本存档在某个地方，可以快速轻松地切换回生产环境。这是底线和最坏的情况。通常，您应该确保该功能在生产之前运行（例如测试和暂存环境）。
回到 GIT 部分。如果您使用 git branch 作为我上面提到的“备份存档”（尽管不建议在生产环境中使用），那么如果您的代码没有冲突结果（例如 db 记录/磁盘文件/等），它就可以工作。
【讨论】：
对此没有正确答案，因为它取决于您对生产环境的偏好、限制和要求。根据这个环境的敏感程度（听起来您在谈论一个用户数量很少的不敏感系统），您希望确保您部署的任何新功能都经过良好测试并且不会破坏预期的功能。例如，您可以使用暂存环境、设置持续集成、使用 Blue/Green deployments 或 Canary Releases 等来实现这一点。
也许以下文章将是一个很好的起点：Deploy to Production - 同样，您会在 Stack Overflow 和互联网的其他部分找到许多关于 CI/CD 主题的提示。
一般来说，我建议使用 git 工作流程，例如 Vincent Driessen's branching model，使用 git 标签并确保您的功能分支保持较小，即每个功能或错误修复都有一个分支。这将限制一次将许多更改合并到主分支的不确定性，并帮助您测试代码。
针对你的特殊情况，为什么不在master分支上创建一个git标签，测试后合并到feature分支中呢？然后，您可以创建一个新标签并将其发布到生产环境中。如果部署后遇到任何错误，可以随时回滚部署之前的标签或创建一个bug fix分支来解决问题。
【讨论】：