团队开发

团队协作开发中，大部分都会用到版本控制软件，比如Git、Svn等。本文将通过一个实例，详细讲解在真实的工作环境中，一个团队应该如何利用Git+Github进行协作开发，即详解Git工作流程。并就其中比较棘手的问题作出解答，比如如何解决冲突比较合适，如何建立各种类型的分支等。
本文不会讲解Git简介、Git原理、Git基本用法等，有不了解的可以参考“ Git 参考手册 ”。我们举例演示的是GitFlow工作流的功能，这里先放一张经典的GitFlow工作流图示：

其中涉及到的主要分支类型有：
master分支，即主分支。任何项目都必须有个这个分支。对项目进行tag或发布版本等操作，都必须在该分支上进行。

develop分支，即开发分支，从master分支上检出。团队成员一般不会直接更改该分支，而是分别从该分支检出自己的feature分支，开发完成后将feature分支上的改动merge回develop分支。同时release分支由此分支检出。


release分支，即发布分支，从develop分支上检出。该分支用作发版前的测试，可进行简单的bug修复。如果bug修复比较复杂，可merge回develop分支后由其他分支进行bug修复。此分支测试完成后，需要同时merge到master和develop分支上。


feature分支，即功能分支，从develop分支上检出。团队成员中每个人都维护一个自己的feature分支，并进行开发工作，开发完成后将此分支merge回develop分支。此分支一般用来开发新功能或进行项目维护等。


fix分支，即补丁分支，由develop分支检出，用作bug修复，bug修复完成需merge回develop分支，并将其删除。所以该分支属于临时性分支。


hotfix分支，即热补丁分支。和fix分支的区别在于，该分支由master分支检出，进行线上版本的bug修复，修复完成后merge回master分支，并merge到develop分支上，merge完成后也可以将其删除，也属于临时性分支。

下边我们一步步拆分讲解各种类型分支的用法。
（1）假设团队就一个人“xianhu”，做一个叫TestGit的项目，并将其代码托管在Github上。首先需要在Github上新建一个项目TestGit：

按照Github上的提示，在本地新建一个项目，并关联到Github上的orgin/master。此时开发一个很小的demo功能，并提交到线上，并在master分支上进行打tag操作，并命名为v0.1。此时的GitFlow工作流为：

（2）如果此时master分支的代码正在线上运行，而且又需要开发新功能，则不能在master分支上直接修改。一个比较好的策略是在master分支上新建并检出develop分支，新功能的开发在develop分支上进行，此时记得将develop分支提交到远端：
git branch develop master # 从master分支上新建develop分支
git checkout develop # 检出develop分支
# 此处可进行功能开发，并add和commit到develop分支
git push origin develop # 推送develop分支到远端的origin/develop
即Github上保持两个分支：master和develop。目的是为以后团队协作更新develop分支做准备。此时Github上为：

此时会出现两种情况：
线上版本的代码（master分支）出现了紧急bug，需要修复。这里用到了hotfix分支。

git checkout master # 切换回master分支
git checkout -b hotfix master # 新建hotfix分支，并切换到该分支
# 做一些bug修复工作
git checkout master # 切换回master分支
git merge —no-ff hotfix # 合并hotfix分支，此时bug已被修复（无冲突）
git tag v0.2 # 新建tag v0.2
git push origin master # 推送master分支代码到远端
git push origin —tags # 推送tag到远端

develop分支上的功能开发完成了，需要进行测试和提交。这里用到了release分支。

git checkout develop # 切换回develop分支
git checkout -b release01 develop # 新建release分支，并切换到该分支

# 做一些测试、bug修复等工作

git checkout develop # 切换回develop分支
git merge —no-ff release01 # 合并release01分支到develop分支（无冲突）
git push origin develop # 推送develop分支到远端

git checkout master # 切换回master分支
git merge —no-ff release01 # 合并release01分支到master分支（无冲突）
git tag v0.3 # 新建tag v0.3
git push origin master # 推送master分支代码到远端
git push origin —tags # 推送tag到远端

此时GitFlow工作流为：

