GitHub使用教程

概要

本篇主要讲述git在windows环境下通过命令管理代码的方式
官方帮助文档：https://git-scm.com/doc

一. 下载git

https://git-scm.com/download/win

可以点击“Click here to download ”下载最新win 64位安装包，或者在“Standalone Installer”中进行下载。安装时一直下一步就可以了。

安装后，在空白文件夹中，点击鼠标右键，可以看到这两个选项证明安装成功了。Git GUI表示可视化操作界面(界面好丑)，Git Bash 表示通过命令来管理(逼格很高)。本章主要将Bash选项。

二. 初始化本地仓库

特别注意：目录文件夹不要使用中文，受管理的文件尽量不用使用中文

//创建一个空的 Git 存储库
git init

在选定好的文件夹中，打开Git Bash，输入 git init 命令

命令执行后，文件夹中会出现.git的隐藏文件，存储库的配置文件都在其中

设置签名

为了区分不同开发人员的身份，需要开发人员提供自己的唯一标识，即：用户名&邮箱
注意这里的用户名和签名可以随意设置，你甚至可以设置一个不存在的邮箱，它仅仅是作为一个标识。
Git签名分为两种情况：
项目级别签名：项目级别签名，顾名思义，其签名仅在当前本地库范围内有效；
系统级别签名：系统级别签名在当前操作系统的当前用户范围内均有效，即：该用户创建的仓库都可使用该签名。

它们之间的优先级遵循就近原则： 项目级别签名优于系统级别签名，二者如果都设置了就采用项目级别签名； 如果只设置了某个级别的签名，那就采用该签名； Git规定必须设置一个某级别的签名，不允许两者都不设置。

//项目级
git config user.name 用户名
git config user.email 邮箱
//系统级签名
git config --global user.name 用户名
git config --global user.email 邮箱

设置完后，我们找到.git目录下的config文件，打开该文件， 这就是刚刚我们设置的签名（劝大家不要动.git文件夹下的东西）
系统级别签名保存在用户目录下

查看状态，三大分区，添加，提交操作

查看状态，三大分区

git status

• On branch master：表示我们目前处在master分支上，关于分支的概念后面会详细讲解
• No commits yet：没有任何的提交，表示本地库中没有任何的提交
• nothing to commit：没有什么可提交，表示暂存区没有什么可提交的东西

说到这里，就需要介绍一下Git的三大分区

1. 工作区(workspace)：该区即是工作的区域，直接编辑的文件会放在工作区
2. 暂存区(Repository)：暂存区是数据暂时存放的地方，暂存区提供了开发者一个反悔的机会，倘若添加了错误的内容，就可以通过一些手段还原
3. 版本区(Remote)：隐藏目录.git就是版本区，版本区中存放了很多东西， 其中的index文件即为暂存区
4. 三者之间的关系
   

添加

这里我创建了一个test.txt文件，然后查询状态，注意查看状态时输出的这个文件名称是红色的，代表暂存区无法和工作区相匹配。
因为我只是创建了文件，还没有进行任何操作，所以目前仍然处于master分支；本地库中仍然没有任何的提交。
但要注意下面的内容了：

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        test.txt

nothing added to commit but untracked files present (use "git add" to track)

这里的意思是并没有提交任何东西但是发现了一个未追踪的文件，这个文件就是刚才创建的test.txt。

//向暂存区添加
//添加一个文件
git add test.txt
//添加全部
git add .

这里我先创建了一个文件，然后向暂存区添加这个文件，最后查看状态，注意查看状态时输出的这个文件名称是绿色的，代表暂存区可以和工作区相匹配。

我们通过git add 指令追踪到文件，也就是将文件放入了暂存区，这时候，我要想反悔，我就可以通过该指令将刚才放入暂存区的文件撤回来，执行指令：

git rm --cached test.txt

文件名变红了，证明提交到暂存区的文件撤回了，暂存区文件与工作区无法匹配

下面我们重新将test.txt文件放入到暂存区，执行指令：

git add test.txt

添加到暂存区后，我们就可以提交了，执行如下指令将暂存区的内容提交到本地库：

git commit -m '备注' test.txt

此时表示暂存区是干净的，没有什么可提交的，工作区也没有任何状态的修改。

