网络上关于Git和GitHub的教程不少，但是这些教程有的命令太少不够用，有的命令太多，使得初期学习的时候需要额外花不少时间在一些当前用不到的命令上。
这篇文章主要的目标是用较少的时间学习Git和GitHub的基本使用。在足够一般使用的前提下，尽量减少命令。
如果需要其他命令，到时候再去其他地方了解就行了。

目录

零、Git是什么

Git 是什么？

直接记录快照，而非差异比较

近乎所有操作都是本地执行

Git 保证完整性

Git 一般只添加数据

三种状态

一、Git的主要功能：版本控制

二、概览

1.个人本地使用

2.个人使用远程仓库

三、Git for Windows软件安装

四、本地Git的使用

1.新的仓库-》初始化

2.文件的添加和提交

3.文件的修改

4.版本回退！

5.清除未追踪的文件

6.关于git status中文乱码问题

五、Github与Git的关联

1）本地Git和Github的连接

2）创建远程仓库并与本地关联

六、团队合作开发

零、前期准备：

一、创建开发分支

二、Fork项目到个人的仓库

三、Clone项目到本地

四、和团队项目保持同步

五、push修改到自己的项目上

六、请求合并到团队项目上

七、团队项目负责人审核及同意合并请求

七、Github的其他介绍

1）获取其他人的远程仓库

2）另一种关联远程空仓库的方法

3）使用GitHub的好处

八、一些可能碰到的问题

其中 零、一、七 是由团队项目负责人来完成的。

零、Git是什么

Git 是什么？

那么，简单地说，Git 究竟是怎样的一个系统呢？ 请注意接下来的内容非常重要，若你理解了 Git 的思想和基本工作原理，用起来就会知其所以然，游刃有余。 在学习 Git 时，请尽量理清你对其它版本管理系统已有的认识，如 CVS、Subversion 或 Perforce， 这样能帮助你使用工具时避免发生混淆。尽管 Git 用起来与其它的版本控制系统非常相似， 但它在对信息的存储和认知方式上却有很大差异，理解这些差异将有助于避免使用中的困惑。

直接记录快照，而非差异比较

Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方式。 从概念上来说，其它大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar 等等） 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 （它们通常称作 基于差异（delta-based） 的版本控制）。

Figure 4. 存储每个文件与初始版本的差异.

Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中，每当你提交更新或保存项目状态时，它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。

Figure 5. 存储项目随时间改变的快照.

这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。 稍后我们在Git 分支讨论 Git 分支管理时，将探究这种方式对待数据所能获得的益处。

近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统，Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。

举个例子，要浏览项目的历史，Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改， Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。

这也意味着你在离线或者没有 VPN 时，几乎可以进行任何操作。 如你在飞机或火车上想做些工作，就能愉快地提交（到你的 本地 副本，还记得吗？）， 直到有网络连接时再上传。如你回家后 VPN 客户端不正常，那么也仍能工作。 使用其它系统的话，做到这些是不可能或很费力的。 比如，用 Perforce 的话，没有连接服务器时几乎不能做什么事；而用 Subversion 和 CVS 的话， 你能修改文件，但不能向数据库提交修改（因为你的本地数据库离线了）。 这样似乎问题不大，但是你可能会惊喜地发现它带来的巨大的不同。

Git 保证完整性

Git 中所有的数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层，是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件，Git 就能发现。

Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。 这是一个由 40 个十六进制字符（0-9 和 a-f）组成的字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样：

24b9da6552252987aa493b52f8696cd6d3b00373

Git 中使用这种哈希值的情况很多，你将经常看到这种哈希值。 实际上，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

Git 一般只添加数据

你执行的 Git 操作，几乎只往 Git 数据库中 添加 数据。 你很难使用 Git 从数据库中删除数据，也就是说 Git 几乎不会执行任何可能导致文件不可恢复的操作。 同别的 VCS 一样，未提交更新时有可能丢失或弄乱修改的内容。但是一旦你提交快照到 Git 中， 就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。

