我们的网络应用包含我们的 bower套餐' A'。
' A'是一个包含master
和develop
分支的git仓库。例如,我们的webapp的bower.json
如下所示:
...
devDependencies: {
...
'A': 'http(s)://gitserver:port/A.git#R1.0'
...
}
目标:
我们的目标是允许webapp始终指向相同的标记/分支
的方法:
我们可以采用两种方法:
在bower包A
中,我们在develop
分支和master
上进行大部分合并工作。当我们准备发布时,我们在R1.0
分支上创建标记master
,指向master HEAD
的SHA-commit。
如果有任何"修补程序"我们推动提交掌握。从本地和远程删除标记R1.0
,并创建指向新版R1.0
主标记的标记HEAD
。
当网络执行bower update
时,我们希望它能够提取最新版本的凉亭套餐' A'
将master
HEAD
的版本分支剪切为R1.0
。在任何"修补程序"上,将它们提升为master
,然后使用R1.0
master
R1.0
分支始终保持"可释放"码。在这种方法中,master
分支几乎就像一个"虚拟"分支
问题:
我们观察了
bower cache clean && bower update
如果我们使用分支方法,只能工作(刷新)bower_components
目录。即当我们使用方法1中描述的标签(尝试轻量级和注释)时,bower_components
不会刷新。
很抱歉这么冗长。 有人可以对此有所了解吗?
谢谢!
答案 0 :(得分:0)
虽然您可以随意创建和删除标签,但我觉得它们并不是真的被设计为像那样移动。该设计的第一个提示是您不能直接移动标签,但必须删除并重新创建它。
当您移动已经推送的标记时,其他获取更改的人将无法获取更新的标记。出现这种情况时,您应该使用
git fetch origin --tags
它会更新强制推送的标签。当您在控制台中看到日志时,您将知道标记已被正确替换,如
- [tag update] v0.1 -> v0.1