GitHub Flow：以部署为中心的开发模式

master <----+
  +         |
  |         +
  |     pull request
  |         ^
  v         |
branch +----+

此流程无需事先进行 Fork， 与之前的自己对自己发起 pull request 的 #1 一样；这样能够简化流程。

只不过这里是整个团队开发都使用这种流程，并且多了几条规则。

多出的几条规则：

• 令 master 分支时刻保持可部署的状态（以部署为中心）
• 需要帮助或反馈时创建 Pull Request, 以 Pull Request 进行交流 (与尽早发起 pull request差不多)
• 让其他开发者审查，与master分支合并，然后立即部署

流程比较简单，但是必须严格遵守其规则。(因为可能该规则是其他某规则或多条规则实施的前提)

GitHub Flow 剔除复杂规则，旨在使开发者快速开发高品质软件。（指相对于Git-Flow #4）
GitHub Flow – Scott Chacon 讲解了 Git-Flow 而使用 Github Flow的区别

实际使用 GitHub Flow 的前提

• 部署作业完全自动化。
• 自动测试

作为一名程序员，不应该每天为部署工作花费精力

官方帮助文档，而且有中文版：

• GitHub.com 帮助文档

Git Flow：以发布为中心的开发模式

便于理解的标准流程

1. 从开发版的分支(develop)创建工作分支(feature branches),进行功能的实现或修正
2. 工作分支(feature branches)的修改结束后,与开发版的分支(develop)进行合并
3. 重复上述❶和❷,不断实现功能直至可以发布
4. 创建用于发布的分支(release branches),处理发布前的的各项准备工作
5. 发布工作完成后与 master 分支合并,打上版本标签(Tag)进行正式发布；就会在github生成一个releases（这就是所谓的发布）
6. 如果发布的软件出现 BUG,以打了标签的版本为基础进行修正(hotfixes)

这里介绍的是分支策略 A successful Git branching model 的基础。

分支策略 A successful Git branching model 的整体流程图

• 特点：考虑了紧急的 BUG 应对措施。
• 难点：开发人员必须了解所做的修改与其它分支的关系以及如何与其它分支进行合并。
• 注意：修改前，必须先pull获取最新远程代码；修改后，尽快进行push操作。

正是由于其复杂性，所以常借助 git-flow 等工具来保证开发时不偏离流程。

仔细观察上图，从来没有在 master 和 develop 分支直接进行过修改和提交。

在 feature 中的工作流程

1. 使用pull获取远程仓库的最新代码
2. 从 develop 分支创建 feature 分支
3. 在 feature 分支中实现目标功能
   • 如果多人开发同一个 feature分支，记得开发时pull获得最新代码
4. 将feature分支push到远程仓库
   • 在push之前先获取远程仓库的最新develop分支
5. 通过 GitHub 向 develop 分支发送 Pull Request
   • 如果PR后得到的反馈是代码有问题
     • 本地修正代码
     • push 到远程仓库
     • 重复修正，直至PR没有问题
6. 其他开发者审查通过后,将 Pull Request 合并至 develop 分支
7. 删除feature分支

一个使用git flow的示例

这里假设是在单人开发一个 feature 分支，并且在开发过程中 develop 分支没有更新。

• 使用git flow init -d 对仓库进行初始设置；这里-d表示保留默认值。一般结果就是会创建并切换到 develop 分支。
• git push -u origin develop将develop推送到远程仓库
• git pull ，将 develop 分支更新至最新状态
• git flow feature start <featrureName>创建并切换到一个特性分支
• git commit 在特性分支中提交修改。 重复...
• 检查远程分支.... 略
• git push -u origin feature/<featureName> 推送到远程，并尽早发起PR
• 。。。
• PR合并成功。更新本地 develop分支： git checkout develop ，git pull
• 删除远程和本地 feature/<featureName> 分支。这里我们不使用 git flow feature finish feature/<featureName>因为它是在本地进行合并，而我们需要发起PR。

另一个分支策略 CakeDC Git Workflow 看起来也不错。

注意这里是 Git Flow 而另外还有一个 GitHub Flow #3

git-flow 备忘清单

步骤

1. 在code下打开该文件，
2. 点击该行的行号部分，或通过shift同时选择多行，
3. 然后会有一个显示为...的按钮出现，点击该按钮即可进行多种操作：
   • copy line：
   • copy permalink： （永久链接）在其他地方粘贴该链接，即可显示该段代码。很实用。
   • view git blame： Blame能够按行显示最新提交信息
   • open new issue：

具体的Pull Requst见：　 #1

这里保留此问题。

打开文件后，可以看到右上角会显示用于该文件的菜单：

• Raw：可以直接在浏览器中显示该文件的内容。使用该URL，就能通过HTTPS协议获取该文件。
• Blame：能够按行显示最新提交的信息。
• History：可以查看该文件的历史记录。
• Edit：可以对文件内容进行编辑并提交。
• Delete：可以删除这个文件。

同时查看文件时，点击文件内容左侧的行号，这里假设是第10行，该行会被高亮标记为黄色，同时URL末尾会自动添加#L10，如果将该为#L10-15就会标记第10～15行，当然你也可以使用shift键达到此目的。我们在其他地方可以好好利用这些URL。