这使得我们使用 Git 成为一个安心愉悦的过程，因为我们深知可以尽情做各种尝试，而没有把事情弄糟的危险。 更深度探讨 Git 如何保存数据及恢复丢失数据的话题，请参考撤消操作。

三种状态

现在请注意，如果你希望后面的学习更顺利，请记住下面这些关于 Git 的概念。 Git 有三种状态，你的文件可能处于其中之一： 已提交（committed）、已修改（modified） 和 已暂存（staged）。

• 已修改表示修改了文件，但还没保存到数据库中。

• 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

• 已提交表示数据已经安全地保存在本地数据库中。

这会让我们的 Git 项目拥有三个阶段：工作区、暂存区以及 Git 目录。

Figure 6. 工作目录、暂存区域以及 Git 仓库.

工作区是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。

暂存区是一个文件，保存了下次将要提交的文件列表信息，一般在 Git 仓库目录中。 按照 Git 的术语叫做“索引”，不过一般说法还是叫“暂存区”。

Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分，从其它计算机克隆仓库时，复制的就是这里的数据。

基本的 Git 工作流程如下：

1. 在工作区中修改文件。

2. 将你想要下次提交的更改选择性地暂存，这样只会将更改的部分添加到暂存区。

3. 提交更新，找到暂存区的文件，将快照永久性存储到 Git 目录。

如果 Git 目录中保存着特定版本的文件，就属于 已提交 状态。 如果文件已修改并放入暂存区，就属于 已暂存 状态。 如果自上次检出后，作了修改但还没有放到暂存区域，就是 已修改 状态。 在 Git 基础 一章，你会进一步了解这些状态的细节， 并学会如何根据文件状态实施后续操作，以及怎样跳过暂存直接提交。

一、Git的主要功能：版本控制

1. 版本：
   想想你平时用的软件，在软件升级之后，你用的就是新版本的软件。你应该见过这样的版本号：v2.0 或者 1511（表示发布时为15年11月），如下图：

   

   
   那么如果你修改并保存了一个文件，从版本管理的角度来说，你得到的是这个文件的新版本。
   可是很多情况下，这种修改是不可逆的。你修改完之后，无法回到你修改前的样子。为了避免这种情况，有的人会把新版本的内容保存到一个新的文件里面。
   由于 Git 更多地用于代码管理，举个程序员的例子。比如以下是计算机专业学生的作业：

   

   
   这样存储多个文件夹，可能会造成混乱。你可能想保存以前写的代码，因为它们可能在以后会用到。但是更多的时候是，你不知道各个文件夹都做了什么修改。
   这时候你需要一款软件帮你管理版本，它就是Git。
2. 控制：
   你可以用Git来对这些不同的版本进行控制。还可以很方便地查看两个不同版本之间的不同之处。
   ——使用Git，你只保存最新的一份文件就可以了。
   ——那我以前的文件怎么办？
   ——可以用Git的 reset 帮你把文件回退到你想要的版本。
   ——如果回去了，那我的最新版本呢？
   ——还可以用 reflog 和 reset 的组合来还原。

二、概览

所有命令前都要加 git，如表中的init是指 git init。
点击命令可直接跳转至本文第一次使用的地方。
以下命令都在命令行里执行。

1.个人本地使用

2.个人使用远程仓库

可以用一张图直观地看出以上主要的命令对仓库的影响。

图片引用自：Git introduction for CVS/SVN/TFS users

图片引用自：工作区和暂存区 - 廖雪峰的官方网站 （做了点修改）

对照查看两张图：

• workspace 即工作区，逻辑上是本地计算机，还没添加到repository的状态；
• staging 即版本库中的stage，是暂存区。修改已经添加进repository，但还没有作为commit提交，类似于缓存；
• Local repository 即版本库中master那个地方。到这一步才算是成功生成一个新版本；
• Remote repository 则是远程仓库。用来将本地仓库上传到网络，可以用于备份、共享、合作。本文将使用Github作为远程仓库的例子。

三、Git for Windows软件安装

Git for Windows（又msysgit）