查看提交历史

该指令能够查看提交历史，执行该指令，结果如下：

git log

首先是commit后面的字符串不一样，这是通过一系列hash算法计算出来的一个值，作为每次提交的索引；其次是在第二次提交中，有这么一个信息：(HEAD -> master)，这里的HEAD其实是一个指针，它指向的是当前版本，所以要想实现版本的切换，我们就需要改变HEAD指针的指向。

查看提交历史的其他指令

使用git log指令虽然可以显示提交历史，但是显示得过于详细有时候也并不方便，当提交次数逐渐增多时，这样显然会加重我们查找某些重要信息的负担，所以我们还需要掌握几个关于查看提交历史的指令。

git log --pretty=oneline

• 意思是以只显示一行的方式来输出提交历史，结果如下：
  

git log --oneline

• 该方式显示的内容将会更加简洁，哈希值只显示部分。
  

git reflog

这种方式显示提交历史的区别在于，它多了一个信息：HEAD@{0}。
比如第二次提交信息中的HEAD@{1}，意思是说，从当前版本切换到第二次提交的版本，需要将HEAD指针移动一次； 同理，HEAD@{2}表示切换到该版本需要将HEAD指针移动两次。
需要注意的是，只有git reflog能够显示所有版本的提交历史，什么意思呢？
假设有一个项目提交了很多次，此时想要回退到之前的版本，当你回退之后，其它查看提交历史的指令是无法看到当前版本之前的历史的，而git reflog可以。

如何进行版本切换

经过前面的铺垫，相信大家已经对版本切换的实现有了一个大体的认识，接下来就是掌握具体的指令了。 对于版本切换，Git提供了三种方式：

1. 基于索引值
2. 使用^符
3. 使用~符

基于索引值

这是比较方便的一种切换版本的方式，既然是基于索引值，我们就得先得到索引值，执行指令：

git reflog

• 此时我若是想切换到第一次提交的版本，执行指令：

git reset --hard 14309ac

HEAD指针目前处于14309ac，版本切换成功。
切换版本时哈希值不必全部写出来，只需要写出部分能够唯一标识当前版本即可。

• 该指令不光能回退，还能前进，比如我想前进到第二次提交时的版本，执行指令：

git reset --hard ff08fe8

基于^符号进行版本切换

该符号也能实现版本切换，但它只能后退版本，无法前进。 我们先用索引值切换到最新的版本，执行指令：

git reset --hard HEAD^
//指令中包含几个^符号则代表回退几个版本。
git reset --hard HEAD^^

基于~符号进行版本切换

使用 ^ 符号虽然也能够实现版本切换，但我若是想回退几十个版本，那指令后面就得跟着几十个 ^ 符号，这显然不是一个好的选择，这时候就可以使用~符号。
假设我需要回2个版本，就可以执行如下指令：

git reset --hard HEAD~2
//~符号后面的数字是多少则表示回退多少版本，所以该方式同样只能回退版本而无法前进。

reset指令的参数介绍

git reset指令中的hard参数是什么意思？它是否有别的参数呢？
这里介绍reset指令的三个参数：

1. soft
2. mixed
3. head

先看soft，这是官方文档对其的解释：

Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files “Changes to be committed”, as git status would put it.

意思是说，仅仅在本地库移动HEAD指针，完全不触及索引文件或工作树。

再看mixed：

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

该方式会在本地库移动HEAD指针，并重置索引，但不重置工作树。

最后是head：

Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

该方式会在本地库移动HEAD指针，并重置索引和工作树。

如何找回被删除的文件

在日常开发中难免会出现一些“手贱”的操作，当你不小心删除了一个文件后，该如何找回它呢？

提交的文件找回

我们在项目中新创建一个文件：delete.txt。

创建好后，我们先提交一次，提交完成后，我们把delete.txt文件删除掉，然后查看一下状态：

rm delete.txt
git status

用什么方式删除都可以，这里我就采用了Linux的一个删除指令：rm

当执行git status指令时，终端提示发现了一个删除了的文件，我们再将这次操作提交一下：

git add delete.txt
git commit -m "删除了delete.txt文件" delete.txt

