简介个人-Git-Work-Flow

重要性

咱们从重要性提及。

团队开发中要重视有洁癖的人，这种人每每对糟糕的工做流不断提出意见、对 Git 的使用方式提出要求。若是你的团队中这种人正在不断的被忽视，那么你的团队必定出现了管理混乱、代码质量不高等等等等问题。

统一的工做流程是相当重要的，无论对于哪个行业的做业来讲都同样。对于咱们开发人员，工做流包含了开发时 Git 的使用规范、Repo 管理的规范、测试过程的规范、设计交互的管理规范等等。因为测试、交互等设计到更多的人员，本篇文章暂且不表，重点说 Git 的使用规范和 repo 管理的规范。

本篇文章将讲述我在工做中一直使用的 Work Flow，但愿对你们有帮助。

常见 Git 使用规范

先举一个例子，放上几张 Network 的图形截图。为了你的工程不变成下面这个样子，请善待 Git 的使用：

这样一个乱糟糟的 Git，大家能忍我不能忍。

先来讲说几张图种的问题：

1. 反向拉取 develop 分支
2. 不通过 Pull Request 的合并
3. 重复使用已经合并的分支
4. 没有意义的 Commit Message

对于问题 1，敢问这位同窗，能不能用 rebase？不少同窗在开发分支过程当中，发现 develop 有更新，就去拉取 develop 的内容 Merge 进本身当前分支。对于 rebase 和 merge，请参考 这篇文章 。引用里面的话：

每次合并上游更改时 feature 分支都会引入一个外来的合并提交。若是 develop 很是活跃的话，这或多或少会污染你的分支历史。虽然高级的 git log 选项能够减轻这个问题，但对于开发者来讲，仍是会增长理解项目历史的难度。

对于问题 2，彻底就是习惯问题，对于全部的合并，若是是你本身的两个分支之间，若是非要直接 Merge 也不是不可，可是若是是两我的分别开发的分支，直接的 Merge 是不负责任的。Pull Request 或者 Merge Request 能够更早的帮你发现合并冲突，而且强制你 review 代码，这在保证代码质量方面起着相当重要的做用。

对于问题 3，已经合并入 develop 分支的分支，最好在 Pull Request 合并时直接勾选移除原分支，更容易保持和 develop 的同步。

对于问题 4，是最最最多见的问题，看看本身的项目，里面有多少个连续的 Commit Message 是『bug fix』、『update』、『pod add』、『修复』等等这样彻底看不出啥内容的描述。敢问这样写的同窗，大家的项目 Owner 看到 Network 时候是否是内心充满了 WTF？Commit Message 应当简短干练的描述这个 commit 作了什么。

下面再看一个正面的示例，无比清爽的 Network：

关于个人 Work Flow，咱们从基本的 Git 开发流接着介绍。

Git Flow

广为人知的 Git Flow 定义了一套标准的 Git 开发流。这里是经典文章。

大体的意思为：

1. master 是长期分支，通常用于管理对外发布版本，每一个 commit 对一个 tag，也就是一个发布版本
2. develop 是长期分支，通常用于做为平常开发汇总，即开发版的代码
3. feature 是短时间分支，通常用于一个新功能的开发
4. hotfix 是短时间分支 ，通常用于正式发布之后，出现 bug，须要建立一个分支，进行 bug 修补。
5. release 是短时间分支，通常用于发布正式版本以前（即合并到 master 分支以前），须要有的预发布的版本进行测试。release 分支在经历测试以后，测试确认验收，将会被合并的 develop 和 master

具体的也能够参考 Git 工做流程。

Github Flow

在开发中 Git 每每搭配持续交付平台，Github 也好，GitLab 也好，都提供了完备的持续交付管理功能。配合这些就有了 Github Flow

大体意思为：

1. master 开出新分支，不区分功能分支或补丁分支。
2. 新分支开发完成后，或者须要讨论的时候，就向 master 发起一个 Pull Request。
3. 项目内人一块儿评审和讨论你的代码。对话过程当中，你还能够不断提交代码。
4. Pull Request 经过，合并进 master，原分支就被删除。

能够看出 Github Flow 是 Git Flow 的简化版本，可是加上了一些合做关节的把控。

个人 Git Work Flow

我一般但愿团队中的开发流程相似 Git Flow，但更为详细，大体为：

1、Git 分支部分

master

长期分支，每一个 commit 对一个 tag（一个发布版本）

develop

长期分支，平常开发汇总（开发版的代码）。

开发一个新的 feature 直接新在 develop 新开一个临时的 feature 分支，开发完成向 develop 提 Pull Request``Pull Request。

release

短时间分支，feature 开发完成后从 develop 拉出的分支，用于测试阶段，期间添加的 commit 基本都是 bug fix，开发结束后同时和并进 develop 和 master，master 打上发布 tag。

hotfix

短时间分支，正式发布之后，进行 bug 修补

2、Git 操做部分

commit 规范