（3）这里可以继续develop分支，并不断push到远端。此时如果团队成员增加，多人需要开发不同的功能，这里就会用到feature分支。团队中的每个人都从Github克隆一个项目，然后新建自己的feature分支。
git clone xxxx.git
git checkout develop
git checkout -b feature-xx develop # 从develop分支新建并检出feature分支
此时“xianhu”做如下操作，并首先第一个提交到了Github远端：
git checkout -b feature-hu develop # 从develop分支新建并检出feature分支
# 这里可以进行一些功能开发，并不断的add和commit
git checkout develop # 切换回develop分支
git pull origin develop # 更新远端代码，看develop分支是否有更新（无更新）
git checkout feature-hu # 切换回feature分支
git rebase develop # 合并develop分支到feature分支，并解决冲突（无冲突）
git checkout develop # 切换回develop分支
git merge —no-ff feature-hu # 合并feature分支到develop分支
git push origin develop # 推送develop分支到远端
此时的GitFlow工作流为：

对于团队其他成员，比如zz，操作如下，并打算在“xianhu”提交后进行push操作：
git checkout -b feature-zz develop # 从develop分支新建并检出feature分支
# 这里可以进行一些功能开发，并不断的add和commit
git checkout develop # 切换回develop分支
git pull origin develop # 更新远端代码，看develop分支是否有更新（有更新）
git checkout feature-hu # 切换回feature分支
git rebase develop # 合并develop分支到feature分支，并解决冲突（有冲突）
# 这里需要进行冲突解决
git add . # 解决完冲突之后执行add操作
git rebase —continue # 继续刚才的rebase操作
git checkout develop # 切换回develop分支
git merge —no-ff feature-zz # 合并feature分支到develop分支（无冲突）
git push origin develop # 推送develop分支到远端
如果团队成员在合并feature分支到develop分支后还需要继续开发，则检出自己的feature分支继续操作，并重复上述过程即可。这里需要注意—no-ff参数，其目的是让commit的流程更加清晰，具体为什么可自行百度。
xianhu这边进行pull操作，即可看到zz进行的操作。此时的GitFlow工作流为：

（4）如果此时需要进行测试、发版操作，则需要再次新建并检出release分支，重复（2）的步骤。完成之后的GitFlow工作流为：

这里就完成了从版本v0.1到v1.0的迭代开发，并详细解释了如何利用Git+Github进行团队协作开发。文章中没有用到fix分支，这种分支的用法和feature分支类似，大家可以自己体会。
最后详细解释一下上张图：
xianhu在master分支上完成v0.1版本开发，“done demo in master”
发现master分支上有bug，需紧急修复。新建并检出hotfix分支进行bug修复，并merge回master分支，发布版本v0.2。
xianhu新建并检出develop分支进行迭代开发，然后在develop分支上检出release01分支，进行发版前测试和bug修复。“fix bugs in release01”，完成后将release01分支merge回develop和master分支，并在master分支上发布版本v0.3。
xianhu继续开发develop分支。此时团队成员增加，团队中的每个人都在develop的基础上新建并检出自己的feature分支，开发完成后merge回develop分支。这里利用到了rebase操作和冲突解决等，需要特别注意一点步骤。
xianhu在develop分支上检出release02分支，再次进行发版前测试和bug修复，“fix bugs in release02”，完成后将release02分支merge回develop和master分支，并在master分支上发布版本v1.0。
这里只用到和解释了GitFlow工作流，团队协作开发也可以用Pull Requests或者其他方式，找一个合适自己团队和具体业务的协作方式即可。另外，Git博大精深，想要完全精通也绝非易事，只能是一边学一边用。

精确查询

https://help.github.com/en/articles/keyboard-shortcuts

1、常用词含义
watch：会持续收到项目的动态
fork：复制某个项目到自己的仓库
star：可以理解为点赞
clone：将项目下载到本地
follow：关注你感兴趣的作者，会收到他们的动态
2、in关键词限制搜索范围
（1）公式
xxx in:name 项目名包含xxx的
xxx in:description 项目描述包含xxx的
xxx in:readme 项目
（2）e.g. 搜索项目名或者readme中包含秒杀的项目
seckill in:name,readme
3、stars或fork数量关键词去查找
（1）公式
:> 或者 :>= 数字1..数字2
（2）case 查找star数大于等于5000的springboot项目
springboot stars:>=5000 查找fork数大于500的springcloud项目
springcloud forks:>500 查找fork在100到200之间并且stars数在80到100之间的springboot项目
springboot forks:100..200 stars:80..100
4、awesome加强搜索
（1）公式
awesome 关键字
awesome 系列一般是用来收集学习、工具、书籍类相关的项目
（2）case 搜索优秀的redis相关的项目，包括框架、教程等
awesome redis
5、高亮显示某一行代码
地址后面紧跟#L数字
地址后面紧跟#L数字1-数字2
6、项目内搜索
键盘按t
7、搜索某个地区内的牛逼人物
（1）公式
location：地区
language：语言
（2）e.g.
location:guangzhou language:java