这样当我们把删除文件的这一操作提交之后，Git便会记录这次提交，所以只要Git记录了，我们怎么删除其实都不要紧，那么如何找回文件相信大家已经懂了吧？只需退回到删除文件之前的一个版本就可以了，执行指令：

git reflog

查看一下版本的索引值：

我们要回退到红色框线标注的版本，执行指令：

git reset --hard bdd097f

回退完成后，我们查看一下工作区，被删除的文件又回来了。

没有提交的文件找回

git checkout -- 文件名

总结

综上所述：要想找回删除文件有一个前提，就是该文件存在时的状态一定是已经保存在了本地库，否则你就找不回来了。 找回删除文件分为两种情况：

1. 删除文件已经提交到了本地库：此时使用git reset --hard [版本索引值]指令回退到删除文件前的版本即可
2. 删除文件添加到了暂存区，但还未进行提交：此时使用git checkout – file刷新一下三大区即可

比较文件之间的差异

Git能够找出一个文件在修改前后的差异，举个例子，我们对GitDemo项目中的test.txt做一个修改：

git status

终端提示有文件被修改了，那么我如何得知该文件到底修改了什么内容呢？
它需要用到这条指令：

git diff

执行指令，结果如下：

当我们将对文件进行修改的操作添加到暂存区后，再去比较：

此时终端没有任何反应，说明没有产生文件差异，这也证明了git diff指令其实比较的是工作区与暂存区的文件差异。
当我们让工作区与本地库进行文件比较时，差异又显现出来了，执行指令：

git diff HEAD test.txt

这是因为暂存区的修改还没有提交到版本库。
它还可以与历史提交版本进行比较，只需要改变指针指向即可：

git diff HEAD^^ test.txt

也可以根据索引值进行比较：

git diff 05f2f17

需要注意的是，git diff指令可以不带文件名，若该指令不带文件名则比较的是项目下的所有文件；若带文件名，则指定文件进行比较。

git分支的概念

这是官网上的一段解释：

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。

既然很耗费时间，那分支的作用岂不是很小？ 在大部分的版本控制系统中，想创建分支，对于一个大项目来说确实是非常困难的，但这些问题在Git中将不复存在，这也是Git为何能够制霸版本控制系统领域的一个重要原因。

Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。

分支操作可谓是Git的灵魂，理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

举个很简单的例子，某开发团队准备开发一个项目，在开发之前，肯定要先对项目进行分析，比如他们要开发的是一款社交软件，那社交软件就涉及到界面、聊天、支付等等功能，这时候首先由团队里技术最好的开发人员搭建出项目结构，并将其作为远程库供其它人员下载。

其它开发人员下载好后，一般不会在原来的程序上进行开发，因为后面的开发是未知的，难免会出现一些问题，我们应该保证让这些问题不要搞到之前写好的代码上去，这样每个开发人员对应着自己的工作内容创建一个分支，如图：

然后每个开发人员都专心做着自己的事情，他们之间互不影响，经过不断的开发测试后，若分支上的功能已经完善并没有问题，我们就可以将其合并到主干上：

通过图解，大家应该也能感受到分支开发的高效性和安全性。

分支操作

理解了分支以后，我们来看看在Git中如何操作分支。

可以通过该指令查看项目中的所有分支：

git branch -v

目前项目中只有一个master分支，master分支称为主干、主分支，是在初始化仓库的时候自动创建的。

我们可以通过该指令创建一条分支：

git branch ui

创建好再查看一下分支情况：

现在项目中就有两条分支了，其中*符表示目前所在的分支。

有了分支，该如何切换到新分支呢？执行指令：

git checkout ui

切换成功后，再看一下分支情况：

此时*符指向了ui分支。
下面就可以在ui分支进行相关的开发了，比如我在项目中创建一个ui.txt文件,然后把该操作提交一下

假设这个时候ui分支的开发已经完成了，现在我想将它合并到主分支上，该如何实现呢？
要想将该分支合并到主分支上，我们首先要回到主分支，执行指令：

git checkout master

回到主分支后，我们查看一下工作区：

刚刚创建的ui.txt文件不见了，当然了，该文件是在ui分支创建的，前面已经说了，分支之间互不影响，但若想合并ui分支的内容，我们只需执行如下指令：

git merge ui

再次查看工作区,合并就成功了。：

解决合并冲突

