我试图确定在git中完成发布分支的最佳方法.我想接受它,以便我们可以在需要时轻松返回.所以当我合并到开发分支时,我创建了一个标签并将其推送到遥控器,如下所示:
Tag this release
$ git tag -a "v1.6" -m "Release v1.6"
Push to remote
$ git push origin develop --follow-tags
Run Code Online (Sandbox Code Playgroud)
这似乎很有效.但是,我还需要合并到主人,并希望以同样的理由把它带到那里.当我尝试在发布时创建标记时,我显然会遇到冲突.所以,到目前为止,我一直在创建一个这样的标签:
$ git tag -a "v1.6-master" -m "Release v1.6"
Run Code Online (Sandbox Code Playgroud)
这工作正常,但似乎应该有一种方法来创建一个标签,并能够检查你碰巧在哪个分支上的标签.我觉得我错过了一些必不可少的东西.
但似乎应该有一种方法来创建一个标签,并能够在你碰巧遇到的任何分支上检查该标签.我觉得我错过了一些必不可少的东西.
如果你的意思是你认为你错过了制作标签的方式,就像你描述的那样......你不是.没有一个.所以我想缺少的是完全理解git中标签,分支和提交的关系.
标记是ref - 指向特定提交的指针.分支也是一个引用,但它恰好是一个预期以特定方式移动的引用.
人们经常想谈论在特定分支"上"的提交或标签; 这在git中并不是真正的东西(与其他版本控制系统不同).一个分支指向一个提交,并且其他提交可以通过该提交到达(通过父指针),并且标记可能指向可以从分支引用到达的提交......但是就这一点而言.如果您的提交拓扑符合某些假设,那么您可以通过说标记指向可从分支到达但无法从父分支到达的提交来近似"分支上的标记"的概念- 但您将使用git不关心的一堆概念(包括"父分支"的概念).
事实上,当你签出一个标签时,你会把自己置于独立的头状态 - 这意味着你不再在任何分支上了.
我猜git 可以定义一个数据结构,指向每个分支一次提交,但事实并非如此.
因此,如果您希望在多次提交中使用"version x"标记,那么您正在做的事情(使用命名约定来保持多个标记笔直)是您可以做的最好的.但我也会回应那些暗示"发展中的发布标签"并不像你预期的那样有用的人的观点.
使用 Git,它是一个提交,而不是一个分支,被标记。根据您的工作流程,相同的提交可能存在于master和develop 中。但是,鉴于您有这两个分支,对master的(合并)提交很可能意味着发布。在这种情况下,正确的做法是将合并提交标记为master。
在开发和主分支上标记发布分支
不。master只发布标签。develop用于开发的分支,它是不稳定的。
1 个标签映射只有 1 个提交哈希字符串,如果一个、两个或多个分支具有提交哈希字符串,则标签将位于这些分支中。
| 归档时间: |
|
| 查看次数: |
5921 次 |
| 最近记录: |