Git Branch 分支综述
> 基于“开发/发布/缺陷分离”模型，结合开发阶段分配分支。主要包含master/develop/release/hotfix分支。
分支特性
Master Branch
1. 生产分支，又称Production Branch。
2. 该分支只接收最近发布到生产环境的分支。
3. 本分支**只能**从其他分支**合并**，**不能**直接**修改**提交代码。
4. 默认为保护分支，不可被删除。
5. 在该分支上打tag，一般Commit Message应为"merage From Release xxx"或"merage From Hotfix yyyy"这种自动生成的日志信息。
Develop Branch
1. 公共开发分支，又称主开发分支。
2. 该分支内包含即将发布的版本代码。
3. 代码来源主要为合并自master/feature分支的代码。
4. 该分支可以修改代码，作用是提供给所有feature分支合并使用，如Podfile。
5. 该分支跟踪于master分支，即主分支有代码变更（如hotfix代码），即主动合并至最新dev分支。
Feature Branch
1. 功能分支，又称任务分支。
2. 该分支主要用来开发独立的一个功能，比如禅道上某个需求，或者某个模块的调整。
3. 该分支的作用是撇清各个开发任务并行不交叉，不用反复合并代码解决冲突。
4. 本分支来源于develop分支，完成开发后合并于develop分支。
5. 此分支上的pod可指定本地目录；但合并至develop时应指定Branch或commit Id。
Release Branch
1. 版本分支，又称提测分支。
2. 本分支的作用为合并当期需要发布的代码，并提交测试。
3. 本分支来源于develo分支，即在开发完成后提测时各个feature合并至develop之后最新merge的代码。
4. 本分支终结于通过测试即发布时，自动合并至master分支，并删除。
5. 此分支上的pod不能依赖本地目录，通过版本Tag指定或远端分支代码commit指定。
Hotfix Branch
1. 紧急修复分支。
2. 该分支的作用为修复线上bug，即在正常的release迭代版本前插队发布的分支。
3. 该分支的来源为master分支，即线上最新代码。
4. 该版本的终点为master分支，在修复代码上线后合并主分支并删除此分支。
5. 如需要后续版本中保留此代码，则需要手动同步master代码到develop。
Git Flow 工作流
> 结合预设模版，组合指令，在不同开发阶段自动创建&合并分支。
正常软件开发周期为需求评审阶段/开发阶段/测试阶段/发布阶段。
对应的代码管理顺序为新建副本/开发代码/合并代码/修改代码/发布代码。
工作流
配置模版
初始化一组新的gitflow命令，主要是指派各个分支组名。
```
git flow init
```
```
同理sourceTree:
"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"初始化仓库"
```
开发新功能
需求评审阶段，当我们接到本阶段开发计划后会根据模块及需求拆分成任务。
```
git flow feature start [featureName]
```
```
同理SourceTree:
"选中当前feature分支"->"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"建立新的功能"
```
1. 首先我们会从先Checkout develop分支（实际只会操作一次）获取最新的团队代码。
2. 然后基于develop分支建立多个feature分支。
3. 分支命名为"需求编号_功能描述_作者"或"功能模块_描述_作者",如"**4396_blackFriday_wsc**"或"**feature/webview_deprecated_jgeng**" 。
4. 原则上只需要及时合并最新develop代码；如果需要依赖其他开发分支代码，手动操作即可。
完成新功能
需求开发阶段，当我们拿到项目排期后根据所属模块在各自feature分支开发即可；当功能开发完成后将合并至公共开发分支develop。
```
git flow feature finish [featureName]
```
```
同理SourceTree:
"选中当前feature分支"->"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"完成功能"
```
1. 首先在各自的任务分支上编写代码。
2. 然后拉取最新的develop分支代码并合并至自己的分支。
3. 解决冲突，保证++可以正常运行++，保证++podfile没有依赖本地代码++。
4. 点击完成功能，将自动合并当前feature代码至develop分支并删除此feature分支。
提交测试
> 到提测日的时候，各自任务分支代码应该已经开发完毕并完成自测。
此时代码仓库状态应该自动清理完所有当期提测的feature分支并自动合并至develop分支，负责本次版本发布的同学创建提测分支。
```
git flow release start [versionName]
```
```
同理SourceTree:
"选中当前feature分支"->"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"建立新的发布版本"
```
1. 首先我们要保证所有的提测分支应该已经合并至develop分支，ddl之后合并的即算延期。
2. 然后基于已经合并本期所有内容的develop新建release分支，此后develop分支得到解放，可以继续合并下个版本的feature分支。
3. 测试期间遇到bug将统一在release分支上修复；如担心存在经常性的合并冲突可自行新建bugfix分支并手动合并到此release分支。
4. 当开始测试后该release分支将与develop分支剥离主从关系，避免dev上有下期的代码也合并到本期release上。
5. 当本次版本通过测试后，即在最后一次commit上修改版本号并Archive&upload。
完成发布
需求评审阶段，当我们接到本阶段开发计划后会根据模块及需求拆分成任务。
```
git flow feature finish [versionName]
```
```
同理SourceTree:
"选中当前feature分支"->"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"完成版本发布"
```
1. 当本次版本通过审核后，点击完成。
2. gitflow会先将本次发布分支的代码合并到master分支，并标记tag。
3. gitflow将在合并完成后，自动同步最新的master代码到develop供下期开发的feature分支合并使用。
#### 紧急修复
需求评审阶段，当我们接到本阶段开发计划后会根据模块及需求拆分成任务。
```
git flow hotfix start [bugName]
git flow hotfix finish [bugName]
```
```
同理SourceTree:
"选中当前feature分支"->"顶部菜单"->"仓库/repository"->"gitflow或hg flow"->"建立新的修复补丁/完成修复补丁"
```
1. 当线上版本出现问题时，需要基于master分支新建hotfix分支。
2. 当完成修复后，gotflow将自动合并hotfix分支至master分支并标记tag。
3. 在合并完成后，gitflow将自动同步最新的master至develop分支。
Git Rule Remarks
目的
git branch
1. 方便代码管理，在合适的时机合并分支
2. 及时清理不必要的分支
git commit log提交信息应当简明扼要，主要用途在于
1. git repo中查看回顾此文件经历的需求
2. Jenkins中对比两次构建之间的提交
3. 关心其他成员修改模块是否对自己代码产生影响
实践要求
分支命名采取责任制的形式 "描述 - 所属人"。具体有两种命名规则：
- 根据需求来，采取"需求编号_需求描述_责任人","4396_blackFriday_wsc"
- 根据功能来, 采取"功能模块_操作描述_责任人","webview_deprecated_lbw"
提交信息命名采取关键词的形式 "xx - details"。具体有两种命名规则：
- 根据增删改查件来，采取操作+文件的方式，"Add/Del/Fix - xx类/yy文件；
- 根据所设计的模块，采取功能+描述的方式，"Detail - 新增折扣标签"
## 补充内容
//清理本地repo占用磁盘过大
```
git gc --prune=now
```