几乎 GitHub 上的每一页都有键盘快捷键，可以更快地执行操作。

部分拉取

GitHub上项目大了之后，某次只需要某个文件或文件夹，并不需要全部拉取。

• 前导知识
  查阅资料，有两个关键字:
  • git checkout [branch] – [file name]
  • svn

• git checkout
  ```bash

  1.初始化

  mkdir localdir # 创建用于作为本地仓库的文件夹 cd localdir # 进入文件夹 git init # 在本地指定文件夹内执行此命令设置为git仓库

  2. 拉取remote all objects信息

  git remote add -f origin http://github/projectName.git # 添加远程仓库地址，实现拉取remote的all objects信息

  3. 开启sparse clone

  git config core.sparsecheckout true # 用于控制是否允许设置pull指定文件/夹，适用于Git1.7.0以后版本，本质是开启sparse clone echo “fileName” >> .git/info/sparse-checkout # 本地目录的.git文件夹下，如果没有sparse-checkout文件则创建，在其中添加指定的文件/夹fileName，就是需要拉取的那个特定文件/夹。*表示所有，！表示匹配相反 cat .git/info/sparse-chechout # 查看

  4. 拉取指定目录

  git pull origin master # 拉取命令是一样的，只是已经通过配置文件sparse-chechout指定了目标文件/夹

-  svn<br />GitHub repositories can be accessed from both Git and Subversion(SVN) clients.  
```bash
svn co --depth empty https://github.com/user/repo # make an empty checkout fo the repository
svn up trunk # get the trunck branch,The Subversion bridge maps trunk to the Git HEAD branch(which is usually master)
svn co https://github.com/user/repo/trunk/fileName # 拉取指定目录

• git与svn不同
  git不能向svn那样针对子目录设置权限。
  svn是基于文件方式的几种存储，git是基于元数据方式分布式存储文件信息。
  Git会在每一次Clone的时候将所有信息都拉回本地，相当于在本地生成一个克隆版的版本库，因此就有了所有权限，也就没法针对子目录进行权限控制了。
  因此本质上来讲，Git是不支持只拉取一个仓库中的部分数据的，但是Git1.7.0之后可以通过sparse clone来变通。
• sparse clone
  sparse clone的逻辑是：
  1. 在本地先从remote拿到repository的all objects的元数据信息；
  2. 在本地仓库添加.git/info/sparse-chechout的文件（类似白名单）来配置需要pull的目录及文件；
  3. git pull master origin

常用功能

一、issue

• 在软件开发过程中，开发者们为了跟踪 BUG 及进行软件相关讨论， 进而方便管理，创建了 Issue。管理 Issue 的系统称为 BTS（Bug Tracking System，BUG 跟踪系统）。当今具有代表性的 BTS 有 RedmineA、TracB、 Bugzilla（http://www.bugzilla.org/）等
• GitHub 也为自身加入了 BTS 的功能。在 GitHub 上，可以将它作为软件开发者之间的交流工具，多多加以利用。遇到下面几种情况时，各 位就可以使用这个功能：
  • 发现软件的 BUG 并报告
  • 有事想向作者询问、探讨
  • 事先列出今后准备实施的任务
• Issue 除 BUG 管理之外还有许多其他用途。在软件开发者的圈子 中，将 Issue 用于多种用途的情况已经司空见惯。作为 GitHub 的功能之 一，想必今后会有更多人自然而然地用到它。所以借此机会，让我们来共同学习 Issue 的一些简单用法

新建 Issue

• 在仓库中点击 “Issue”，然后点击“New issue” 就可以新建一个话题

• 点击 “New issue” 之后如下所示

简洁且表现力丰富的描述方法

• GitHub 的 Issue 及评论可以使用 GFM(Github Flavored Markdown，简称GFM) 语法进行描述，从而获得丰富的表现力
• 比如像下面左图中那样描述，然后点击 Preview，就可以看到下面右图那种标记后的效果

• 点击文本框下面就可以找到 GFM 语法相关帮助的链接

• 语法高亮： 假设我们像下面左图所示，先指定语言再描述代码，这样一来，代码就会如下面右图所示被添加语法高亮，变得直观易读

