Git-多分支管理-attempt

2017-12-3 11:31 tag: Git team manage

引用块内容Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

---

多分支

1.引言

==git的分支，作为git一个重大亮点。针对git分支管理，本文参考jobbole而写，大家有空可以看看原文。==

2.永久分支
Git中永久性分支一般有master、dev。
master分支是完全稳定的，可以直接供用户使用的产品，更新频率较低，一般更新：(1)修复bug，小版本更新 (2)发布大版本。dev为开发分支，全称develop。最开始从master中分离出来，用于存放基本稳定的开发版。每个开发者本机拥有和远程保持一致的master和dev，每次开发完成，开发者将本地的dev仓库push到远程的dev上，最终团队leader认定功能开发完成，可以正式发布新版本，由专人负责将dev合并至master，并打上新版本的标签V1.1。

(备注：传统模式，团队成员均可以将dev合并至master，为了避免操作失误带来风险，合并的权限授予团队中的1-2人。)

场景1

备注：master、dev所处直线为时间线，时间往下为依次递增的。

场景描述：版本开发任务分配完毕，小张、小王、小周开始并行开发，并不断向dev提交代码。小张一时疏忽下犯了低级错误，在没有察觉的情况下提交至dev。这时小王和小周从dev上pull下代码，开发->测试，发现代码运行异常，报错的代码段与自己无关。这时他可以选择：
(1)大神：直接修改小张的代码。流程：开发->测试->提交dev。不幸的是，大神动了小张的代码，产生冲突，所以需要解决冲突，再提交。同理，小张的代码提交也会显示冲突……
(2)呼叫小张，让其修复代码并提交；流程：等待->pull代码->开发->测试->提交，漫长的等待……
(3)呼叫小张，修复代码并提交；流程：开发->等待->测试->提交，代码早写好了，啥时候让我测啊。

总结：
两分支-优点：产品演进的版本路线十分清晰展示在master上，且master面向用户，极其稳定，管理十分方便。
两分支-缺点：一人bug，全队坐等修复。（快点修复，我们都在盯看着你）

3.总览分支

备注：此图阉割了版本发布的分支，如有兴趣，请参考jobbole。
master、dev所处直线为时间线，时间往下为依次递增的。

分支介绍：
master：主分支，面向用户，存储可用的完全稳定的产品，记录产品的演进。(放置在码。云)
dev：开发分支，面向开发者，存储经过测试的、稳定的版本。(放置在码云上)
feature：功能分支，面向单个开发者，每当接到新任务，流程 pull代码从dev -> 根据本地dev生成feature分支 -> feature-taskname开发->测试->commit(本地代码保存)->合并至本地dev->解决冲突(如果有的话)->push至码云的dev-> 删除功能分支feature-task01。(放置在本地git仓库)
hotfix：bug修复分支，当产品出现bug。流程 pull代码从master->根据master生成hotfix-bug01分支->开发->测试->合并至本地dev->解决冲突(如果有的话)->push至远程dev(码云)。(hotfix放置本地的分支)

备注：这个分支管理方案并没有授予每个成员直接push master的权限，普通成员仅仅能push/pull dev。针对master，普通成员只有pull的权力，没有push的权利，这会让master-产品版本管理更加严格和清晰，通常团队里面只有1-2人可以向master提交bug修复或者新版本。

总结

四分支-优点：团队不会出现因为小bug而停止开发，码云的dev管理更加便捷，稳定性更强。
五分支-缺点：暂时没有版本控制的分支，后期如觉得必要，再添加。