刚刚学习了如何合并分支，但合并分支并没有想象的那么简单，有时候合并分支会产生一些冲突，为什么会出现冲突，原因很简单。

当两个开发人员在两个不同的分支修改了同一个文件中的同一个地方，此时Git无法选择到底应该用谁的，它就会以冲突的形式将问题抛给我们，让我们自己去解决。

举个例子，我们先把分支切换到ui分支：

git checkout ui

把操作提交一下,再切换到master分支，在同一个文件的同一个地方进行修改：

git checkout master

同样提交一下
下面开始合并，执行指令：

git merge ui

注意几个地方，提示信息是说自动合并失败，需要手动解决冲突然后提交。 然后看红色框线标注的地方，master|MERGING，英语中的ing表示进行时，意思是master分支目前正在合并中。
我们打开工作区的ui.txt文件：

可以看到，文件中显示了两个分支修改的内容，并以一些特殊标记进行分隔，其中的<<<<<<<HEAD表示当前分支修改的内容；而>>>>>>>ui表示ui分支修改的内容，中间用=======分隔。

此时你可以进行取舍，想要哪一段就删除另外一段即可，当然你也可以全留下，这里我就留下当前分支修改的内容
记得把分隔符号也删掉。

查看一下状态：

git status

终端提示你有未合并的路径，可以使用git add将指定文件标记为冲突已解决。

下面我们就尝试一下，执行指令：

git add ui.txt

再次查看状态：

此时终端提示所有的冲突已经被解决了，但你仍然处于合并的状态，你可以使用git commit来完成合并，执行指令：

git commit -m "ui.txt冲突已解决"

这里注意了，git commit指令后面千万不要加文件名，否则就会出错，执行该指令后,合并就完成了。

git 远程库交互

创建GitHub账号

对于远程代码托管中心，我们有两个选择：码云和GitHub，这里我以GitHub为例进行讲解。
官网地址：github.com/

如何创建远程库

注册完成后我们登录自己的账号，进入主页：

这是我的主页，下面介绍如何在GitHub中创建远程库。

你可以点击左边的绿色按钮新建仓库，也可以先点击右上角的加号，然后点击New Repository新建仓库。
然后跳转到该界面：

仓库名必须填写，仓库描述可填可不填，这里勾选公共仓库，因为GitHub中的私有仓库是收费的，然后初始化README文件我们也不选，直接点击绿色按钮完成创建。

这样仓库就建好了，里面没有任何东西。配置SSH Key

1. 设置git的user name和email

如果你是第一次使用，或者还没有配置过的话需要操作一下命令，自行替换相应字段。

git config --global user.name "名称"
git config --global user.email  "邮箱"

说明：git config –list 查看当前Git环境所有配置，还可以配置一些命令别名之类的

2.检查是否存在SSH Key

cd ~/.ssh
ls
或者
ll
//看是否存在 id_rsa 和 id_rsa.pub文件，如果存在，说明已经有SSH Key

如果没有SSH Key，则需要先生成一下

ssh-keygen -t rsa -C "真实注册邮箱"

3.获取SSH Key

cat id_rsa.pub
//拷贝秘钥 ssh-rsa开头

4.GitHub添加SSH Key

取个名字，把之前拷贝的秘钥复制进去，添加就好啦。

5.验证和修改

测试是否成功配置SSH Key

ssh -T git@github.com
Hi GerryGithub1! You've successfully authenticated, but GitHub does not provide shell access

如何将本地库推送到远程库

创建好远程库后，我们重新创建一个本地库来进行测试(仓库名为TestGitHub)：

和远程仓库名一致，但为了区分，通常都设置为同一个名字。
这样本地库和远程库都创建好了，接下来如何将本地库推送到远程库呢？ 我们需要获取远程库的地址，复制如下内容：

这就是远程库的地址，通过该地址我们就能够将本地库推送上去。
在TestGitHub文件夹内启动Git终端，先初始化仓库，然后提交一下内容：

提交完成后，我们就能通过远程库地址将本地库推送上去了，执行指令：

git branch -M main
git remote add origin https://github.com/GerryGithub1/TestGitDemo.git
git push -u origin main

异常

异常1