• 安装包可以到官方网站[1]下载，或者在github[2]下载。如果下载不下来，可以把链接复制下来用迅雷下载。如果用迅雷下载不放心，在下载完后去在github下载的那个地方查看SHA-256值，并和下载的文件对比，如果值一样就可以放心使用。

• 安装的时候一路点击Next就行了。

• 刚安装完打开后，窗口比较小。如果不太习惯，可以把它改大一些。

  1. 首先移到窗口右下角边缘，出现箭头后把窗口拉大。
  2. 点击窗口顶部左边的图标 -> Options... -> Window -> Current size -> OK
     这样以后打开窗口都会是调整后的大小。

Git for Windows从2.8.0版本[3]开始，默认添加环境变量，所以环境变量部分就不用再手动配置了。（这句可以无视）

四、本地Git的使用

这里先不引入Github，而是在本地计算机上的操作。

打开命令行（cmd）或者在想要创建repository的地方右键鼠标并点击 Git Bash Here 打开窗口。

1.新的仓库-》初始化

运行 git init 来初始化仓库，如下图：

它会创建一个隐藏的文件夹 .git 这里不去管它是用来干嘛的。关闭windows的显示隐藏的项目吧。

2.文件的添加和提交

我在这个文件夹里面创建了一个 today.txt 的文件。并且不要脸地祝自己儿童节快乐：

这时我使用 git status 来查看有什么变化：

它告诉我有一个还未追踪的文件，并提示我可以使用 git add <file>... 把它加进去。

但是我并不打算把所有命令都介绍一遍，所以我选择使用上面概览时所提到的 git add -A 命令。

嗯，什么提示都没有。没关系，我们再次使用 git status ：

状态变了！说明add成功。再看看它的提示 Changes to be committed ，也就是说现在可以执行commit了。下面一行则告诉你如何将文件从stage里移出，这里不管。
执行 git commit -m "提交信息" 将文件提交到repository里。提交信息用英文的双引号括起来。

这时运行 git log 就可以看到提交的记录了：

这样第一步就完成了。

也许你会奇怪：为什么要有一个add，直接commit不就行了？这是因为stage有很多用处，具体可以去查找相关资料。这里就算不了解问题也不大。

3.文件的修改

接着我修改文件内容。改成祝大家儿童节快乐好了 (～￣▽￣)～

我们用 git status 看看有什么变化：

这和之前的提示不一样了。之前是这个：

比较一下就会看到，之前的是添加新文件，当时文件还没被追踪（untracked），而这次是更改已经追踪（tracked）的文件。

现在我们通过git看看文件做了哪些变化，执行 git diff ：

它默认跟最新的一个commit进行比较。
红色（前面有减号-）表示删除，绿色（前面有加号+）表示添加。
因此，在git看来，我们是删除了原来那一行，并添加了新的两行。这在文件内容特别多的时候效果比较明显。
这个命令在以下情况可以使用：

• 你忘记改了什么，又想知道
• 别人发给你新版本，你想知道更改了什么

注：如果你用 windows 创建 txt 文件，并用自带文本编辑器来编辑文本，得到的编码是 GBK 。而 Git 读取文件时，使用 UTF-8 无 ROM 编码。因此会出现中文无法正常显示的情况。

假如我现在想撤销这些更改，执行 git checkout -- . 就行了：

恩，仍然没有任何提示。执行 git status 看看：

上一个status的提示已经不见咯。再来看看文件：

果然复原了！那么再次进行修改：

接着：
git add -A
git commit -m "将[自己]改为[米娜桑]"

用 git log 看看提交（commit）记录：

嗯。现在有两个提交了。

4.版本回退！

如果我写的是一篇很长的文章，并且在之前的版本基础上修改了一部分内容，生成一个新的commit，现在我发现我在修改的时候删掉了一部分内容，而这部分内容是我现在需要用到的，怎么办？版本回退！

还是以刚才的文件为例，现在我试着将文件回退到第一个commit时的状态。但在这之前，我们看看这个文件夹里面的东西：

.git 文件夹因为本来就是隐藏的，我在关了 显示隐藏的项目 的选项后，它就不显示了。
现在看到的是只有一个文件，而且是最新的一个版本。