• 添加图片： 添加图片也十分简单。只需将图片拖曳到文本框中便可以粘贴图片，或者选择下图中的链接会弹出对话框让你选择文件。GitHub 的网站上也有相关内容的详细讲解，各位不妨参考一下 (https://help.github.com/articles/issue-attachments)

添加标签以便整理

• Issue 可以通过添加标签（Label）来进行整理。在创建一个 Issue 话题时，可以为该话题设置一个标签，在下图左侧选择

• 例如在此处我们选择 Bug

• 然后点击 “Submit new issue” 提交之后，就会话题旁边就会显示这个标签

• 标签可以自由创建。既可以按语言和技术分类，也可以按照 BUG、任务、备忘等作业类型分类。各位可以按照需要选择便于整理的标签。
• 提个小建议：其实在 Issue 比较少的情况下不必每个都添加标签， 大可等 Issue 积攒到一定数量，只有进行筛选才能清晰把握时再添加标签

添加里程碑以便管理

• 除标签外，还可以通过添加里程碑来管理 Issue
• 点击下图中的 “Milestones” 按钮进入

• 然后点击 “Create a Milestone” 就可以创建一个里程碑

• 例如下面创建一个

• 然后会在仓库中显示

• 设置里程碑，就可以用 Issue 来管理任务

Tasklist 语法

• 我们可以使用 GFM 的一项独有功能，那就是 Tasklist 语法
• 首先试着按下面的格式进行描述

• 这样一来，这段文字就会被标记成复选列表的样式（下图所示）。这 个复选列表可以直接勾选或者取消，不必打开 Issue 的编辑页面重新编辑，十分方便，建议各位记住这个功能

通过提交信息操作 Issue

• 在 GitHub 上，只要按照特定的格式描述提交信息，就可以像一般 BTS 带有的功能那样对 Issue 进行操作
• ①在相关 Issue 中显示提交： 在 Issue 一览表中我们可以看到，每一个 Issue 标题的下面都分配了诸如 “#2、#3…#24…” 的编号。只要在提交信息的描述中加入“#24”，就可以如下下图所示，在 Issue 中显示该提交的相关信息，使关联的提交一目了然。这里只需轻轻点击一下便可以显示相应提交的具体内容，在代码审 查时省去了从大量提交日志中搜索相应提交的麻烦，非常方便

• ②Close Issue： 如果一个处于 Open 状态的 Issue 已经处理完毕，只要在该提交中以下列任意一种格式描述提交信息，对应的 Issue 就会被 Close：
  • fix #24
  • fixes #24
  • fixed #24
  • close #24
  • closes #24
  • closed #24
  • resolve #24
  • resolves #24
  • resolved #24
• 利用这个方法，每次提交并 push 之后，就不必再大费周章地到 GitHub 的 Issue 中寻找相应 Issue 再手动 Close，省去不少麻烦
• 像这样，只要按照特定的格式描述提交信息，GitHub 就会自动识别 并处理，让使用 GitHub 变得更加轻松。目前，很多 GitHub 之外的 BTS 也实现了这一功能，记住它绝对是有利无弊的。

将特定的 Issue 转换为 Pull Request

• 在 GitHub 上，如果给 Issue 添加源代码，它就会变成我们下面要讲到的 Pull Request。Issue 与 Pull Request 的编号相互通用，通过 GitHub 的 API 可以将特定的 Issue 转换为 Pull Request，能够完成这一操作的 hub 命令会在后面文章讲解。在这里，各位只要先记住 Issue 与 Pull Request 的编号通用即可

二、Pull Request

• Pull Request 是用户修改代码后向对方仓库发送采纳请求的功能，也是 GitHub 的核心功能（下图所示）。正因为有了这个功能，才会让众多开发者轻松地加入到开源开发的队伍中来

• Pull Request 页面能够列表查看当前处于 Open 状态的 Pull Request。通过点击页面左部和上部的选项可以进行筛选和重新排列
• 在列表中点击特定的 Pull Request 就会进入详细页面（下图所示）。页面上方显示着这次是从谁的哪个分支向谁的哪个分支发送了 Pull Request

• 下面，我们对各个标签（Tag）页进行讲解

Conversation

• 在 Conversation 标签页中，可以查看与当前 Pull Request 相关的所有评论以及提交的历史记录。人们在这里添加评论互相探讨，发送提交落实讨论内容的整个过程会按时间顺序列出，供用户查看。各位在查看过程中如果有自己的想法，不妨积极地添加评论参与探讨
• 提交日志的右侧有该提交的哈希值，点击链接即可确认相应提交的详细信息

Commits

• 在 Commits 标签页中，按时间顺序列表显示了与当前 Pull Request 相关的提交（下图）。标签上的数字为提交的次数。每个提交右侧的哈希值可以连接到该提交的代码

Files Changed

• Files Changed 标签页中可以查看当前 Pull Request 更改的文件内容以及前后差别。标签上的数字表示新建及被更改的文件数
• 默认情况下系统会将空格的不同也高亮显示，所以在空格有改动的情况下会难以阅读。这时只要在 URL 的末尾添加 “?w=1” 就可以不显示空格的差别
• 将鼠标指针放到被更改行行号的左侧，我们会看到一个加号。点击这个加号可以在代码中插入评论（下图）。这样，评论是针对哪行代码的就一目了然了

三、Wiki

• Wiki 是一个使用简单的语法就能编写文档的功能。所有有权限的人都可以对文章进行修改，所以比较适合多人共同编写文章的情况。创建、编辑文档时不必另外启动软件，用起来十分方便，非常适合用来针对更新频率较高的软件进行文档等信息方面的汇总

新建 Wiki

• 与 Issue 和 Pull Request 相同，Wiki 也支持 GFM 语法，所以可以轻松创建表现力丰富的文档
• 点击页面右上角的 New Page 按钮便可以创 建新的 Wiki 页

clone 编辑

• Wiki 功能本身的数据也在 Git 中进行管理
• 点击 Clone URL 按钮可以将当前 Wiki 的 Git 仓库 URL 复制到剪贴板中。用户能够通过 clone 操作获取 Wiki 仓库，然后在本地创建、编辑页面，进行提交再 push， 便可以完成对 Wiki 的创建及编辑工作
• 例如下面是一个 Wiki 的实例，链接如下：

https://github.com/dongyusheng/git-tutorial.wiki.git

```

Pages 标签

• 在 Pages 标签页中可以列表查看 Wiki 页面
• 例如本仓库只有一个 Wiki 文章，因此 Pages 标签中只有一个

侧边栏

• 所有 Wiki 页面都可以显示侧边栏。做法很简单，只要创建名为 “_sidebar” 的页面即可。_sidebar 页不会显示在 Pages 的页面一览中
• 点击右侧的 “Add a custom sidebar” 既可以创建

• 在编辑各页面时页面下部会附加 Sidebar 段（下图所示）， 用户可以在这里编辑侧边栏的内容

四、Pulse

• Pulse 是体现该仓库软件开发活跃度的功能。近期该仓库创建了多少 Pull Request 或 Issue，有多少人参与了这个仓库的开发等， 都可以在这里一目了然

• 根据这个页面，用户可以判断目前这个软件是否正在被积极开发， 或者持有仓库修改权限的人是否在认真地进行 BUG 修正等维护工作。 在挑选 GitHub 上开发的软件时，它可以作为一个重要的衡量标准

active pull requests

• 页面中 Overview 的左半部分显示了特定期间内活动过的 Pull Request 数
• 下图中：
  • 0 个 Pull Request
  • 其中有 0 个被采纳 (Active Pull Requests)，0 个保持 Open 状态 (Proposed Pull Requests)
  • Proposed Pull Requests 将来要么会被采 纳，要么会被 Close

• 如果想查看清单的详细内容，只要点击对应项即可（但是此处演示案例没有）。Pull Request 的概要及链接按照合并的先后顺序排列
• 点击 proposed-pull-request 则可以按创建的先后顺序查看 Pull Request 的概要及链接
• 通过这些信息，用户可以了解该软件最近正在开发哪些功能。如果 发现对方正在进行功能扩展或者修正，不妨积极试用一下这个功能。这 或许会成为您加入开源软件开发的契机

active issue

• 页面中 Overview 的右半部分显示了特定期间内活动过的 Issue 数
• 下图中：
  • 有 2 个 Issue，其中有 1 个被 Close，其余 1 个仍处于 Open 状态

• 如果想查看清单的详细内容，只要点击对应项即可。Issue 的概要及链接按照 Close 的先后顺序排列
• 点击 new issue 则可以按创建的先后顺序查看 Issue 的概要及链接
• 通过观察 Issue 的整体动向，用户能够知道这个软件是否有人在积 极地维护与支持。对方仓库越是活跃，用户发送的 BUG 报告和相关探 讨越可能收到回应

commits

• Overview 下方显示的是与提交相关的信息
• 左侧部分包含了如下几类信息：
  • 编写过代码的人数
  • 提交的次数
  • default branch 中修改过的文件数
  • default branch 中添加的行数
  • default branch 中删除的行数
• 通过这些信息，用户可以大致把握该仓库中活跃开发者的人数
• 另外，右侧图表显示了这些开发者具体发送的提交数。通过图表我 们可以了解到有哪些开发者在格外积极地向该仓库发送提交

五、Graphs

• Insights 页中，可以通过多种图表查看该仓库的相关统计信息。利用图表直观地汇总信息，可以让用户把握当前仓库的各种趋势

Contributors

• 在 Contributors 的图表中，我们可以看到每个用户在相应日期中发送提交、添加代码、删除代码的大致数量
• 从这里我们能够 了解到该仓库的代码主要由哪些人编写。而且，还可以通过图表分析出该软件大幅修改阶段和稳定维护阶段的相应时期

• 另外，这些图表的统计中还包括发送 Pull Request 被采纳后产生的 代码增减

Commit Activity

• Commit Activity 中显示了一年内（52 周）每周收到的提交的大致数量
• 第二张表中还可以查看相应周每天的提交数量。 判断某 个仓库是否有人在积极更新时，这部分是一个重要的指标

Code Frequency

• Code Frequency 中显示了该仓库中代码行数的增加量和删除量
• 一款优秀的软件并不会一味地增加代码，在经过重构之后，代码量往往会降低。通过这张图，我们可以直观地把握相应信息

Network

• 以图表形式显示包括克隆仓库在内的所有分支的提交。 从图上可以直观地看出每个人做了多少工作
• 将鼠标指针停留在表中提交或合并的点上，可以查看相应的参考 内容

六、Settings

• 在这里可以对仓库进行任何设置。用户必须拥有更改设置的权限，才能看到这个页面

Options

• ①Settings：
  • 在这里可以修改仓库名称
  • 上传社会预览：上传一张图片，定制你的存储库的社交媒体预览

• ②Features： 这里可以更改 Wiki 和 Issue 的相关设置。如果想关闭某些功能，只要取消已勾选的相应复选框，该功能就会从菜单中移除，无法使用

• ③GitHub Pages：
  • GitHub 有一个名为 GitHub Pages 的仓库，用户可以利用该仓库中的资料创建 Web 页，用来发布仓库中软件的相关信息。如果已经创建过 GitHub Pages，则会显示相应 URL
  • GitHub Pages 主要用于在 GitHub 上托管静态 HTML，以便发布项目的 Web 页 (https://pages.github.com/)
  • 由于可以绑定独立域名，人们也经常利用结合了这个功能的 OctopressB 框架来搭建博客。有兴趣的读者不妨试一试

• ④Danger Zone： 这里都是一些需要格外留意的设置。在这里，用户可以将仓库改为私有或是变更仓库所有者，甚至删除仓库本身。这些设置有可能影响到其他人，在变更时一定要谨慎

②Branches

• 功能分别为：
  • 设置显示仓库 URL 时默认显示的分支。这个默认分支同时也是创建 Pull Request 时的默认值，如果各位的主分支不是 master 分支，建议更改这一设置
  • 分支保护规则。 定义分支保护规则来禁用强制推送，防止分支被删除，并在合并之前有选择地要求检查状态

③Webhooks

• 在这个页面中，用户可以添加 Hook 让 GitHub 仓库与其他服务集成。通过 Add webhook 可以添加用户自己的 webhook

④Deploy Keys

• 在这个页面中，用户可以添加用于部署的公开密钥，允许以只读方式访问仓库。设置公开密钥后，用户可以使用私有密钥通过 ssh 协议 clone 仓库
• 要注意的是，这里添加的公开密钥 · 私有密钥对无法再添加到其他仓库。使用 Deploy Keys 功能时，需要给每个仓库赋予不同的密钥对

Notifications

• 第一次点进去时，会让你设置电子邮件地址，以便在触发推送事件时接收通知

• 每当创建 Issue、收到评论、创建 Pull Request 等情况发生时，我们就会在 Notifications 中收到通知
  https://blog.csdn.net/qq_41453285/article/details/110189036

键盘快捷键

在 GitHub 中输入 ? 可弹出一个对话框，列出可用于该页面的键盘快捷键。 您可以使用这些键盘快捷键对站点执行操作，而无需使用鼠标导航。

下面是一些可用键盘快捷键的列表。

站点快捷键

仓库

源代码编辑

源代码浏览

评论

议题和拉取请求列表

议题和拉取请求

拉取请求中的更改

项目板

移动列

移动卡片

预览卡片

GitHub Actions

通知

网络图