git push -u origin main
fatal: unable to access 'https://github.com/GerryGithub1/TestGitDemo.git/': Failed to connect to github.com port 443: Timed out

需要使用“科学上网”或代理来解决

异常2

git push -u origin main
remote: Permission to GerryGithub1/TestGitDemo.git denied to ygs12.
fatal: unable to access 'https://github.com/GerryGithub1/TestGitDemo.git/': The requested URL returned error: 403

push表示推送，push后面跟上远程库的地址，地址后面写上需要推送到的分支，因为是新创建的本地库，只有main分支，为了与本地库对应，在远程库也创建main分支。

执行指令后，会弹出该页面让使用Access Personal Token

正确输入点击Sign in with your browser即可。

这样就表示推送成功了，我们回到GitHub页面，刷新一下网址：

当提交操作特别频繁的时候，经常粘贴远程库地址显然又费力又容易出错，为此，Git提供了一个方式，可以给远程库地址起一个别名。

我们可以先使用该指令查看一下目前是否有设置别名：

git remote -v

发现终端是没有任何反应的，下面执行该指令对远程库地址起一个别名：

git remote add origin https://github.com/GerryGithub1/TestGitDemo.git

add后面跟上别名，一般起的别名即为：origin。

别名后面跟上远程库地址，再次查看是否设置了别名：

这次就有了，我们可以通过别名来推送本地库了，指令如下：

git push origin master

这里的origin就代表了一长串的远程库地址。

如何将远程库克隆到本地

学会了如何键本地库推送到远程库，我们还需要掌握如何将远程库克隆下来，重新创建一个文件夹，作为另外一个工作区(名字为TestGitHub_2)：
此时我们在该文件夹下启动Git终端，然后执行指令：

git clone https://github.com/GerryGithub1/TestGitDemo.git

clone后面跟上需要克隆的远程库地址。

如果不知道远程库地址，可以在这里找到：

执行结果：

这样克隆就完成了，我们查看一下TestGitDemo_Clone文件夹：

目还携带了.git目录，就无需我们自己去初始化仓库。

克隆项目到本地有三个效果：

1. 完整地把远程库下载到本地
2. 创建origin远程库地址别名
3. 初始化本地库
   克隆完成后，我在克隆下来的项目中新建一个dev.txt文件模拟开发过程： 接下来我们提交一下该操作：
   提交完成后，我们尝试着将该本地库推送到远程库，执行指令：

git push origin main

此时又会弹出登录界面让我们输入用户名和密码，这里我再输入另外一个账户模拟另外一个开发者的身份：
按照之前的想法，这个开发者还没有加入到项目团队中，是不能直接进行推送的，看执行结果：

git push -u origin main
fatal: unable to access 'https://github.com/GerryGithub1/TestGitDemo.git/': Failed to connect to github.com port 443: Timed out

邀请其它开发者加入项目团队

要想让其它开发者能够将本地库推送到远程库，我们得让该开发者进入项目团队，来到GitHub网页：

点击仓库中的Settings进入设置页面：

先点击左边的Manage access，然后点击下方的绿色按钮，此时弹出一个搜索框： 在搜索框内输入另外一个账户的用户名，下面就显示出了该用户，然后点击该用户接着点击加入项目。

还没完，在底下点击如下按钮：

就复制到了邀请链接，此时把邀请链接发送给你准备邀请的人，让对方访问该链接就可以了，这里我是自己演示，所以我切换成了另一个GitHub账户然后访问该链接：

点击接受即可。 现在我们以另一个开发者的身份重新推送一下本地库：

推送成功，刷新GitHub页面：

新操作也进来了。会发现，第二次推送的时候系统并没有要求我们去输入用户名和密码，其实是系统自动帮你记录了：

原来的凭据删除，下次推送就又会让你输入用户名和密码了。

如何拉去远程库

我们暂且将最开始推送远程库的开发人员称为程序员A，另一位开发人员称为程序员B。

那么现在的情况是，程序员B克隆了程序员A的远程库到本地，并在本地进行了修改，然后推送到了远程库。

此时程序员A若想得到程序员B修改的代码，就需要从远程库进行拉取代码。

首先我们需要回到程序员A的工作区，即：TestGitDemo文件夹。在该文件夹下启动Git终端，执行指令：

git fetch origin main

执行结果：