文件的修改日期为 2016\6\1 21:52

从刚才的 git log ：

我们看到两行黄色部分是以 commit 开头的，后面接着一串字符。这一串字符是16进制的数，是一串哈希值。我们叫它版本号就行了。

开始回退，执行 git reset --hard 1df0573 （取版本号前7位就可以了）：

这里提示HEAD已经更改指向至1df0573了。此时文件：

其内容：

已经回到我的第一个版本的状态。

这里文件的修改日期被更改为我现在的时间 2016\6\2 19:29
这是由于文件的修改日期是由windows修改的，因为它检测到这个文件被修改了。而我们刚才从最新版本回退到现在这个版本，就像是我们手动修改了文件内容一样，事实上是由git来完成的。
其实可以不管上面这一段

现在再执行 git log ：

新版本的commit记录不见了！这就是 reset --hard 的力量，很好很强硬！

现在已经看到了之前版本的内容，那么如何回到最新版呢？
先执行 git reflog ：

可以看到HEAD的变化情况。
第一行表示当前HEAD所在的版本号是 1df0573 ，而之所以在这个版本号，是由于我们执行了reset命令。
看第二行，它告诉我们，这个HEAD所在的版本号是 ad93b89 ，这个版本号是在执行commit之后形成的。

此时我再用一次reset，将HEAD指向 ad93b89 ， 同时查看log ：

git reset --hard ad93b89
git log

回到第一次reset前的状态了！

5.清除未追踪的文件

通常在reset或者pull（后面会讲）之前要做两件事：

• 将新添加且为追踪的文件删除掉（比如编译程序后所产生的文件）
• 已追踪的文件已有修改，但又不需要这些修改，则将它们还原

还原已做修改的tracked文件，上面已经讲过。
现在看看如何用命令删除新加的文件。

首先我手动创建个文件，用来演示：

用checkout是没办法删除掉它的，使用 git clean -xf ：

这个命令的杀伤力比较大，它删除当前目录下所有没有track过的文件。不管它是否是.gitignore文件里面指定的文件夹和文件。当然，也有杀伤力比较小的，但这里就不介绍了。

6.关于git status中文乱码问题

如果你的文件名是中文的，在使用git status时会乱码。如下图所示：

如果要使它显示为中文，在命令行里执行：git config --global core.quotepath false。
再使用 git status：

如果 git log 也会乱码，执行以下命令：

git config --global i18n.commitencoding utf-8
git config --global i18n.logoutputencoding utf-8

请根据需要将后面的 utf-8 替换成你想要的编码。如果是团队项目，请确保所有成员的设置都一致。

五、Github与Git的关联

上面的操作都是在本地计算机上产生影响的，一般也够用了。
如果你是程序员，想和其他人分享你的代码，或者合作开发，可以用Github。

1）本地Git和Github的连接

1. 到Github[4]注册账号。

2. 本地配置用户名和邮箱（如果已经设置好，跳过该步）：

   • git config --global user.name "你的用户名"
     git config --global user.email "你的邮箱"
     如图所示：

     ​

   • 或者你直接在config文件里改，位置在 C:\Users\你的用户名\.gitconfig 。如下图所示，添加相应信息：

     ​

3. 生成ssh key
   运行 ssh-keygen -t rsa -C "你的邮箱" ，它会有三次等待你输入，直接回车即可。

   ​

   
   将生成的ssh key复制到剪贴板，执行 clip < ~/.ssh/id_rsa.pub （或者到上图提示的路径里去打开文件并复制）：

   ​

4. 打开Github，进入Settings：

   ​

   
   点击左边的 SSH and GPG keys ，将ssh key粘贴到右边的Key里面。Title随便命名即可。

   ​

   
   点击下面的 Add SSH key 就添加成功了。
   测试一下吧，执行 ssh -T git@github.com ：

   ​

   
   嗯，这样就成功了！

   注：

   • 对于 oschina 的 “码云” ，执行 ssh -T git@git.oschina.net
   • 对于 coding 的 “码市” ，执行 ssh -T git@git.coding.net

