我对“功能”分支进行了重大更改，此“功能”分支是从master分支更新的：
git checkout feature
git pull origin master
尽管已经过全面测试，但我仍然想保持安全。我仍然不想将其合并到master分支。
因此，在生产环境中，我正在考虑仅在“功能”分支上检出，因此，如果出现错误，禁止用户继续操作，则可以立即向master分支检出。
请注意，这一主要实现不会影响任何现有的数据库例程。
这很好吗？ 有什么想法吗？
答案 0 :(得分：1)
这很好吗？
在生产环境中手动部署永远不会好。如果您准备启用功能，则应将其合并到母版并继续发布过程。如果该功能上线后出现意外故障，还原过程将开始工作。当我说“还原过程”时，我并不是说“ git revert”，以前的工作版本存储在某个地方，可以快速，轻松地切换回生产环境。这是底线，也是最坏的情况。通常，您应该在生产前确保该功能正常工作（例如测试和登台环境）。
回到GIT部分。如果您使用git branch作为我上面提到的“备份存档”（尽管在生产环境中不建议使用），则如果您的代码没有冲突结果（例如db记录/磁盘文件/等），则可以正常工作。
答案 1 :(得分：1)
对此没有正确的答案，这取决于您对生产环境的偏好，约束和要求。根据此环境的敏感程度（听起来您正在谈论的是一个用户数量少的不敏感系统），您需要确保已部署的所有新功能都经过了良好的测试，并且不会破坏预期的功能。例如，您可以使用暂存环境，设置持续集成，使用Blue/Green deployments或Canary Releases等来实现此目的。
也许下面的文章将是一个很好的起点：Deploy to Production-同样，您可以在Stack Overflow和Interweb的其他部分找到许多关于CI / CD主题的技巧。
通常，我建议使用诸如Vincent Driessen's branching model之类的git工作流程，使用git标签并确保您的功能分支保持较小，即每个功能或错误修复都是一个分支。这将限制一次将许多更改合并到master分支中的不确定性，并帮助您测试代码。
对于您的特定情况，为什么不在master分支上创建git标签并在对其进行测试后合并到feature分支中？然后，您可以创建一个新标签并将其发布到生产环境。如果在部署后遇到任何错误，则始终可以回滚并部署上一个标记，或创建一个bug修复分支来解决该问题。