git 有没有必要专门拉一个分支来放标签？

[James369]

我看有的地方除了有一个 release 分支之外，还专门开了一个 tag 或 master 分支来放 Tag 。

那么，为什么不直接在 release 分支上打 tag 就好了？少一个分支，这样还更省事？

[hronro]

分支还能放 tag ？？？我真不理解了。。。

「分支」可以简单理解为：指向最新 commit 的指针（即每次提交新的 commit ，分支的指针都会移动）
「 tag 」可以简单理解为：固定指向某一个 commit 的指针

由此可见，分支和 tag 都只和 commit 有关，分支和 tag 之间本身并没有任何的关系。专门开一个分支存 tag ，我是真不理解是怎么做到的？

[James369]

@hronro 看下这个： https://www.jianshu.com/p/c2aefcf6b2b7

[BugCry]

人多就拉，人少随意

[toast]

那个就是 master 吧 = =
M 和 P 节点上游包含哪些其他分支的节点，都是 master 的一部分的
他就是画图的时候这么画了而已，不是说 master 只有那俩 commit

[unt]

借楼问一下,多人协作中代码合并的规范.
我们现在远程分支是 4 个,master,dev,adev,bdev,
合并时 adev 和 bdev 互相合并,开发到一定阶段后一起由一个人合并到 dev 分支(个人本地会另见分支用于合并或者尝试性开发), 这种合并模式对不对

[fpure]

@unt 冗余了，保留 master 和 dev 就可以了

[hronro]

@James369 #2

你这说的是 gitflow 之类的 GIT 工作流程吧。这和我之前说的没有任何冲突：我们在开发过程中，除了开发用的主分支外，还需要一个东西来表明哪一个 commit 可以进入测试了，哪一个 commit 已经测试通过可以部署了。而这个东西，它并不是一成不变的，会随着我们开发的推进，而不断推进。结合我上面说的，branch 是不断变化的指向 commit 的指针（会逐渐推进），tag 是不会变化的固定指向某个 commit 的指针，这里当然是使用 branch 更为合适。

至于你说的「专门有一个分支放标签」，我估计是你对 GIT 的这些概念不熟悉导致的。实际上 Testing 、Release 这些分支，真正起作用的是分支本身，即这个指向当前分支 HEAD 的指针，用于表明这个 commit 将要被用于测试 /生产。只是这个 commit 上刚好可能有一个 tag 而已，但这个 tag 并不一定是必需的，我完全可以只从 master 分支 merge 指定的 commits 到 release 分支，一个 tag 也不打。

[zhzy0077]

单一主干的没有必要 但是我给你举个例子 Windows 可能会同时有五六个在维护的版本 21H1 21H2 22H1 22H2 每个版本就需要一个单独的分支了
虽然事实上 win 的分支管理比这个复杂很多

[securityCoding]

基于 commit 打 tag 就好

[pony279]

@James369
我猜，
这种工作流的目的是让 master 分支上面的任意一个提交都是可以发布使用的
当出问题且无法正向解决的时候，在 master 上面直接进行版本回溯，会比在一个混杂稳定和不稳定版本的分支上操作方便很多
直接基于 tag 进行版本回溯也是可以的，但相对没有那么直观

[yeqizhang]

tag 指向提交的全局唯一版本号，只是某些分支的时间轴上可能有别的分支没合过去的提交版本号。只能说拿稳定分支上的版本号来打 tag 比较常见，说放标签就很不专业了，还专门开一个 tag 来放 tag 让人无法理解

[xiubin]

@hronro #7

赞同 7 楼，release 分支会因为功能或者 bugfix 合入而不断迭代，在此期间每个合入该 release 分之的 commit 都可能被打成一个 tag 进行交付或者测试。

并不是有个 release 分支专门存 tag ，而是这个分支在迭代更新的时候出了几个版本（ tag ）

[chloerei]

你可能说的是版本分支，这样一般是为了后续维护打补丁。

[GeruzoniAnsasu]

@unt
杜绝相互合并，尤其是双向三路合并（ git merge ），即 a merge b, b merge a ，which is extremely evil ；
严格遵循单一公共线原则，即使是 feature 分支，也要有公共的 feature 分支+feature_a_dev+feature_b_dev ；
推送代码前必须先拉代码;
严禁任何分支 mege master ，只允许 master merge dev

推荐在 feature 和 dev 分支上禁用 merge ，只允许 rebase 。但 rebase 会导致目标分支历史重写，所以有第二条，尽量只重写自己的分支，避免公共分支被重写干扰其他人

[GeruzoniAnsasu]

@James369

你的理解有误，tag 就是指向具体 commit 的标签，跟在哪个分支无关

master 分支的目的是公共 checkpoint ，包含每一个完整的 feature ，与之对应的是 dev ，会包含尚未完善的 feature 。master 上每一个 checkpoint 或者 merge 点代表完成一个完整 feature 。

release 分支会有很多个（ release_v1, release_v2 ...），它们与 master 永久分岔，目的是存放所有已发布的历史线，如果不需要对外提供旧版本的 release ，那么旧的 release 分支其实可以删掉。之所以分岔的原因是，master 会有新 feature 和新 fix ，但 release 上只会有新 fix ，历史与主线是不同的。release 上的 fix 一般通过 cherry-pick 获得

如果完全不需要对已发布的版本做修复，而采用修复随版本滚动提供的方式，那么完全不需要 release 分支，只需要 tag/release 就好。 tag 的作用是给 commit 做特殊标记，由于有意义的 commit 一般在 master 上，所以 tag 「碰巧」打在了 master 上

[jim9606]

你看的那个是 svn 吧，通常会分 trunk 、branches 、tags 三个目录，trunk 相当于 master ，branches 放其他稳定分支，tags 通常只从 trunk 或者某个分支 cp 出来不修改。

[THESDZ]

有必要，增加一点的操作成本，避免了后续的其他使用成本；
比如热更新、回滚、版本比对等操作（各种需要一个稳定分支做动作的事情）；
以上用 tag 也行，但是不方便。

[THESDZ]

@THESDZ #17 其实是用分支来确定开发的不同环节，用 tag 来约束版本。

[unco020511]

很多人连 tag 是啥都没理解,tag 是一个标记,指向某一个 commit,git 里每个 commit 都是唯一且不可变的,既然如此又何来"用分支来放 tag"的说法呢?
我猜 op 的意思应该是说有了 dev,featureA,B,C dev 都往 dev 合,为啥还需要一个 master(或者 release)来与 dev 做同步,且在 master(或者 release)上打 tag?
其实和各个团队规定有关系,我们团队就只有一个 rc 分支来接受合并的代码,并且在 rc 上做发布.当然如果你认为需要,dev 往 master 同步,在 master 打 tag,然后 master 作为发布分支还不是可以,没有明确规定,选择适合自己的

[tags]

意思是想专门抽一些或者删除一些特性出来整成 release 版本打上 tag 吧？如果当前分支线上已经满足版本要求直接打 tag 就行了。不满足的话，比如 release 前要改一些编译配置，这些改动又不要合到主干，就会单独拉分支。