git 管理代码，如果有 100 个功能，开了 100 个分支，某个功能开发完毕，可预见的时间内不会修改，这个分支该删除吗

[qweweretrt515]

git 管理代码，如果有 100 个功能，开了 100 个分支， 那么 这么多的分支管理起来可能麻烦，可能有些乱

那么，为了保持不乱，

某个功能开发完毕，可预见的时间内不会修改，这个分支该删除吗

[wtser]

等到你需要开发某个功能的时候再开某分支，而不是一开始就开 100 个。
做完一个功能，就把分支合并到主干，然后删除这个分支。
若将来要修改，则到时候再另外开分支。

[andyhuzhill]

既然功能已经开发完毕了 不是就应该合并到主线分支去了么？ 合并之后就可以删除啦

[SpicyCat]

分支就不是这么用的。一般开发使用 git 的话，还要搭配使用个 issue tracking system. 如果使用的是 Gitlab 或者 Github, 那么自带了 issue tracking system. 一个 issue 对应一个 分支。
而有的 issue 可能比较复杂，还有进一步分解，那么分解后的子 issue 对应一个分支。
分支要保持尽量小，生命周期尽量短，尽快做完合并到主分支。

[qweweretrt515]

@wtser
@andyhuzhill
@SpicyCat
多谢三位

[shoaly]

我在幻想如果你们真开了 100 个分支 对应 100 个功能之后... 合并时候的酸爽

[keepfool]

分支要用的时候再开吧。按楼主的意思，我感觉是一次来了 100 个功能，需要开 100 个分支，我觉得这和 git 无关了，而是管理的问题。

[mahone3297]

lz 的问题，我觉得重点，不是 100 这个数量。
应该是想说，做新功能，开分支。完成后， merge ，那分支要删除码？
* 我之前是删除的
* 现在不删除了。可以看当时的分支上，做了哪些事。而且多一些，好像也没什么性能影响

[otakustay]

分支随用随开， merge 完就删，楼上这样要看做了哪些事的，用 no-ff merge 就能看了

[qiaobeier]

为了避免风险需要有层级，每一个层级的分支生命周期都不同。具体要看你们怎么管理的。
以下是我习惯的分类。
- Trunk
-- Produce/QA/DEV （这里有 3 个分支，每 2 周更新一次，每一个分支独立进行测试）
---- Sprint (每 2 周往 DEV 合并)
------- Tickets （任务分支，一旦完成往 Sprint 分支合并）

[loading]

谨慎做删除……无论是什么东西。

别问我为什么知道。

[340244120]

源文件一般都按功能或者模块划分， csv 不是用来做这种事的。
而且即使要修改代码，也是从最新提交的代码里修改，从以前的分支里改好再合并的话，也太不科学了，因为你不能保证每个功能分支的修改完全独立于其它功能 /分支。
最后，所谓功能的分支，留着几乎没用，当然如果硬盘大，为了某些情况下方便查看当时的代码，留着也可以。。

[mahone3297]

@otakustay >楼上这样要看做了哪些事的，用 no-ff merge 就能看了
请教，这个能否说详细点？没明白

[msg7086]

@mahone3297