虽然我们现在只写了一个两行代码的小应用，它现在只能说 “hello ~”。不过可以想像的是，在未来我们的应用可能会包含很多行代码，放在许多文件里。所以我们需要一种管理这些源代码的工具还有方法，Git 是我们选择要用的源代码管理工具。
对于开发的项目，我们可以说要对这个项目做 “源代码管理”，或者也可以说要做 “版本控制”，它们指的是一个意思。做源代码管理或版本控制用的工具叫源代码管理工具（SCM），或者叫版本控制系统（VCS），它们指的是一种东西，Git 就是其中一种可以做源代码管理或版本控制用的工具。
我们对项目对了一些修改，比如添加了一个小功能，修复了某个 Bug 等等，你可能希望要保存一下项目当前的这个状态，这样以后遇到问题的时候，我们可以把项目恢复到保存的这个状态。如果不用源代理管理工具，要保存项目的当前状态，可以复制一份整个项目，然后重命名一下这个目录，以后出了问题，想要恢复项目的时候，可以用这个复制品替代正在开发的项目。
用源代码管理工具可以更好的管理项目的状态，每次我们对项目做了一些修改，就可以使用源代码管理工具来保存一下项目的这个状态。它会给我们提供一个历史记录，每一条历史记录都相当于是项目的一个状态，记录上都会有一行简短的描述，说明了一下当时为什么要做这次修改，修改的东西是什么。在项目的修改历史记录上还会显示这次修改是在什么时候做的，是谁做的，修改了项目里的哪几个文件里面的哪几行代码。我们可以把开发的项目恢复到任意一个时间点上，也就是恢复到保存的任意一个状态上。
既然选择走上开发这条路，Git 就是你的必备工具。它是一个非常强大的工具，提供了相当多的功能，我们不用一下子学完所有的东西，你也不需要单独去买一本 Git 手册去学习，因为你不可能记住所有的东西。一开始，你只需要完成这一章里的训练任务，掌握它的基本用法就足够了。在以后的实际开发工作中，可以再按需学习。
下面我们就通过一些训练任务，一步一步地学习这个工具的基本用法。
准备源代码管理工具<Git>
Git 本身是个命令行工具，所以要在命令行界面下使用它，不过现在也有一些带图形界面的 Git，比如 Source Tree，Github Desktop 等等。在我们的 VSCode 编辑器上也集成了 Git 功能。我推荐大家先熟悉一下在命令行界面下使用 Git 工具，先要理解它，然后可以再选择一款带图形界面的 Git。
下面我们要做的训练任务都是在命令行界面下使用 git 命令完成的。
#任务<macOS>：准备 Git
macOS 系统本身自带 Git 这个工具，打开终端，可以执行一下：
git --version
上面这行命令会得到当前在系统上安装的 Git 工具的版本号，如果提示没找到 git 命令，或者你想使用新版本的 Git，可以到 Git 的官方网站下载一个安装包，然后把它安装在系统上。
#任务<Windows>：准备 Git
我们之前在 Windows 系统上下载安装了 Cmder 这个命令行界面，它里面自带 Git 工具，所以就不需要额外再去安装了。打开 Cmder，执行一下 git 命令，确定可以使用它。
任务：配置 Git
用 Git 对项目做源代码管理的时候，经常要保存项目的状态，在保存的时候，Git 会记录这个保存的动作是谁干的。所以我们要提前配置一下 Git，告诉它我们是谁。
1：配置全局用户名与密码
打开终端，用 git config 命令配置一下，告诉 Git 我们的名字还有邮件地址是什么，执行：
git config --global user.name "wanghao"
上面执行的是 git config 命令，用了 --global 这个选项，表示要做的是一个全局的配置。这样在所有的项目里都会使用这个配置信息。wanghao 是我的名字，你要替换成自己的名字。
2：配置全局邮件地址
再执行：
git config --global user.email "wanghao@ninghao.net"
上面这行命令在全局范围，配置了一下用户的邮件地址，你要把这个邮件地址替换成自己的。
3：查看配置信息
git config 可以处理 Git 的配置信息，用 --global 选项设置了一个要做的配置影响的范围是全局范围， user.name 配置的是用户的名字，user.email 配置的是用户的邮件地址。这个命令实际上做的事情就是修改了一个配置文件里的内容，查看所有的配置，可以执行：
git config --list
Git 在工作的时候可能会用到这个配置文件里的配置信息，比如在保存应用状态的时候，它要知道这个动作是谁做的，Git 就会在这个配置文件里读取配置里的用户名还有用户的邮件地址。
创建一个仓库<Repository>
用 Git 这个工具对项目做源代码管理，先要在这个项目里创建一个仓库，英文是 Repository，可以简称为 Repo。Git 会把它需要的东西都存储在这个仓库里，这个仓库其实就是一个叫 .git 的目录，Git 帮我们管理这个目录里的东西。通常我们不需要关心这个仓库里到底都放了些什么，需要做什么都可以通过 git 命令完成。
Repository，这个词以后你可能还会在其它的地方看到它，比如后面我们在搭建应用生产环境的时候用的 Linux 操作系统里面，也会出现 Repository（Repo） 这个词，表示的是不一样的东西。在源代码管理这个语境的下面，它指的是一个代码仓库。不管它出现在哪里，我们可以先用它的字面意义理解它，也就是 仓库 的意思，就是一种存储东西的地方。
任务：初始化仓库
1：初始化仓库
在命令行界面，先进入到项目所在目录的下面，执行：
cd ~/desktop/xb2-node
初始化仓库就是创建一个空白的仓库，Git 提供了一个命令可以创建这个空白的仓库，执行：
git init
这行命令可以在当前目录的下面创建一个空白的仓库，也可以说初始化了一个仓库，这个动作只需要执行一次。命令会在项目的下面创建一个叫 .git 的目录，里面添加了一些必要的东西，有了这个仓库以后，Git 就可以发挥它的神奇作用了。
2：观察 .git 目录
如果好奇 .git 目录里面都有什么东西，可以执行一下：
ls -la .git;
我们不需要知道 .git 目录里的这些东西到底有什么用，因为这是 Git 要做的事情。我们只需要知道自己想要什么，然后告诉 Git，让它帮我们完成需要的任务。如果你不想对项目做源代码管理了，只需要直接删除掉 .git 这个目录。
保存项目的状态<Commit>
现在我们开发了一个会说 hello ~ 的应用，我想保存一下应用的这个状态。如果不用源代码管理工具，保存应用的状态，可能就是复制一份项目目录，然后改个名字，比如 xb2-node-hello，然后继续编写 xb2-node 这个目录里的文件。如果我想把应用恢复到能说 hello ~ 的这个状态，可以用 xb2-node-hello 目录里的东西，替换掉 xb2-node 目录里的东西。
如果用 Git 保存项目的状态就没这么麻烦了，只需要执行两行命令就可以存储一次应用的状态，保存的这个状态也可以看成是应用的一个版本。通过命令，我们可以列出保存的这些状态，可以任意查看这些状态，知道某个状态是什么时候保存的，是谁做的，相关的文件、代码是什么。我们可以把项目恢复到任意一个状态上。
在 Git 里面，这种保存项目状态的动作，有个专门的术语叫 提交，英文是 Commit。“保存一下项目的当前状态”，“保存一下当前对项目做的修改”，“做一次提交”，它们都是一个意思。Commit 当动词用的时候，指的就是要做一次提交，或者说保存一次应用的状态。它有时候也可以当名词用，比如我们可以说，“查看一下应用的提交历史记录”，“查看一下这次提交”，“这次提交是 wanghao 这个用户做的”。
任务：做一次提交
1：进入项目所在目录
在终端，确定当前是在项目所在目录的下面，如果不在，可以执行：
cd ~/desktop/xb2-node
下面就可以使用 git 命令对我们的项目做源代码管理了。
2：查看项目当前状态
查看项目当前的状态，执行：
git status
status 是 git 的一个子命令，它的功能就是查看项目当前的状态。在做提交（Commit）之前，先用 status 查看一下项目当前的状态，它会告诉我们项目当前发生的一些变动（Changes），比如哪些文件被修改了，都修改了哪几行代码，新添加了什么，删除了什么等等。项目里的这些变动都可以作为要提交的东西，也就是我们可以选择想要包含在要做的这次提交里的变动。
我们的项目之前还没有做过任何提交，所以查看项目状态的时候，会显示有一些 Untracked files，表示还没有被跟踪的文件，就是还没有做源代码管理或者版本控制的文件。
3：添加准备要提交的修改
添加要包含在提交里的修改，执行：
git add --all
用 add 这个子命令可以选择添加要提交的变动，这里我们用了一个 --all 选项，意思就是要把在项目里当前发生的所有的变动全部包含在这次提交里。
有时候我们并不希望把所有的修改都包含在要做的这次提交里，比如我们只希望在提交里包含发生在某些文件中的修改，这时同样可以使用 git add 命令，然后在命令的后面加上具体的文件名字就可以了。比如 git add package.json，意思就是在提交里包含发生在 package.json 这个文件中的修改。
4：再次查看项目当前的状态
添加了要提交的修改之后，再次查看项目的状态，执行：
git stauts
这次查看项目状态的时候，你会发现，在 Changes to be committed 下面列出了一些要提交的变动。这些要提交的变动会放在一个叫暂存区的地方，也就是在暂存区里的东西就是即将要包含在提交里的一些变动。你可以使用 git rm --cached <file> 这种形式的命令，把要提交的变动从暂存区里删除掉。
5：确定提交
现在我们已经把要提交的变动放在了暂存区里，确定这次提交，执行：
git commit -m 'init'
确定提交，要执行 git commit 命令， 提交的时候需要添加一条描述，说明一下这次提交主要都做了些什么。这个描述信息可以放在 -m 选项的后面。m 在这里表示 message ，也就是信息的意思。
6：查看状态
做完提交以后，再查看一下项目当前的状态，会显示 nothing to commit，目前还没有可以提交的东西。
7：查看历史
查看在项目里做的提交的历史记录，执行：
git log
上面这行命令会列出项目里的提交历史记录，如果记录比较多就会分页显示，按 f 键向后翻页，按 b 键可以向前翻页，按 q 键可以退出。在执行 git log 命令的时候可以加上 --oneline 这个选项，这样会用更简单的形式展示历史记录。
目前在我们的项目里只做过一次提交，提交的时候设置的描述信息是 init。每一次提交保存的就是应用的一个特定的状态。注意在每一条历史记录里面，除了提交时设置的描述，还会记录这次提交是谁做的，在什么时候做的。
commit 3b5e68c9a68985c561b871bf2ca2318eab61a4d4
Author: wanghao <wanghao@ninghao.net>;
Date: Sat Feb 8 18:19:46 2020 +0800
init
在提交记录里，commit 后面有一串很长的文字，是数字与字母的组合。这个东西是 Git 用一套方法根据这次提交计算出来的，我们可以把它想成是这次提交的唯一的标识，也就是这次提交的 ID，它在整个提交历史里面是唯一的，所以我们可以用它来表示这次提交。
很多事情都需要用到提交的 ID，比如你想看一下某一次提交都做了什么，可以复制一下这次提交的 ID，只需要复制其中的一小部分就行，假设 ID 号是：3b5e68c，然后执行 git show 3b5e68c，命令会显示这次提交都做了些什么。想要恢复在这次提交里对项目做的修改，可以执行 git revert 3b5e68c 。
在项目里创建了一个仓库，就可以对这个项目做源代码管理了，我们做了一次提交，保存了一下项目会说 hello ~ 的这个状态。你对项目做了一些修改，当你觉得合适的时候，就是如果你想保存一下项目的某个这个状态，就可以选择去做一次提交，提交的时候设置的那个描述信息，要尽量描述清楚这次提交都干了什么事儿。
Git 本身是个命令行界面，不过也有些软件会给 Git 套上一层 “壳”，提供了一个图形界面。也就是之前要在命令行界面下输入命令完成的事情，也可以在图形界面下点点鼠标来完成了。 虽然很多事情在图形界面下完成会比较方便，但是我们也必须要熟悉如何在命令行界面下使用 Git 。
任务：把文件恢复到上一次提交时的样子
1：修改项目
在编辑器，打开 src/main.js 文件，修改一下 greeting 的值，改成 你好。
2：查看状态
修改了 src/main.js 这个文件以后，在终端，执行 git status，查看一下项目当前状态，你会看到在 Changes not staged for commit 的下面，会出现 modified: src/main.js，意思就是现在项目里 src/main.js 这个文件被修改过，目前这处修改还没有放到暂存区里准备提交。
3：添加要提交的修改
执行一下：
git add src/main.js
上面这行命令的意思是，把 src/main.js 这个文件的变动添加到暂存区里，这样在提交的时候，就会在提交里包含在这个文件里发生的变动。
4：查看状态
再用 status 查看一下状态，这次你会发现在 Changes to be committed 的下面，会列出 modified: src/main.js，这就表示已经把 src/main.js 这个文件的变动添加到了暂存区里了。
5：移除要提交的修改
假设我突然改主意了，打算恢复一下对 src/main.js 文件的修改，把它恢复到之前的一个状态，也就是上一次提交的那个状态。如果不用 Git，你可能需要在编辑器里打开的这个文件的上面，不断地恢复之前对这个文件做的修改，但如果你保存了这个文件，又关掉了这个文件，重新再打开它，这就没那么容易使用编辑器的恢复功能了，只能凭记忆手工恢复文件的状态。
我们的项目用 Git 做了源代码管理，所以执行两行命令，就可以恢复当前对某个文件的修改。因为之前我们已经把这个文件的修改添加到了暂存区里准备提交，所以第一步要做的是把它从暂存区里再拿出来，执行：
git reset HEAD src/main.js;
执行了上面这行命令以后，再次查看项目当前的状态，你会发现 src/main.js 这个文件的变动又会出现在 Changes not staged for commit 的下面。
6：恢复文件的状态
恢复一下 src/main.js 文件的状态，执行：
git checkout -- src/main.js
现在 src/main.js 这个文件就会恢复到上一次提交时的状态了，也就是它会说 hello ~ 的那个状态。再查看一下项目当前的状态，会提示当前没什么可以提交的东西。然后在编辑器里再观察一下 src/main.js 这个文件，你会发现 greeting 的值，又会变成原来的 hello ~ 。
实验想法的好地方<Branch>
当你想在开发的项目里去实验一些新的想法，给应用添加一些新的功能，解决应用里出现的一个 Bug 的时候，如果你不太确定对项目做的修改是否可行，这些时候我们可以在项目里去创建一些新的分支，然后在这些新的分支上继续开发项目，做一些提交，怎么折腾都可以。如果可行，我们就可以把在这些分支上做的提交（保存的状态）合并到主分支上，如果不可行，我们可以扔掉这些分支，项目不会受到任何的影响。
在项目里初始化了一个仓库之后，默认会带着一个叫 master 的分支，可以称为主分支。这个分支跟其它的分支相比，没有什么特别的地方，只不过我们经常会把它作为应用的主分支，在其它分支上做的提交最终都可以合并到这个主分支上。
比如现在如果运行我们开发的应用，它会输出一个 hello ~，这是应用在 master 分支上的当前的状态。现在我想试验一个新的想法，我可以先基于当前的 master 分支创建一个新的分支，比如分支的名字叫 greeting，这样在 greeting 这个分支上就会包含在 master 分支上做的所有的提交，我在 greeting 分支上继续开发项目，做了提交，让应用会说 你好。
假设我对在 greeting 分支上开发的项目比较满意，我可以在应用的 master 分支上，合并一下我在 greeting 分支上对项目做的提交，这样在 master 分支上就会包含所有在 greeting 分支上做的提交。也就是，现在如果运行在 master 分支上的应用，它就会输出 你好。
任务：创建与切换分支<develop>
1：查看分支
在终端，先进入到项目所在的目录，然后执行：
git branch
这个命令会告诉我们项目里都有哪些分支，项目当前是在哪个分支上。初始化一个仓库以后，里面就带着一个默认的分支，名字是 master，这个 master 分支跟我们自己创建的分支没有任何区别，只不过我们自己可以赋予不同的分支不同的意义。比如这个 master 分支，一般可以作为应用的 “主分支”。
2：创建分支
创建一个叫 develop 的分支，执行：
git branch develop
执行 git branch ，后面加上一个分支的名字，就可以基于当前的分支创建一个新的分支，develop 就是我们基于 master 分支创建的一个新的分支。
3：切换分支
把项目切换到新创建的 develop 分支，执行：
git checkout develop
切换到指定的分支上，用的是* git checkout* 命令，后面加上要切换到的分支的名字。git checkout develop，意思就是把项目当前的分支切换到 develop 。这样对项目做的修改，提交，都只会影响到 develop 分支，因为它是项目当前的分支。checkout 这个子命令有不少功能，在这里我们用它切换项目当前的分支。
项目当前的分支是 develop，查看一下这个分支上的提交历史，你会发现在 master 分支上做的所有的提交。
4：查看分支
再看一下项目里的分支，执行：
git branch
再次执行 git branch 查看项目分支的时候，你会发现，现在项目里有两个分支，master 与 develop，在 develop 分支名字的前面会带着一个 * 号，表示这是项目当前的分支。
在 master 分支上的项目的状态是随时可以正式发布的，所有的开发工作都在 develop 分支上进行，如果需要给应用添加新的功能，修复项目里的 Bug，都可以基于 develop 分支再去创建新的功能分支或者修复 Bug 的分支，然后把在这些分支上做的提交合并到 develop 分支上，最终可以再把 develop 分支上的东西合并到 master 分支。这是一种基于 Git 做开发时用的一种工作流程，你也可以定制适合自己的开发流程。不过现在，先跟着我这样做。
任务：创建分支<greeting>
上面这个任务要做的就是基于 develop 分支，创建了一个新的分支叫 greeting，同时把项目当前分支切换到这个新创建的 greeting 分支上。这里用的命令是 git checkout -b greeting， 在 git checkout 命令里添加一个* -b* 选项，这样如果要切换到的那个分支不存在的话，就会先去创建这个分支，然后再切换到这个新的分支上。这个命令跟先执行 git branch greeting，然后再执行 git checkout greeting 的效果是一样的。
在 greeting 这个分支上，我们可以随便折腾，因为不管怎么折腾，都不会影响在 develop 与 master 分支上保存的项目的状态。
任务：再做一次提交
1：确定当前分支
在终端，项目所在目录的下面，先查看一下项目的分支，确定是在 greeting 这个分支上，这是之前我们基于 develop 分支创建的一个新的分支。
2：修改项目文件
src/main.js<修改>
const greeting = '你好！';
3：做一次提交
在项目的 greeting 分支上，修改了一下项目，做了一次提交，保存了一下应用会说中文 “你好！” 的这个状态。查看提交历史你会发现有两次提交记录，一次是 init，一次就是刚才做的 用中文问候。 每一次提交保存的都是项目的一个状态，init 这次提交保存的是应用会说 hello ~ 的这个状态，用中文问候这次提交保存的是应用会说 你好！ 的这个状态。
7f8fb12 用中文问候 3b5e68c init
任务：重做最后一次提交
刚刚做完了一次提交，你突然发现某些地方错了，打算重新修改一下项目。已经做了的提交我们是不能直接修改的，只能重做一次。先查看一下提交历史，执行：
git log
观察一下最后这次提交的 ID，然后再执行一下：
git reset HEAD~
上面这行命令可以重置一下最近做的这次提交，这时你可以再查看一下项目当前的状态，还有提交的历史，你会发现之前看到 用中文问候 这次提交不见了。这时我们可以在编辑器里编辑项目，然后重新再做一次提交。
git add --all git commit -m '用中文问候'
任务：理解分支
项目当前的分支是 greeting 。回到编辑器，打开 src/main.js，观察文件里的 greeting 的值，现在应该是 你好！ 把当前分支切换到 develop 分支以后，再观察一下 src/main.js 文件里的 greeting 的值，你会发现它的值会是 hello ~ 这是因为在 develop 分支上，还不包含之前在 greeting 分支上做的 用中文问候 这次提交。
在 greeting 分支上，我们把 src/main.js 文件里 greeting 的值从原来的 hello ~ 改成了 你好！，然后做了一次提交，提交时设置的描述信息是 用中文问候。在 develop 分支上并不包含在 greeting 分支上做的 用中文问候 这次提交，所以在这个分支上，src/main.js 文件里的 greeting 的值还是原来的 hello ~ 。
任务：合并分支
在 greeting 分支上，我们修改了项目，让它会说中文 你好！，做了一次提交保存了一下项目的这个状态。我很满意这个结果，所以打算把这个状态合并到项目的 develop 分支上。
1：观察 greeting 分支
在终端，项目所在目录的下面，先确定项目当前的分支是 greeting，执行：
git branch
确定当前分支是 greeting 以后，可以再查看一下在这个分支上的提交历史，执行：
git log --oneline
你应该会看到两次提交。然后在编辑器观察一下 src/main.js 文件里的 greeting 的值，应该是 你好！
2：观察 develop 分支
下面再回到终端，可以把项目当前的分支切换到 develop，因为我们要在这个分支上做一次合并，执行：
git checkout develop
查看在这个分支上的提交历史，执行：
git log --oneline
会显示这个分支上目前只有一次提交。在编辑器，观察 src/main.js 文件里的 greeting 的值，应该是 hello ~
3：合并分支
下面我们要在 develop 这个分支上做一次合并，执行：
git merge greeting
合并用的是 merge 这个子命令，把要合并的分支的名字告诉这个命令，这里就是 greeting，意思就是我们要把在 greeting 分支上做的提交，合并到当前分支上。合并之后，再查看一下 develop 这个分支的提交历史，执行：
git log --oneline
你会发现，现在 develop 这个分支上就会包含之前我们在 greeting 分支上做的提交了。在编辑器，观察一下 src/main.js 文件里的 greeting 的值，现在会是 你好！
合作与备份中心<Remote>
在自己电脑上的项目仓库叫 本地仓库，在别人电脑上的仓库对于你来说就是 远程仓库。有很多服务商提供这种远程仓库的服务，比如 Github、码云、Coding.net 等等。
我在自己的桌面电脑上创建了一个项目，在项目里创建了一个仓库，对项目做源代码管理。我还想在我的笔记本电脑上开发这个项目。所以得想个办法把在桌面电脑上开发的这个项目，复制到我的笔记本上。我在笔记本上修改项目，做了一些提交，如果我要切换到桌面电脑上继续开发，又需要把在笔记本上的这个项目复制到桌面电脑上。
解决这种来回切换开发设备的问题，更好的方法是在一个远程仓库服务商那里给项目创建一个远程仓库。然后在本地仓库这里配置一下，这样在本地仓库这里保存的状态（提交），可以使用命令上传到这个远程仓库里面，也可以通过命令，从远程仓库这里下载保存的状态。比如我先在桌面电脑上对项目做了一些提交，然后把这些提交上传（Push）到远程仓库，等我切换到用笔记本作开发的时候，可以先从项目的远程仓库那里，把在桌面电脑上做的提交下载（Pull）下来。
通过远程仓库，项目可以由多人合作共同开发，每个合作开发者的本地都有一份项目的拷贝，大家可以正常的在本地开发项目，创建新的分支，做一些提交。然后可以把在本地做的提交上传到项目的远程仓库里面，这样项目的其他的合作者都可以从项目的远程仓库下载这些新的提交，把它们合并到自己的本地分支上。
任务：注册远程仓库服务商帐号<Github>
你可以随便找一个远程仓库服务商，在上面注册一个帐号，然后就可以为项目创建远程仓库了，这些远程仓库服务商都提供类似的服务，用法差不多，相关的概念也都差不多。Github 是一个不错的选择，很多著名的开源项目你都可以在这个网站上找到。远程仓库可以是公开的，也可以是私有的。如果你想让别人看到你的项目代码，可以创建一个私有的远程仓库，这样只有特定权限的用户才能看到仓库里的东西。
任务：配置使用 SSH 密钥验证身份
在使用远程仓库的时候，服务商需要验证我们的身份。有两种验证身份的方法，一种是通过我们在服务商那里注册的用户名与密码，还有一种方法是通过 SSH 密钥（Keys），使用这种方式的好处是，只需要配置一次，不需要重复地输入用户名与密码。
1：生成 SSH 密钥
使用 SSH Keys 这种方法验证身份，先得在自己的电脑上生成一对 SSH 密钥，在终端，执行：
ssh - keygen;
一路回车，这个 ssh-keygen 命令会生成两个文件，放在用户主目录下的 .ssh 这个目录里面。一个文件是id_rsa（密钥），还有一个文件是 id_rsa.pub（公钥）。
在服务商那里配置 SSH Keys，需要提供的是 id_rsa.pub 这个文件里的内容，在终端，查看这个文件里的内容，可以执行：
cat ~/.ssh/id_rsa.pub
可以用 cat 命令查看指定的文件里的内容，复制一下输出的文件内容。
2：配置 SSH 密钥
在 Github 网站上通过 github.com/settings/keys 这个地址配置 SSH Keys，新建一个 SSH Key，随便输入一个 Title（标题），比如可以说明一下这个 SSH Key 来自哪一台电脑。选择使用什么标题，不会影响身份验证，真正需要的是在 Key 里填写的内容，把之前复制的，在本地电脑上的 ~/.ssh/id_rsa.pub 文件里的内容粘贴到 Key 这个文本区域的下面，然后点击 Add SSH Key，确定一下就行了。
在你的其它设备上如果也想使用 SSH Key 这种方法的身份验证，需要重复上面的动作。在设备上生成一对 SSH 密钥，复制公钥（id_rsa.pub）内容，在服务商提供的配置界面上，新建一个 SSH Key，输入标题与 Key，再确定一下。
不同的服务商，配置 SSH 密钥的方法与地方可能会有些区别，但你只要知道，几乎所有远程仓库服务商都支持配置 SSH 密钥的身份验证，仔细找一下具体的配置方法就行了。
任务：创建远程仓库<Github>
在 Github 这个远程仓库服务商这里，创建了一个仓库，名字叫 xb2-node ，新创建的这个远程仓库是空白的，里面什么都还没有。如果你在访问 Github 网站的时候遇到问题，也可以选择国内的一些服务商提供的服务，比如码云，Coding.net 等等。
- 登录到 Github 网站
- 新建一个 Repository
- 设置 Repository name（仓库名）：xb2-node
- 仓库类型选择 Public 或 Private
- 点击 Create repository（创建仓库）
在创建远程仓库的时候，可以选择仓库是 Public（公开） 还是 Private（私有） 的，仓库的类型在以后也可以通过设置来修改。如果选择 Public，就表示任何人都可以看到你创建的这个仓库，使用这个仓库里的代码。如果设置成 Private，默认除了你自己，谁也没有权限访问你的这个仓库。
公开与私有仓库都可以设置 Collaborators（合作者），也就是跟你合作开发这个项目的人，这些人会有权限对仓库做一些事情，比如把他们自己在本地电脑上对项目做的一些提交，推送到这个远程仓库里面。
远程仓库会提供两种类型的地址，一种是 HTTPS 类型的，还有一种是 SSH 类型的地址。选择哪个都可以，区别是，如果选择用 HTTPS 类型的远程仓库地址，验证身份的时候要通过用户名与密码，选择使用 SSH 类型的远程仓库地址，可以通过 SSH 密钥验证身份。
下面是刚才创建的 xb2-node 这个仓库的两种类型的地址：
- HTTPS：https://github.com/ninghao/xb2-node.git
- SSH：git@github.com:ninghao/xb2-node.git
在上面的远程仓库地址里面，ninghao 这部分内容是你在服务商那里注册的用户名，xb2-node 这部分指的是仓库的名字。这两种类型的地址，除了验证我们用户身份的时候，使用的方法不一样，其它的都是一样的，它们都指向的是我们在服务商那里创建的一个特定的远程仓库。
任务：添加远程仓库
在服务端那里创建了远程仓库，需要在本地仓库里面配置一下，给它添加一个远程，这样就可以在本地通过命令，把本地的东西上传到远程，也可以从远程那里下载。
1：复制远程仓库地址
复制一下新创建的远程仓库的地址，可以选择使用 SSH 类型的地址，因为之前我们已经配置过了 SSH Keys，所以可以使用 SSH 类型的仓库地址，如果没有配置 SSH Keys，就只能使用 HTTPS 类型的仓库地址。
2：在本地仓库添加远程
在终端，先进入到在本地的项目所在目录，然后先查看一下本地仓库的远程，执行：
git remote -v
执行上面这行命令不会得到任何结果，因为目前在本地仓库里还没有添加任何远程。添加远程，执行：
git remote add origin git@github.com:ninghao/xb2-node.git
在本地仓库里面添加远程，用的是 git remote add 命令，origin 是我们给要添加的远程起的一个名字，你可以随便定义要添加的这个远程的名字，比如 yuancheng，只不过 origin 是一个惯用的远程的名字。如果你想使用多个远程，这些远程就需要使用不同的名字了。
在远程的名字后面，要加上远程仓库的地址，这样以后就可以通过远程的名字，访问到这个远程仓库了。注意你要把这个远程仓库的地址替换成自己在 Github 上创建的远程仓库地址。
3：查看项目的远程
添加了远程以后，再查看一下本地的远程，执行：
git remote -v
执行 git remote 命令的时候加上了一个 -v 选项，它可以显示更详细的信息，这次会得到类似下面这样的信息：
origin git@github.com:ninghao/xb2-node.git (fetch) origin git@github.com:ninghao/xb2-node.git (push)
提示现在我们的项目里面，已经有了一个叫 origin 的远程，后面还会显示这个远程的具体的地址，fetch 指的是下载时用的地址， push 指的是上传时用的地址，默认它们都是一样的地址。
4：把本地分支推送到远程仓库
在本地仓库，成功添加了一个叫 origin 的远程，我们现在就可以把本地上的东西上传到这个远程，也可以把远程上的东西下载到本地。上传本地仓库里的东西，执行：
git push origin master
用的是 git push 命令，后面要加上远程的名字，还有在本地要推送到这个远程的分支。比如执行 git push origin master，意思就是把本地上的 master 分支上的东西上传到 origin 这个远程。
远程仓库服务商都会给我们提供一个界面，可以浏览仓库里的东西，在远程仓库页面，刷新一下，你会发现用 git push 上传上来的东西。有了这个远程仓库以后，你的开发工作仍然是在本地设备上进行，只不过可以时不时的把自己在本地设备上做的提交，上传到项目的远程仓库，这样项目的其他合作者都可以下载你做的提交，你自己在其它设备上也可以下载这些最新的提交。
任务：把远程仓库复制到本地
我们在项目里添加了一个远程仓库，把本地上的某个分支上的东西，上传到了这个远程仓库，这个远程仓库有点像是项目的备份中心。即使我把在本地设备上的项目整丢了或玩坏了，这都不要紧，因为我们现在随时可以把远程仓库里的东西复制到我们的本地设备上。这个复制的动作叫 Clone（克隆）。
假设我需要在自己的另外一台设备（电脑）上同时开发 xb2-node 这个项目，打开这台设备以后，可以完成下面这几件事儿：
1：克隆远程仓库
在远程仓库页面复制一下远程仓库的地址，然后在终端，先进入到想在保存项目的地方：
cd ~/desktop
继续执行：
git clone git@github.com:ninghao/xb2-node.git
把一个远程仓库克隆到本地，用的是 git clone 命令，后面加上要克隆的远程仓库的地址。注意这里我用的是 SSH 类型的地址，这就要求提前配置好 SSH 密钥，也就是我需要把我现在用的这台设备上生成的公钥内容，添加到我的远程服务商帐号那里。这样才能在这台设备上使用 SSH 类型的远程仓库地址，不然就只能用 HTTPS 类型的远程仓库地址。
我是在两台设备上做的这个任务，你可以选择在同一台设备上做这个任务，在克隆的时候可以指定一个新的目录，比如：
git clone git@github.com:ninghao/xb2-node.git xb2-node-2
这样会把克隆的项目放在 xb2-node-2 这个目录的下面，也就是你的桌面上应该会出现两个目录，一个是 xb2-node，一个是 xb2-node-2。然后你可以新建两个命令行界面，分别进入到这两个目录里面，再去执行相应的命令。
2：查看提交历史
在克隆时如果不特别设置项目的目录，默认会创建一个跟远程仓库名字一样的目录。进入到这个目录的下面：
cd xb2-node
进到项目里以后，可以查看提交历史与分支
git log
查看历史的时候，你会发现要只有一次提交记录。在我的另一台设备上对项目做过两次提交，但这两个提交是在 develop 这个分支上，并没有跟 master 分支合并。创建了远程仓库以后，我把那台设备上的 master 分支推送给了这个远程仓库，推送的是本地的 master 分支，这个分支上只包含一次提交，就是 init 这个提交。
3：创建开发分支
git branch
查看分支会显示项目当前有一个默认的 master 分支，在这台设备上开发可以创建一个 develop 分支，执行：
git checkout -b develop
任务：推送（上传）与拉取（下载）
在一台设备上推送新的东西到远程仓库，然后在另一台设备上可以下载新推送到远程仓库里的东西。
1<macOS>：推送本地分支到远程仓库
先在最开始我们开发的项目里做一些事情，在终端，进入到项目所在目录以后，执行：
git checkout master
把项目当前分支切换到 master ，然后去合并一下 develop 分支，执行：
git merge develop
这样 master 分支上就会包含 develop 分支上的提交了。现在相比项目的远程上的 master 分支，我们本地的 master 分支上有了新的提交，可以把这些新的提交上传到远程仓库里面，执行：
git push origin master
刷新远程仓库页面，你就会发现刚刚推送上来的新的提交了。
2<Windows>：下载远程仓库里的提交
切换到另一台设备，如果你是在同一台设备上做的这个任务，就是切换到另一个项目目录，比如 xb2-node-2。我用的是一台 Windows 设备。下面我要在这台设备上的项目里下载在远程仓库里包含的新的提交。
在终端，确定是在项目所在目录的下面，查看一下项目里的分支，执行：
git branch -a
这次执行 git branch 命令的时候，多加了一个 -a 选项，它会显示项目里全部的分支，你会看到里面有一些 remotes 开头的分支，这些是指的是在远程上的分支。当前是在 develop 分支上，我们可以把当前分支切换到 master 这个分支上，执行：
git checkout master
在这个分支上可以下载远程仓库里的新东西，同时可以把它们合并到当前这个分支上，也就是合并到 master 这个分支上。执行：
git pull
完成以后可以再查看一下当前分支上的提交历史，执行：
git log
之前在这个分支上只有一次提交，不过我们在下载合并了远程仓库里的提交之后，当前这个 master 分支上就会出现两次提交。下面再把当前分支切换到 develop 这个本地分支上，执行：
git checkout develop
开发时我都希望在这个分支上进行，现在这个分支上只有一次提交，所以我们可以合并一下 master 分支，执行：
git merge master
合并之后再查看这个 develop 分支上的提交历史，你会发现两次提交。
你在做这个任务的时候，不一定非得真的用两台不同的设备，你可以在同一台设备上完成这个任务。主要目的是理解这个开发流程，你在一台设备上修改了项目做了一些提交，可以把做的这些提交上传到项目的远程那里。这样你在其它设备上继续开发项目的时候，可以先把之前上传到远程上的新东西（提交）下载并且合并到本地项目仓库里。在这台设备上做了一些提交以后，再把它们也推送到项目的远程仓库。
任务：添加 README.md 说明文档
在一台设备上的项目里添加了一个文件，做一次提交，推送到远程。在另一台设备上下载这次提交。是不是开始嫌麻烦了啊，完成一个简单的事情要做这么多动作，无论如何，我们都要慢慢地熟悉与适应这种工作方式。
1<Windows>：创建新的分支
我想在项目里添加说明文档，虽然这是一个很简单的任务，但是为了演示 Git 的开发流程，所以我还是打算创建一个新的分支，然后在这个新的分支上添加项目的说明文档。
在终端，项目所在目录的下面，确定当前是在 develop 这个分支上，下面基于这个分支创建一个新的分支并且切换到这个新的分支上，执行：
git checkout -b readme
2<Windows>：创建说明文档
在编辑器，项目的根目录下面，新建一个叫 README.md 的文件，内容如下：
# 小白兔的开发之路
README.md 经常会在项目的根目录下出现，在这个文件里可以介绍一下你的项目。 .md 后缀，表示文件里的内容用的格式是 Markdown。文件里输入了一行内容：# 小白兔的开发之路 ，文字前面的 # 号，就是 Markdown 里设置标题用的格式，一个 # 号表示后面的内容是一级大标题，如果用 ##，就表示后面的内容是二级大标题。
3<Windows>：提交，合并然后推送
在终端，先做一次提交，执行：
git add .
上面这行命令可以添加所有发生在根目录下的修改，确定提交：
git commit -m '添加说明文档'
这次提交是在 readme 这个分支上做的，假设我们现在完成了添加说明文档这件事儿，下面可以把当前分支切换到 develop，执行：
git checkout develop
在这个 develop 分支上做一次合并，合并的是 readme 这个分支。执行：
git merge readme
develop 是我们决定要用的一个专门用来做开发的分支，没什么特别的，你也可以选择不用这个分支，直接用 master 分支也可以。之所以单独创建一个开发专用的分支，主要是想让 master 分支上的项目是随时可以使用的，也就是适合在生产环境上运行的应用。
如果我们决定让 master 分支上也包含刚才做的提交，可以再切换到 master 分支：
git checkout master
再让 master 分支合并一下 develop 分支，执行：
git merge develop
合并之后，我们可以把在本地 master 分支上的新东西推送到远程仓库，执行：
git push origin master
4<macOS>：从远程那里下载最新的提交
现在我们可以切换到另一台设备，如果你是在同一台设备上做的这个任务，就是切换到另一个项目目录，比如 xb2-node-2。在终端，确定当前是在项目所在目录的下面，并且确定项目当前的分支是 master 这个分支。在远程那里下载最新的提交，执行：
git pull origin master
这次我们在用 git pull 命令的时候，设置了一下具体的远程，还有远程分支的名字，意思就是下载 origin 这个远程的 master 分支上的新东西，再把它们合并到本地当前的分支上。
查看一下当前分支上的提交历史，你会看到 “添加说明文档” 这次提交。这次提交是我在另一台设备上做的，把它上传到了远程以后，又在这台设备上把这次提交下载下来，合并到了本地 master 分支上。在编辑器，你可以在根目录下面，发现多了一个 README.md 文件。
在终端，再把当前分支切换到 develop：
git checkout develop
合并一下 master 分支：
git merge master
再查看本地 develop 分支上的提交，在这个本地的 develop 分支上，也会出现 “添加说明文档” 这次提交。
任务：忽略不需要做源代码管理的东西<.gitignore>
在项目里创建了一个仓库以后，默认 Git 会跟踪这个目录里所有的文件，不过在项目里有些东西是不用做源代码管理的，比如一些日志文件，用户上传的文件，系统自动生成的一些文件等等。这些东西可以在 .gitignore 文件里说明一下。
1：切换到 develop 分支
在终端，项目所在目录的下面，执行
git checkout develop
2：添加 .gitignore 文件
在项目根目录的下面，创建一个 .gitignore 文件，在这个文件里面列出不需要做源代码管理的东西，这样 Git 就不会跟踪这些东西了。以后如果你发现有不需要做源代码管理的东西，也就是不想包含在项目仓库里的东西，可以把它们写在这个 .gitignore 这个文件里。
.gitignore：
# compiled output /dist /node_modules # Logs logs *.log npm-debug.log* # OS .DS_Store # IDE - VSCode .vscode/* !.vscode/settings.json !.vscode/tasks.json !.vscode/launch.json !.vscode/extensions.json
上面是在 Node.js 项目里经常要忽略掉的，也就是不需要做源代码管理的东西。比如 /dist 指的是 dist 目录，这样就会忽略掉这个目录里的所有的文件，.log 意思就是忽略掉所有文件名里带 .log 后缀的文件，.vscode/** 的意思是忽略掉 .vscode* 目录里的所有的文件，!.vscode/settings.json 的意思是，不忽略 .vscode/settings.json 文件。
