我们正在将源代码管理从vss移到git(对此我们非常高兴)。我正试图确定git中跟踪我们的代码的哪个版本部署在我们的环境中的哪个框上的最佳策略。到目前为止,我们只将github主分支专门用于表示仅在生产中的内容。除非配置管理团队记录成功应用于生产的内容,否则此分支上不会发生提交。
人们是否也为他们的所有环境创建单独的分支或使用标记?我已经看到了提出的分支模型,但这似乎需要很多不必要的、潜在的痛苦的合并。
我认为标签是一个很好的解决方案,但是人们如何实现它呢?假设我有3个qa环境,分别命名为qa1、qa2和qa3。如果我刚刚将代码从分支源代码/hotfix42部署到框qa2,我是否可以使用诸如“qa2-060911 pm”之类的标记术语来告诉我在什么时候将哪个版本的代码部署到哪个框上?但如果我真的这么做了,我的标签数据库会随着时间的推移增长到成百上千。所以,如果我想找到部署到qa2的当前版本,如何查询所有标签以找到最新的?或者……我是否总是添加一个名为qa2_current的额外标记?但在部署过程中还要不断地删除标签并添加到其他版本中?
有没有其他机制可以向提交中添加元数据?例如,我可以在提交中添加一个env变量,然后在env=qa2的位置搜索提交吗?
谢谢
最佳答案
经验法则是,对永远不会更改的内容使用标记(如版本1.0.0总是指向同一提交),对确实更改的内容使用分支(如“最新”版本)。
因此,我建议部署到qa2的当前版本由git branch QA2
指定,并通过在命令中添加-f
来适当移动。如果只是将其用作“可移动标记”,则无需进行复杂的合并。
如果您需要保留过去部署的内容的历史序列,那么您可能希望进行合并而不是仅仅移动分支。在短时间内,您可以使用QA2@{1}
,QA2@{2}
等,但这些最终会被git gc
删除。
另外,请记住,在git中合并比您可能习惯的方式要少痛苦几个数量级。你可能想让这些模特试一试,然后再认为他们太难了。