我们正在将我们的源代码控制从 VSS 转移到 Git(对此非常高兴)。我正在尝试确定 Git 中的最佳策略，以跟踪我们的代码的哪些版本部署在我们环境中的哪些盒子上。到目前为止，我们只将我们的 GitHub master 分支专门用于专门代表生产中的内容。除非配置管理团队记录已成功应用于生产的内容，否则不会在此分支上进行任何提交。
人们是否也为他们的所有环境创建单独的分支或使用标签？我已经看到提出的分支模型，但它似乎需要大量不必要的、可能会带来痛苦的 merge 。
我认为标签是一个很好的解决方案，但人们如何实现呢？假设我有 3 个 QA 环境，分别命名为 QA1、QA2、QA3。如果我只是将代码从分支 origin/hotfix42 部署到 box QA2，我是否可以使用像“QA2-060911_511pm”这样的标记命名法来告诉我哪个版本的代码在什么时间部署到哪个 box？但如果我这样做了，随着时间的推移，我的标签数据库将增长到数百甚至数千个。所以如果我想找到部署到 QA2 的当前版本，如何查询所有标签以找到最新版本？或者....我会总是添加一个名为 QA2_Current 的额外标签吗？但是随着部署的发生，必须不断地删除该标签并添加到其他版本？
是否有任何其他机制可以将元数据添加到提交中？例如，我可以向我的提交添加一个 env 变量，然后搜索 env=QA2 的提交吗？
谢谢
最佳答案
经验法则是对永远不会改变的事物使用标签(例如版本 1.0.0 始终指向同一个提交)，对确实发生变化的事物使用分支(例如“最新”版本)。
所以我建议部署到 QA2 的当前版本由 git branch QA2 指定, 并通过添加 -f 进行适当移动到命令。如果您只是将其用作“可移动标签”，则无需进行复杂的 merge 。
如果您需要保留过去部署的历史序列，那么您可能想要进行 merge 而不只是移动分支。短时间内，您可以使用 QA2@{1} , QA2@{2}等，但这些最终会被 git gc 删除.
此外，请记住，在 git 中进行 merge 比您可能习惯的操作痛苦要少几个数量级。您可能想先尝试一下这些模型，然后再认为它们太难了。
关于Git 分支和环境部署跟踪，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6933722/