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 flow 关于branch的管理

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 

```