Git 使用规范

上午说了网盘可以用 SVN，那么代码其实也可以在 SVN 上管理，但为什么我们不用 SVN 呢，很大程度上是因为 svn 对分支的支持不如 git 好，比如方便性、灵活性等等。

这里做了一个 git 和 SVN 的对比，都很明显，不过有一点，git 代码保密性差的意思应该是，一旦 clone，就公开了所有代码、分支和版本信息，
SVN 不一样，svn 在分支管理时，多个分支是在不同的文件夹下；

然后我们介绍下 git 的分支管理模型，也是我们后面开发时候需要的一些流程和规范，主要介绍三种分支管理模型，最后还有我们目前使用的一种综合三类模型优点的模式；

• TrunkBased
• GitFlow
• AoneFlow

首先说一下 TrunkBased，这个就比较简单了，只有一个 master 分支，个人过程太简单，只适合项目刚开始的时候，赶紧开发出一个版本，以后再换其他的分支管理方式。
缺点很明显，没有测试分支，只能自己本地测试，有时候自己测试难免有忽略的点。
或者我有个功能 feature1 直接合并到 master 分支，让测试团队去测试，但是另一个 feature2 要上线，就把没有测试通过的 feature1 给发布出去了。

接下来是 gitflow，特点：引入 feature 分支，避免对 master 的污染，且多个新特性同时开发，不会互相影响；
但同时带来一个难题，就是 feature 的颗粒度设计，如果颗粒较大，比如模块级，会导致 feature 分支长期存在，等到 feature 完成，进行代码合并的时候，容易出现大量的代码冲突，
如果颗粒较小，又会存在大量的 feature 分支，维护成本高，开发来回切换分支，搞得晕头转向，把代码写到错误的分支也会发生；
主要分支可以看做为基准，就是代码的修改都在我的基础之上，最后所有的代码改动直接反馈到主要分支上。

然后是 AoneFlow，在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的多分支的麻烦。
三条基本规则：
-开始工作前，从主干创建特性分支

• 通过合并特性分支，形成发布分支。
• 发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。

最后介绍一下我们目前的 git 管理方式，比较简单；

首先说一下我们在开发时，一般会创建 3 个分支：开发、测试、master 分支。
一般我们在开发功能、修复线上 bug 都会创建一个新的分支，都算成是开发分支。

我们在 gitlab 上创建项目时，默认就是 master 分支，就是我们的线上发布分支。
项目初始化完成后，我们开始项目功能的开发，就需要在此基础上发起一个功能开发的分支，我们可以叫做开发分支，
命名可以以 jira 号命名，比如：jira-22;

当功能开发完成后，合并到测试分支 test；

测试通过，合并到 master 分支上，我们也可以在线提 PR，由 leader 进行代码 review，然后手动合并。

提交代码时，我们可以在 message 里指定 jira 号，比如：git commit -m “完善 xx 功能 #jira-22”；