Github 的由来

尽管当时 Git 对于代码的管理以及团队协作方面已经非常出色，但是 Git 无法帮助开发人员寻找优秀的开源项目，同时很多程序员开发的优秀开源项目又变得不为人知，基于这样的历史背景下，一个既可以托管所有项目、提高协作又能充分利用 Git 特性的代码平台的诉求成为必然，基于 Git 的这个局限，Github 就这样诞生了。

如何在 Github 高效的搜索项目

如今 Github 已经非常火爆，也因此被戏称为 “世界最大的同性交友平台”，在 Github 上托管的仓库数量巨大，这对在 Github 上寻找需要的开源项目造成了困扰，其实在 Github 上搜索项目也有一定的技巧，下面我们就来说一下如何高效的找到自己需要的开源项目。

在登录 Github 后，让搜索项目的搜索框获取焦点并敲下回车键，会跳转到一个搜索页面，这个页面上点击 Advanced search（高级搜索）就会跳转到高级搜索页面。

  • From these owners：按照作者名搜索，格式 user:username；
  • In these repositories：按照仓库名称搜索，格式 repo:username/reponame；
  • Created on the dates：按照创建日期搜索，格式 created:<YYYY-MM-DD；
  • Written in this language：按照语言进行搜索，格式 language:JavaScript；
  • With this many stars：按照星星数查找，格式 stars:>1000；

上面列举只是常用的部分搜索方式和格式，具体可以查看 https://github.com/search/advanced，也可以不通过高级搜索的页面直接将规则写在 Github 主页的搜索框内，多个搜索规则可同时使用，格式之间用空格隔开，当然也可以按照内容是否在哪一个文件中来搜索，如 partcontent in readme。

Organizations（组织）

在 Github 中的仓库可以创建在个人仓库中，也可以创建在组织中，创建在个人仓库时项目的管理者只有项目的所有者，不方便团队层面的管理和协作，如果想要多人共同的管理项目可以通过组织的形式进行。

创建组织步骤（如 Github 功能更新请搜索最新教程或自行探索）如下：

  • 个人信息 setting；
  • 进入界面点击左侧 Organizations；
  • 点击右上角 new organization；
  • 填好组织信息后点击下方 Create organization。

添加后的组织会出现在用户 setting 页面的 Organizations 选项中，点击进入某个组织，可以添加 Github 中能搜索到的成员进行协同开发、在组织下新建仓库、创建团队对仓库做更精细化的管理，也可以对团队里的每个成员针对仓库设置读写权限。

怎样选择适合团队的工作流

一个团队在协作的时候一定会分工到所有人完成的工作变成一个产品的过程，“工作流” 对于研发团队来讲，可以理解成分支管理的流程。

主干开发

主干开发是围绕着一条主开发分支进行开发，团队所有成员的 commit 都及时的集成在这条主分支，让团队其他成员第一时间知道。


主分支开发工作流
主分支开发工作流


适用团队：

  • 适用于开发团队系统设计和开发能力强，有快速迭代场景，并且有一套有效的特性切换的实施机制（发布系统），保证上线后无序修改代码就能够修改系统行为；
  • 适用于组件开发的团队（一些基础服务的部门，专门造轮子），成员能力强，人员少，沟通顺畅，用户升级、切换组件成本低。

Git Flow

Git Flow 工作流定义了一个围绕项目发布的严格分支模型，工作流虽然复杂，但提供了一个健壮的用于管理大型项目的框架，具体的工作流程如下图：


Git Flow 工作流
Git Flow 工作流


  • master：专门用来存储正式发布的历史；
  • develop：作为功能的集成分支，可以多团队、跨迭代同时在 develop 分支集成；
  • feature：专门用来开发某一个新功能，仅仅只和 develop 交互；
  • release：发布（提测）分支，当快要到达发既定发布时间，从 develop 分支分出用来 bugfix、上线、与 master 进行合并，同时与 develop 进行合并；
  • hotfix：上线后从 master 分出用来修复线上 Bug。

适用团队：对项目质量要求较高，不具备主干开发能力，有预定发布周期且需要严格执行发布流程的团队。

Github Flow

Github Flow 工作流就是基于 master 的某一个 commit 拉一条特性分支进行开发，在开发完毕后再重新集成到 master 的工作流。


Github 工作流
Github 工作流


适用团队：不具备主干开发能力，随时集成随时发布，分支集成时经历代码评审和自动化测试，通过后就可立即发布的应用。

Gitlab Flow

Github Flow 是在 Github Flow 的基础上做了一些优化，新增了平行的 production 分支，用于随时准备发布上线，也可以多一些针对不同测试环境的待测试分支。


Gitlab 工作流
Gitlab 工作流


适用团队：

  • 适用于不具备主干开发能力，需要逐个通过测试环境的验证才能发布的应用；
  • 适用同一个时间节点项目发布出去会有多个版本同时存在的情况（公共库）。

Create pull request

在多人开发的项目或开源项目中，其他人拉出一条分支进行开发，在上线之前需要合并到 master 主分支，需要提交 pull request，在 Github 项目页面点击上面的 Pull requests 按钮，上面有两个选项：

  • base：目标分支；
  • compare：合并的特性分支。

在选好 base（目标分支） 和 compare（合并的特性分支） 后，点击下方 Create pull request，填写提交的描述信息后再次点击 Create pull request，此时会在下方显示与目标分支相比新增的提交信息并自动检查冲突。

pull request 有三种模式：

  • Create a merge commit：直接将某一个特性分支通过 merge 的方式合并到 master；
  • Squash and merge：会将特性分支的所有变更集组合成一个 commit 合并到 master 当前指向的节点之后，特性分支的树将独立；
  • Rebase and merge：会将特性分支变更集直接合并到 master 当前指向的节点之后，特性分支的树将独立。

