week1 gitflow wiki - XLab-Tongji/AIOpsConceptualModeling GitHub Wiki
Git Flow
git flow是 Vincent Driessen 2010 年发布出来的他自己的分支管理模型，作为三种常用的git工作流之一，使用度非常高。按功能来说，git flow由5种分支组成，从这5 种分支的生命时间上，又可以分别归类为主要分支和协助分支。
主要分支：
在采用 Git Flow 工作流的项目中，代码的中央仓库会一直存在以下两个长期分支：
- Master
- Develop
其中 origin/master 分支上的最新代码永远是版本发布状态。origin／develop 分支则是最新的开发进度。
当 develop 上的代码达到一个稳定的状态，可以发布版本的时候，develop上这些修改会以某种特别方式被合并到 master 分支上，然后标记上对应的版本标签。
协助分支：
除了主要分支，Git Flow 的开发模式还需要一系列的协助分支，来帮助更好的功能的并行开发，简化功能开发和问题修复。这类分支只为暂时出现的问题而存在，解决后合并回主要分支。 协助分支分为以下几类：
- Feature
- Release
- Hotfix
Feature 分支用来做分模块功能开发，命名看开发者喜好，但不要和其他类型的分支命名弄混淆。模块完成之后将其合并到 develop 分支并删除。
Release 分支用来做版本发布的预发布分支，建议命名为 release-xxx。例如在软件 1.0.0 版本的功能全部开发完成，提交测试之后，从 develop 检出release-1.0.0 ,测试中出现的小问题，在 release 分支进行修改提交，测试完毕准备发布的时候，代码会合并到 master 和 develop，master 分支合并后会打上对应版本标签 v1.0.0, 合并后删除，这样做的好处是，在测试的时候，不影响下一个版本功能并行开发。
Hotfix 分支是用来做线上的紧急 bug 修复的分支,建议命名为 hotfix-xxx。当线上某个版本出现了问题，将检出对应版本的代码，创建 Hotfix 分支，问题修复后，合并回 master 和 develop ，然后删除自己。这里注意，合并到 master 的时候，也要打上修复后的版本标签。
Merge 加上 no-ff 参数
需要说明的是，Git Flow 的作者 Vincent Driessen 非常建议，合并分支的时候，加上 no-ff 参数，这个参数的意思是不要选择 Fast-Forward 合并方式，而是策略合并，策略合并会让我们多一个合并提交。这样做的好处是保证一个非常清晰的提交历史，可以看到被合并分支的存在。
wiki
通常使用markdown来编写wiki，本地编辑md时推荐使用typora。目前的wiki暂时采用以每周进度进行整合的方式，详见wiki界面侧边栏。
参考资料