1. commit message 言简意赅，不要写无用信息。不要出现 『update』，『Bug Fix』，这样让别人不能领其意的描述
2. 添加一个新的 Pod 库或 pod update 后，单独提交一个 commit，统一 commit message 为『pod add xxx』或 『pod update』
3. commit 之间保持独立，不要有修改同一个文件的状况。好比一个 Pull Request 中 commit1 在 FileA 中改了一个变量名， commit2 改回了变量名。缘由是：审核代码时，审核人一般会逐个 commit查看，而不是直接看 Changes（能够直接忽略掉 pod update 这样的 commit 不看）

rebase

不要出现反向拉取代码的状况，即文章开头第一张、第二张图片中的状况——看到 develop 有更新，就将 develop 的代码拉取 merge 进本身的分支。

缘由是：

1. merge 会致使你的分支都会引入一个外来的合并提交。若是 develop 很是活跃的话，或多或少会污染你的分支。
2. 丑，Network 复杂，增长理解项目历史的难度。

如何解决当前 develop 有更新的状况？

请使用 rebase！

rebase 用中文直译就是 变基。上张图帮助你们理解：

rebase 在进行时，须要选择一个 commit 点，将当前分支从根基整个移到指定 commit 点，名副其实——变基。

这样你既能够获得一个好看的 Network，又能够及时控制冲突。不过在多人开发中你须要多多关注 develop 的状况，及时 rebase，避免长时间不更新代码忽然 rebase 到最新后发现了大量冲突。固然，控制和分配比较好的项目自己也不多产生冲突。

3、GitLab 管理规范

issue

平常 Github 玩的转的同窗都知道 issue 能够作不少事，好比：意见管理、Bug 管理、任务管理，能够只作一种功能，也能经过不一样的 Label 同时使用全部的功能。

个人 Work Flow 中，issue 用来作任务管理，由于 issue 能够方便的指派，及时收到邮件通知。

每次新版本迭代开始，PRD 审核经过时，组内协商好任务分配后将任务拆成最小单元，由 Owner 分别创建 issue，你们自行领取。

若是有开发过程当中发现的须要改进的地方，一样能够创建 issue。

关于 Label，我一般会分为：optimizing、bug fix、feature

一个任务完成时，一般会提 Pull Request，若是该 Pull Request 中完成了全部的任务，Pull Request 的 Title 应当相似如下格式：

『close #13 首页滚动栏切换效果完善』

GitLab 和 Github 都能识别 close #{issue id}，若是在 Title 中这样写，在 Pull Request 经过审核时，相应的 issue 会自动被关闭。

Milestones

Milestones 即里程碑，issue 在创建的时候能够选择 Milestones，若是合理的使用了 Milestones，在 Milestones 页面，就能够获得一个清晰的项目进度。

Pull Request

全部的合并都须要提 Pull Request，包括本身的分支合并到本身的分支，能够更好的帮助你们养成 Code Review 的好习惯。

Pull Request 的标题应该简介的介绍该次合并所作的事。更详细的内容应当在 Description 中逐条列出。若有相关文档连接也应列出。

注意选择合适的 Milestone 和 Labels。选择一位 Assignee 来审核，若是以为该 Pull Request 内容过多，或有须要你们共同讨论的地方，再 Pull Request 提交后，在 Discussion 区域 @ 其余人，全部人都会及时收到邮件。

Code Review

Code Review 是一个很值得说的点。不少时候你们会觉得 Code Review 是必定要读懂别人的代码，而后进行分析、审核。其实 Code Review 更多的是扮演了团队内经验传递的做用。

举个例子，代码规范这样的东西，就算是一个团队有了很详细的文档，但你们也不必定会去完整记下。对于新人，完成了 feature 后提 Pull Request，交由其余人 Code Review 时，由其余人审核代码规范，不合规要求继续修正，来回四五次，就再基本不会有问题了。

这也是个人亲身经历，我以前的一位 leader 对于 Work Flow 管理很是有经验，我在最初时提了几回 Pull Request，很快就熟悉了团队内的代码规范。

因此 Code Review 审核人应当检查的内容不是硬性的，但至少应当包括：

1. 代码规范
2. 基本语法和基本逻辑错误
3. 业务逻辑的一些经验
4. ...

在发现错误时，应当及时的添加 comment。

当审核人所有审核完毕，添加完全部的 comment 以后须要在 Discussion 区域 @提交人 review done，通知提交人。

一样，提交人在按照 comment 修改完后，也应当在 Discussion 区域 @相关审核人 修改完成，请从新审核。

须要着重说明的是：提交人的全部修改，不容许新提交 commit，应当在本地修改完成后，ammend 追加到最后 commit。

可是这一点，只是我一直使用的方式，缘由一样是遵循『commit 之间保持独立』，若是提交新的 commit 致使两个 commit 修改了同一个文件。

固然也有人认为新加 commit 能够更清晰的看到提交者的新变更，也更符合 Github Flow。关于这里，就没有什么强制了，更喜欢什么就什么。

总结

最后，但愿你们都收获一个清爽如风的 Network。

---

有什么问题均可以在博文后面留言，或者微博上私信我，或者邮件我 coderfish@163.com。

博主是 iOS 妹子一枚。

但愿你们一块儿进步。

个人微博：小鱼周凌宇