提问一个关于 git 很低级的问题

这种没见过。猜一下，可能没有明确的业务需求，不好拉业务分支，创建自己的分支，每天下班前 push 一下只是为了同步自己的 workspace 吧。

我们是每个 task 都新建一个分支

具体遵循的规范是 git flow. 使用了 git flow 的 cli. 配置的时候分支的前缀名都配置成各个开发的英文名.

@eGlhb2Jhb2Jhbw 应该是楼下说的那样，不过我离职了没办法问项目的人为什么这样，现在想起来是想了解下这块的姿势

@rioshikelong121 谢谢。git flow 这块的知识确实是我的知识盲区。之前接触到的是基于产品的一个需求版本来搞一条开发，做好一个 task 就可以合到测试分支给测试。

我们公司就是每人都拉 dev 分支到本地，然后本地再从 dev 上拉起一个新分支，在这条新分支上开发新功能或者修复 bug，任务完成再推到远程仓库发起 merge request，架构师 review 以后再合并到 dev 上，每周五再把 dev 代码回归到 master

还好吧，我们也是拉 feature 分支，然后分支名前加上个人昵称简写 xxx/feat/xxxx，主要位了知道功能是谁负责的

@W1angMh 谢谢，学到了，github 上有这个东西。就你的了解，这样做除了代码审查和工作量的查看以外，其它的优点是什么呢？

@eGlhb2Jhb2Jhbw 嗯嗯，谢谢纠正。5 楼应该说的没问题

正确的做法是一个任务一个 feature 分支，但如果管理水平不够，这会给开发人员带来不小的负担，所以每人一条个人分支，是一种折中做法

至于你们之前的全部人在一个分支上提交，是错误的

@zoffy 也不能说是错误的吧，就是没有把一个版本的功能拆分几个 feature，不过我们之前那群人确实没什么人懂这个东西，所以我也觉得是有问题的。你说的负担指的是什么呢？

我也会这么干（虽然多数是 feature 分支），原因很简单，怕硬盘给我炸了丢代码

@yeqizhang #11 不是错误的，这种管理模式偏向是 Trunk-based Development （ TBD ）。也是一个比较主流的代码管理方式，和 Git Flow 各有千秋。

相当于私人文件夹

@yeqizhang #11 管理水平不够，很可能开发人员需要同时进行数条分支，这是挺痛苦的。还有就是要命名很多分支，有些任务根本不知道该叫什么

@yeqizhang #11 建议你还是查一下常见的这几种代码管理方式的优缺点吧，有时候会根据项目和团队组成，混起来用。

Git 是一个很强大很灵活的工具，上下限跨度很大，可以做到干干净净管理，也可以坑到像 cvs 一样挤作一团，全看管理和技术能力。

反正 git 的分支是免费的，那就多用起来呗，一个 feature 一搞分支，一个人一个暂存盘分支，都可以。

可以了解下常见的 git flow. gitlab, bitbucket 都有推荐 git flow, 但核心无外乎 feature, master, release.分支.用 feature 分支来开发, 可以使得各块功能都能独立开发而不冲突, 对敏捷开发友好, 而且能相对快速追溯到某个功能点的改动.

当然每个团队有各自的历史包袱和开发习惯.

我们曾经的实践是 git 与 kanban 关联，看板上一个卡片对应一个分，而且都会 push 到远端做 code review 再直接合并到主干
与 kanban 关联的好处是，只要卡片划分合理，卡片指定为具体的人了，那么分支也就是对应的人
CI 过程也能根据 git 的分支名字找到卡片，然后实时（甚至自动）更新卡片的状态（进行中、review 中、完成）

@zoffy 了解了，同时进行多个分支确实痛苦，但也没法避免的。命名确实是个头疼的问题哈哈

@msg7086 嗯，之前都是胡乱的用，连 rebase 都没有，历史图都看不下的，所以才有怀疑分支多了的问题。现在通过大家的提点也了解了一些