2）创建远程仓库并与本地关联

1. 创建远程仓库
   首先是在右上角点击进入创建界面：

   ​

   接着输入远程仓库名：

   ​

   点击 Create repository 就创建好了。其他选项可以暂时不管。

2. 将远程仓库和本地仓库关联起来

   先到Github上复制远程仓库的SSH地址：

   ​

   有两种方式可以关联，一种是SSH，一种是HTTPS。由于HTTPS比较慢，所以推荐使用SSH。
   注意SSH的地址格式是这样开头的： git@github.com

   运行 git remote add origin 你复制的地址 ：

   ​

   如果你在创建 repository 的时候，加入了 README.md 或者 LICENSE ，那么 github 会拒绝你的 push 。你需要先执行 git pull origin master。

   执行 git push -u origin master 将本地仓库上传至Github的仓库并进行关联：

   ​

关联已经完成！

以后想在commit后同步到Github上，只要直接执行 git push 就行啦：

可以在Github上看到修改：

六、团队合作开发

目录

零、Git是什么

Git 是什么？

直接记录快照，而非差异比较

近乎所有操作都是本地执行

Git 保证完整性

Git 一般只添加数据

三种状态

一、Git的主要功能：版本控制

二、概览

1.个人本地使用

2.个人使用远程仓库

三、Git for Windows软件安装

四、本地Git的使用

1.新的仓库-》初始化

2.文件的添加和提交

3.文件的修改

4.版本回退！

5.清除未追踪的文件

6.关于git status中文乱码问题

五、Github与Git的关联

1）本地Git和Github的连接

2）创建远程仓库并与本地关联

六、团队合作开发

零、前期准备：

一、创建开发分支

二、Fork项目到个人的仓库

三、Clone项目到本地

四、和团队项目保持同步

五、push修改到自己的项目上

六、请求合并到团队项目上

七、团队项目负责人审核及同意合并请求

零、前期准备：

首先把队友直接push的权限关掉，即设置成Read。这样可以防止队友误操作，未经审核就把代码push到团队项目上。
Teams用来分配issue的时候会用到，所以保留下来，并不是没有用。

一、创建开发分支

master分支一般用来发布稳定版本，dev分支（开发分支）用来发布开发版本。
输入分支名称后，下面会跳出Create branch，点击即可创建。

下面图片写的是develop，是因为我们这个项目已经有dev分支了。如果你们没有dev分支，那么名字改成dev即可。这个影响不大。

分支创建完毕后，会自动跳转到dev分支。由于dev分支是从master分支上创建的，因此内容与master分支一致。

二、Fork项目到个人的仓库

点击右上角的Fork，并选择你的账号（一般在第一个）。就可以Fork团队项目到个人仓库啦。

Fork完成后

三、Clone项目到本地

首先是clone，clone的地址可以直接点击按钮复制（如下图）。

推荐使用SSH协议，用HTTP协议有时会出问题。
注意，这里clone的是你自己仓库里的项目

打开git命令行，输入指令和刚才复制的地址，回车即可克隆到本地

此时你只能看到master分支，并没有把dev分支clone下来。使用 git branch 命令查看本地分支，发现本地只有master分支。如下图的①

如上图的②，使用 git branch -a 查看所有分支，就能看到远程分支。
根据远程分支，我们可以创建一个新的本地分支dev，并把该项目的dev分支的内容放到本地dev分支。如上图③。

git checkout -b dev origin/dev 的意思是，创建一个dev分支（-b），并把远程dev分支（origin/dev）的内容放在该分支内。接着切换到该分支（checkout）

现在使用 git branch 可以查看两个分支，并且用 ls 或者 dir 就能看到dev分支的内容了。想切换回master分支的时候，再用 git checkout master 即可。

上面的操作完成后，你就可以在本地进行开发了。但是如果要将你修改完的代码合并到团队项目上，还需要进行下面的操作。

四、和团队项目保持同步

首先查看有没有设置upstream，使用 git remote -v 命令来查看。如下图①

