有关 Git 的常见问题。
我们的工作以两周为一个周期，包含 4 个分支流程：
开发 > 发布-B-名称（测试） > 发布-A-名称（Beta） > 主控
每个冲刺，我们都会创建一个有名称（AZ）的新分支。
每个季度，我们都会将 RC 合并到主代码中，并将该代码标记为可用于生产。
然后，在生产环境中，我们获取并合并最新版本的 master（通过运行git pull origin master），因此每个季度，生产环境都会运行最新、最好的 master。这是历史方法。
问题：我应该在生产环境中运行/检查主分支还是主分支的标记版本？
我知道使用标记版本运行时会处于分离状态，但我真的没有看到这有什么问题，除了需要进行修补时？
答案1
免责声明：我个人对使用 Git 作为部署工具持怀疑态度。真正的构建/部署工具将提供许多 Git 无法实现的功能：版本控制规则、编译/预处理、管理文件权限等。如果您使用 Git 进行“部署”，这些步骤通常必须手动进行，这很糟糕。但是，您似乎原则上对您的部署过程感到满意，所以我不再争论了。
回答您的问题：
问题：我应该在生产环境中运行/检查主分支还是主分支的标记版本？
两者都可以，但我更喜欢使用标记版本。拉下来的文件完全相同，因此没有区别。但是，在某些情况下使用标记版本更安全：
- 如果有人在标记和部署之间的时间内推动掌握，您仍然可以获得正确的版本。
- 如果有人稍后
git pull在生产环境中运行，使用默认设置并master签出 Git 将获取最新状态master（无论它是什么）。如果签出标签，则不会发生任何变化。
我知道使用标记版本运行时会处于分离状态，但我真的没有看到任何问题，除了需要进行修补时？
我真的希望你没有暗示你打算在生产环境中提交（甚至可能开发）修补程序？如果是，那么请不要 :-)。
无论如何：是的，分离的 HEAD 状态不应该成为问题。我实际上认为这是一个好处，因为它明确表明你不应该在生产中提交东西。如果你真的觉得必须这样做，你总是可以在以后需要时创建并签出分支（但请不要这样做）。
最后，给大家一个建议：
然后，在生产环境中，我们获取并合并 master 的最新版本（通过运行 git pull origin master）
即使您坚持使用 Git 进行部署，使用 也不是一个好主意git pull，因为git pull如果之前签出了错误的分支（或者您甚至有本地提交，但希望您没有），它将自动执行合并。合并将导致您拥有来自不同分支的（未经测试的）数据混合。相反，我建议您使用：
git fetch
git checkout MY_VERSION_TAG
这样，您将获得来自的准确文件MY_VERSION_TAG。除此之外，我强烈建议您git status在部署之前使用检查本地修改。如果发现任何修改，请在部署之前对其进行调查。