该指令会将指定地址的远程库下载到本地，但是这个时候工作区的文件内容是没有改变的，可以查看工作区：

它将下载的内容放到了一个名为origin/master的分支上，你可以切换到该分支看看是否和远程库一致，这里我就不演示了。

所以我们还需要一个合并的操作，执行指令：

git merge origin/main

查看工作区：

拉取成功。

Git还为此提供了一个更加方便的拉取方式，指令为：

git pull origin main

执行该条指令相当于先执行了fetch，然后执行merge，两者合并为一次操作。

解决合并操作

在讲解本地库的分支操作时，我们便介绍了该如何去解决合并所产生的冲突，这里的协同开发同样可能会产生一系列的冲突问题，解决方法是类似的。
举个例子，程序A对项目中的test.txt文件进行了修改，修改完成后，我们把本次操作提交一下：

提交完成后，把本地库推送到远程，执行指令：

git push origin main

推送是成功的。
然后程序员B也对test.txt文件进行了修改， 同样将操作提交一下：

我们再让程序员B进行推送：

git push origin main

此时终端就报错了：这是因为你所推送的内容和远程库中的内容起了冲突，因为你准备修改的地方已经有内容了，是程序员A修改的，这时候你需要将远程库先拉取下来，执行指令：

git pull origin main

看到红色框线标注的内容，是不是感觉似曾相识呢？没错，现在我们又处于合并中的状态了，打开程序员B的工作区：

解决冲突也很简单，把不需要的内容都删除就行了，这里我们就把程序员A和程序员B所做的修改都保留下来, 接下来的操作就一样了，将文件添加到暂存区：

git add test1.txt

然后提交：

git commit -m "解决程序员B因推送产生的冲突"

这里还是注意千万别加文件名。

提交完成后，就可以推送到远程库了：

git push origin main

跨团队协作开发

刚才介绍了如何进行团队协作开发，当你将某位开发人员邀请到你的项目团队中，该开发人员就可以对远程库进行拉取和推送的操作了。

但是这仅限于团队内部人员，什么意思呢？你的项目肯定是交由公司内部的人或者你信任的人来一起开发。比如你目前正在开发公司项目中的某个模块，途中遇到了一些技术上的问题，你找人帮忙，可他不是你们公司的，你当然不能把他邀请到你的项目团队里了，这就涉及到一个跨团队协作开发的问题，该如何解决呢？

步骤如下: 团队外部人员可以将项目fork到自己的远程库，然后克隆到本地进行开发，完成后通过pull request发起请求，待项目负责人员审核后就可以进行合并了。

下面具体演示一下： 目前程序员A和程序员B在同时开发一个项目，此时程序员B遇到了一些问题需要程序员C帮忙，程序员C就需要去访问项目地址：

看到项目后，我们点击右上角的Fork，点了之后就会在程序员C的GitHub中复制一份远程库：

这样程序员C就可以开始正常开发了，新建一个文件夹(名为：TestGitHub_3)，然后在该文件夹下启动Git终端，并将远程库克隆下来，执行指令：

git clone https://github.com/YangGerry/TestGitDemo

注意这里的地址是程序员C的远程库地址。

克隆下来以后，我们在程序员C的工作区创建一个pay.txt文件：

提交完成后推送到远程库，执行指令：

git push origin main

此时刷新程序员C的远程库：

推送就完成了。

接下来程序员C就需要发起一个pull request请求，点击下图中红色框线标注部分：

你可以点击上面的Pull Requests，也可以点击下面的New pull requets来直接发起请求：

此时会显示你所做的修改，新添加了一个pay.txt文件，然后点击绿色按钮Create pull request：

输入一下这次请求的标题和内容，完成后点击右下角的绿色按钮：

到这里，程序员C的任务就完成了，接下来就要让程序员A去审核程序员C发起的请求：

可以看到程序员A的远程库中有一个Pull requests，我们点击进入：

changed可以查看程序员C具体改动了哪些文件，都确认无误后，点击下面的绿色按钮开始合并：

然后输入本次合并的注释信息：

点击绿色按钮确认合并，合并就完成了。

此时程序员A的远程库中就有了程序员C的代码，程序员A又可以对远程库进行拉取，本地开发，然后推送等操作。