如果没有显示upstream，则使用 git remote add upstream 团队项目地址 命令。如上图②
接着再次使用 git remote -v ，如果如上图③，显示出了upstream，那么就设置好了

开始同步。首先执行 git fetch upstream 获取团队项目最新版本。如下图①

此时并没有把最新版本合并到你本地的分支上，因此还需要一步。如上图②，当前分支是dev分支，执行 git merge upstream/dev 命令后，会将源分支（upstream/dev）合并到当前分支（dev）。

如果你是在本地的master分支上开发，那么在使用该命令前，先切换到master分支。
merge的时候，有可能碰到冲突。需要解决冲突才能继续下面的操作。冲突的解决可以参考→ 冲突的解决

五、push修改到自己的项目上

解决冲突后，就可以使用 git push 命令将本地的修改同步到自己的GitHub仓库上了。

注意，在当前所在分支使用push，会push到与这个分支相关联的远程仓库分支。这里dev分支与origin/dev关联，因此push到GitHub上的dev分支。

六、请求合并到团队项目上

首先到你的GitHub上，进入你Fork的仓库里。点击红框处的Pull request

下图左边红框，表示要合并到fzu2015/CourseManagement项目的dev分支。
下图右边红框，表示要从自己仓库的dev分支发起合并请求。
点击红框处的 Create pull request就可以发送合并请求了。

当然，在发送请求之前，你可以检查一下你都改了哪些东西。在上面那个页面往下拉，就可以看到两者的对比。如下图

以上操作结束后，团队成员的流程就结束了。最后一步交给团队项目负责人来完成。

七、团队项目负责人审核及同意合并请求

首先进入GitHub的团队项目仓库中。此时右边的Pull requests显示当前项目有几个Pull request。点击进入查看。

选择一个Pull request

项目负责人审核有两个要注意的地方

• 一个是下图的①。一定要看清楚是合并到哪个分支。这里是从schaepher的dev分支合并到fzu2015的dev分支。

• 另一个是下图的②。点击进去后，就可以查看该Pull request对项目做了哪些修改。这样如果有问题，可以及时发现，并关闭该Pull request。

  如果关闭了，一定要告诉队友，否则他可能会不知道。虽然也可以直接在下面发布Comment告诉他，但队友不一定看到。

  ​

• 如果没有问题，可以点击Merge pull request。这样就合并好了。

七、Github的其他介绍

1）获取其他人的远程仓库

看到别人的代码，想要获取到本地计算机慢慢研究或者修改，可以用Git将其下载下来。
以我和一位同学合作的仓库为例，链接：schaepher/blogsbackup

这是我们用来备份博客园博客的一个小程序，主要用于助教备份学生的博客。

1. 复制别人远程仓库的SSH。方法和上面关联git一样，进入仓库页面后，就能找到SSH地址。

   ​

2. 执行 git clone 复制的SSH地址

   ​

   整个项目42M，花了点时间才clone下来。

有一点要注意：这样直接clone别人的仓库后，不能push上自己的修改。

2）另一种关联远程空仓库的方法

在知道了clone之后，你就可以更简单的创建并关联一个空仓库了。

1. 在Github上创建仓库，上面有提到，这里不多讲
2. 复制刚才创建的仓库的SSH
3. clone到本地

这样可以不用再做关联了。省去了上面的 init 和 git remote add origin 以及 git push -u origin master 。

3）使用GitHub的好处

• 全球最大的同♂性交友网站（逃
• （严肃脸）很多牛逼程序员和牛逼公司的开源项目都放在这上面，有丰富的资源可以学习
• 别人（如HR）可以通过你的Github大致了解你的水平。《怎样花两年时间去面试一个人》 这篇文章的后面部分讲到了Github

八、一些可能碰到的问题

这篇文章基本只介绍主线操作，而在操作过程中，可能有误操作或者其他问题。我把这些问题集中放在另一篇博客里面（这里列出目录）。这样这篇文章不会显得太长。

• 一、 解决merge时出现的冲突
• 二、 回退一个merge
• 三、 获取某一commit的修改