我想知道我用于标记和修复标记（我用于部署rails应用程序）的策略是否合适。
对于标记，我只标记主干的提交。
如果它发生，我必须修补标签，我正在检查标签（例如1.0），修复问题，提交它并重新标记它（例如1.0.1）。 现在，如果我必须对标记执行另一个修复，我将重复该过程，首先使用第一个修补程序的标记（例如1.0.1）。
现在，我注意到两件事： 1.当我结账1.0.1时，我得到一个警告，说我不在分支机构 - 我认为这没关系，但它是否适合作为策略？ 2.当我尝试部署1.0.2时，我从远程存储库的代码更新中收到capistrano（用于部署rails应用程序的工具）的错误，说它无法找到对象[提交1.0.2 ]。我可以纠正这个问题，检查主人并合并1.0.2。
当然，我总是将标签推送到存储库。
是否有任何错误/效率低下/不适当，或者这是一个适当的策略？ 我对git完全不熟悉，而且我找不到关于通常使用的部署策略的大量信息。
答案 0 :(得分：3)
我建议这样做：
为您的1.0标记创建一个分支，例如version-1并在其中应用此修补程序。
将分支标记为1.0.1。
对于下一个修补程序，您可以使用相同的分支，或者如果您删除它，则创建一个新分支，但这次是从标记1.0.1。
答案 1 :(得分：3)
从标签1.0开始，您需要制作分支
$ git checkout -b hotfix1.0
，每次需要部署时都可以在其上创建标记（1.0.1,1.0.2，...）。
处理分离的HEAd并不是最佳选择，因为稍后可以修剪该提交。如果你是一个独立的HEAD并做了一些修改，你总是可以将它们与给定的分支合并：
$ git checkout -m hotfix1.0
我不建议为你的程序的1.0版本为每个修补程序创建一个分支：一个分支应该足够用于此目的，标记一路上标记值得发布的重要修改。