选择 pull request 模式后，需要对这个 pull request 进行再次确认，填写确认信息并点击 Confirm merge 确认合并，在完成合并后 Github 会给我们提供删除特性分支的快捷按钮 Delete branch，一般会等到项目稳定后才会删除特性分支。

Issues

Issues 用于追踪需求和任务，在开源项目中使用者发现 Bug 或有新的需求都是通过 Issues 提出，在 Issues 的 Labels 中有开发者设置的代表当前处理状态的标签，通过 Issue 上的状态标签可以知道 Issue 的处理进度。

创建 Issue

创建 Issue 的步骤：

  • 点击项目的 Issues 进入 Issues 页面；
  • 点击 New Issue;
  • 填写 Issues 的标题及内容；
  • 点击 Submit new issue 创建 Issue。

创建 Issue 模版

Issues 的类型不是单一的，项目的所有者是可以给项目的 Issues 添加分类模版的，操作如下：

  • 进入项目的 Setting 页面；
  • 点击 Issues 选项的 Set up templates 按钮进入设置页面；
  • 通过下拉框选择 Issues 模版的类型，分类如下：
    • Bug report：用来提出项目中的 Bug；
    • Feature request：用来提出新的需求和功能；
    • Custom issue template：自定义的模版类型，由项目所有者创建时决定具体用途。
  • 点击 Preview and edit 对添加的 Issue 模版进行编辑，编辑后点击 Close preview 保存编辑的内容；
  • 添加 Issues 模版后点击 Propose changes；
  • 添加本次修改的记录，同时可以选择用 master 分支还是新创建分支来管理这些 Issues；
  • 点击 Commit changes 则会生成模版，再次执行创建 Issues 的步骤时可以看到设置的模版；
  • 点击模版对应的 Get started 快速生成对应的模版。

在编辑模版后，模版会生成对应 markdown 文件被保存在项目中的 .github/ISSUE_TEMPLATE 路径下。

Issues 更大的好处是，在追踪需求和任务的同时，任何人都可以在下面对这个 Issue 中的内容进行评论交流，甚至可以直接 @ 评论者、项目所有者、开发者、甚至是项目的整个团队，有助于快速解决 Issue 中提出的问题。

Projects

在开源项目开发时可以为当前项目的某个正在进行的迭代创建 Project，创建的 Project 类似于一个看板的形式，可以非常便捷的管理正在进行修复的 Issue 和 pull request（需要在创建 Issue 和 pull request 时选中关联这个 Project）。

创建 Project 步骤如下：

  • 进入项目的 Projects 页面；
  • 点击 Create a project；
  • 填写项目的名称和描述并点击下方 Create project。

在看板中分别对应四个区域如下：

  • To do：将要完成的任务；
  • In progress：正在进行中的任务；
  • Needs review：需要复盘的任务；
  • Reviewer approved：已经审核通过的任务。

任务可以通过拖动来改变当前的进度和状态，可以非常便捷的实现项目的任务进度监控和管理，有效的推进项目进程。

分支保护

在 Github 的项目中，可以对指定的分支定义规则来进行保护，防止强制推送、以及分支被删除等操作，目的是为了防止误操作对重要分支造成无法挽回的后果。

设置分支保护步骤：

  • 进入项目的 Setting 页面；
  • 选中左侧的 Branches 选项；
  • 点击 Add rule 来添加保护规则；
  • Branch name pattern 内制定要保护的分支名字；
  • Rule settings 中可以设置分支保护规则。

可选规则（可根据项目需求和要保护分支的安全级别多选）如下：

  • Require pull request reviews before merging：选中该项后所有的提交合并都必须通过 pull request 进行，下面有三个子选项如下：
    • Required approving reviews：同意 pull request 的人数，就是说设置后必须有对应设置的人数的相关人员批准，才可以合并；
    • Dismiss stale pull request approvals when new commits are pushed：勾选后在有新的 pull request 时会撤销旧的 pull request；
    • Require review from Code Owners：勾选该项后，pull request 必须通过项目所有者的通过才能进行合并。
  • Require status checks to pass before merging：在合并前必须通过状态检查才能合并，状态检查如下：
    • Require branches to be up to date before merging：要求分支在合并之前是最新的。
  • Require signed commits：勾选该项后要求在提交时验证签名；
  • Include administrators：加入管理员执行所有限制的配置。

Wiki

Wiki 是 Github 提供的说明文档功能，点击项目上的 Wiki 选项进入文档页面，在项目从来没有编辑过文档页面时，会默认出现 Create the first page 按钮，点击则会跳转编辑 Wiki 的页面，可以输入 Wiki 标题、内容和提交信息，内容支持 Markdown 语法编写。

当已经创建过一个 Wiki page 后再次进入项目的 Wiki 页面，会在右上角显示 Edit 和 New page 按钮，分别用于修改和新增 Wiki page，在左侧有所有 Wiki page 的列表，最下面是 Wiki 的仓库地址，也可以通过编辑器在本地创建 Wiki page，编写后通过 Git 推送到 Wiki 仓库。

在 Wiki 页面还有两个扩展功能，分别为 Add a custom footer 和 Add a custom sidebar，用于创建自定义底部和侧边栏（如编写目录等）。

总结

Github 管理项目实现协同开发是非常便捷的，在 Github 中每一个的操作的参与者和被参与者都会收到 Github 邮件进行通知，进入邮件链接也可以直接对项目变化进行 code review，在企业级项目中目前 Gitlab 的私有仓库更流行，基本功能与 Github 大同小异，在基本功能的基础上增加了更高级的功能和内置的持续集成插件。