Git使用指南

介绍

关于 Git

Git 是一种可以智能追踪文件中的更改的版本控制系统。 在你和一组人员同时对同一文件进行更改时,Git 的价值就体现出来了。

通常,要在基于 Git 的工作流中执行此操作,需要:

关于 GitHub

GitHub 是一种基于云的平台,可在其中存储、共享并与他人一起编写代码。

通过将代码存储在 GitHub 上的“存储库”中,你可以:

协作式工作是 GitHub 最基本的功能之一,该功能由开源软件 Git 实现,而 GitHub 是以该软件为基础进行构建的。

Git 基本工作流

初始化仓库

git init

如果初始化成功,执行了git init命令的目录下就会生成.git目录。这个.git目录里存储着管理当前目录内容所需的仓库数据

查看仓库状态

git status

这个命令非常常用,请务必牢记

向暂存区中添加文件

git add

如果只是用 Git 仓库的工作树创建了文件,那么该文件并不会被记入 Git 仓库的版本管理对象当中。因此我们用 git status 命令查看 README.md 文件时,它会显示在 Untracked files 里。

要想让文件成为 Git 仓库的管理对象,就需要用git add命令将其加入暂存区(Stage或者Index)中。暂存区是提交之前的一个临时区域。

(base) martian148@Mac git_1 % touch README.md
(base) martian148@Mac git_1 % git status
位于分支 master

尚无提交

未跟踪的文件:
  (使用 "git add <文件>..." 以包含要提交的内容)
	README.md

提交为空,但是存在尚未跟踪的文件(使用 "git add" 建立跟踪)
(base) martian148@Mac git_1 % git add README.md 
(base) martian148@Mac git_1 % git status
位于分支 master

尚无提交

要提交的变更:
  (使用 "git rm --cached <文件>..." 以取消暂存)
	新文件:   README.md

README.md 文件加入暂存区后,git status 命令的显示结果发生了变化。可以看到,README.md文件显示在Changes to be committed (提交的变更)中了。

保存仓库的历史记录

git commit

可以将当前暂存区中的文件实际保存到仓库的历史记录中。通过这些记录,我们就可以在工作树中复原文件。

(base) martian148@Mac git_1 % git commit -m "commit 1"
[master(根提交) c917196] commit 1
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

m 参数后的 "commit 1" 称作提交信息,是对这个提交的概述。

刚才我们只简洁地记述了一行提交信息,如果想要记述得更加详细,请不加 -m,直接执行git commit命令。执行后编辑器就会启动,并显示如下结果。

# 请为您的变更输入提交说明。以 '#' 开始的行将被忽略,而一个空的提交
# 说明将会终止提交。
#
# 位于分支 master
# 要提交的变更:
#       删除:     README.md
#

然后你依次输入以下信息:

这里的编辑是需要使用 vim 操作的

执行完 git commit 命令后可以使用 git status 查看当前状态。

查看提交日志

git log

git log 命令可以查看以往仓库中提交的日志。包括可以查看什么人在什么时候进行了提交或合并,以及操作前后有怎样的差别

(base) martian148@Mac git_1 % git log
commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1 (HEAD -> master)
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:08:28 2025 +0800

    commit 2
    
    delete README.md

commit c91719612c44dfe4e3338a3917a546935dd2ee11
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:05:06 2025 +0800

    commit 1

可以看到我们的两次提交

只显示提交信息的第一行

如果只想让程序显示第一行简述信息,可以在 git log 命令后加上 --pretty=short。这样一来开发人员就能够更轻松地把握多个提交。

(base) martian148@Mac git_1 % git log --pretty=short

commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1 (HEAD -> master)
Author: chengyiwei-mac <1485868106@qq.com>

    commit 2

commit c91719612c44dfe4e3338a3917a546935dd2ee11
Author: chengyiwei-mac <1485868106@qq.com>

    commit 1

只显示指定目录、文件的日志

只要在 git log 命令后加上目录名,便会只显示该目录下的日志。如果加的是文件名,就会只显示与该文件相关的日志。

git log [文件名]

如果你需要到历史记录里面去查,就需要加上 --,告诉 Git 我查的是历史里的路径,而不是当前工作区的路径。

(base) martian148@Mac git_1 % git log -- README.md
commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1 (HEAD -> master)
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:08:28 2025 +0800

    commit 2
    
    delete README.md

commit c91719612c44dfe4e3338a3917a546935dd2ee11
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:05:06 2025 +0800

    commit 1

查看更改前后的差别

git diff

git diff 命令可以查看工作树、暂存区、最新提交之间的差别(只显示已追踪文件的变化)。单从字面上可能很难理解,各位不妨跟着笔者的解说亲手试一试。

我们再次创建 README.md,并写下标题

# Git 教程
(base) martian148@Mac git_1 % git add README.md
(base) martian148@Mac git_1 % git diff
(base) martian148@Mac git_1 % git diff HEAD

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..81aaa8d
--- /dev/null
+++ b/README.md
@@ -0,0 +1,2 @@
+# Git 教程
+

第一次使用 git diff 没有返回时因为我们 git add README.md 之后工作树和暂存区之间并没有区别,加上 HEAD 之后就能查看和最新的提交之间的差别

不妨养成这样一个好习惯:在执行git commit命令之前先执行git diff HEAD命令,查看本次提交与上次提交之间有什么差别,等确认完毕后再进行提交。这里的HEAD是指向当前分支中最新一次提交的指针。

确认无误后我们使用 git commit 提交

(base) martian148@Mac git_1 % git commit -m "insert Index"
[master 2c068fa] insert Index
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
(base) martian148@Mac git_1 % git log
commit 2c068faea9ab880034ad5cb3cfd5434e8875c61a (HEAD -> master)
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:32:12 2025 +0800

    insert Index

commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:08:28 2025 +0800

    commit 2
    
    delete README.md

commit c91719612c44dfe4e3338a3917a546935dd2ee11
Author: chengyiwei-mac <1485868106@qq.com>
Date:   Mon Apr 7 00:05:06 2025 +0800

    commit 1

Git 分支

在进行多个并行作业时,我们会用到分支。在这类并行开发的过程中,往往同时存在多个最新代码状态。从master分支创建feature-A分支和fix-B分支后,每个分支中都拥有自己的最新代码。master分支是Git默认创建的分支,因此基本上所有开发都是以这个分支为中心进行的。

不同分支中,可以同时进行完全不同的作业。等该分支的作业完成之后再与master分支合并。比如feature-A分支的作业结束后与master合并。

通过灵活运用分支,可以让多人同时高效地进行并行开发。

显示分支一览表

git branch

可以看到master分支左侧标有“*”(星号),表示这是我们当前所在的分支。也就是说,我们正在master分支下进行开发。结果中没有显示其他分支名,表示本地仓库中只存在master一个分支。

(base) martian148@Mac git_1 % git branch
* master

创建、切换分支

git checkout -b

执行下面的命令,创建名为 feature-A 的分支

(base) martian148@Mac git_1 % git checkout -b feature-A
切换到一个新分支 'feature-A'

这时再来查看分支列表,会显示我们处于feature-A分支下。

(base) martian148@Mac git_1 % git branch
* feature-A
  master

feature-A分支左侧标有 "*",表示当前分支为feature-A。在这个状态下像正常开发那样修改代码、执行git add命令并进行提交的话,代码就会提交至feature-A分支。像这样不断对一个分支(例如feature-A)进行提交的操作,我们称为“培育分支”。

下面来实际操作一下。在README.md文件中添加一行。

# Git教程

 - feature-A

我们在 README.md 中添加了 feature-A 这样一行字母,然后进行提交。

(base) martian148@Mac git_1 % git diff
diff --git a/README.md b/README.md
index 81aaa8d..69d9407 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,3 @@
 # Git 教程
 
+- Feature -A
(base) martian148@Mac git_1 % git add README.md 
(base) martian148@Mac git_1 % git commit -m "add feature-A"
[feature-A 6e91002] add feature-A
 1 file changed, 1 insertion(+)

于是,这一行就添加到feature-A分支中了

切换到 master 分支

(base) martian148@Mac git_1 % git checkout master
切换到分支 'master'

然后查看 README.md 文件,会发现 README.md 文件仍然保持原先的状态,并没有被添加文字。feature-A 分支的更改不会影响到 master 分支,这正是在开发中创建分支的优点。只要创建多个分支,就可以在不互相影响的情况下同时进行多个功能的开发。

切换回上一个分支

现在切换回 feature-A 分支

(base) martian148@Mac git_1 % git checkout -
切换到分支 'feature-A'
(base) martian148@Mac git_1 % git branch
* feature-A
  master

像上面这样用 “-”(连字符)代替分支名,就可以切换至上一个分支。当然,将 “-” 替换成 feature-A 同样可以切换到 feature-A 分支。

合并分支

git merge

接下来,我们假设feature-A已经实现完毕,想要将它合并到主干分支master中。首先切换到master分支。

(base) martian148@Mac git_1 % git checkout master
切换到分支 'master'

然后合并 feature-A 分支。为了在历史记录中明确记录下本次分支合并,我们需要创建合并提交。因此,在合并时加上--no-ff 参数。

(base) martian148@Mac git_1 % git merge --no-ff feature-A
Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)

这样一来,feature-A 分支的内容就合并到 master 分支中了。

以图表形式查看分支

git log --graph

git log --graph命令进行查看的话,能很清楚地看到特性分支(feature-A)提交的内容已被合并。除此以外,特性分支的创建以及合并也都清楚明了。

(base) martian148@Mac git_1 % git log --graph
*   commit 78796c05775d58a610f94eda195e933fccf76484 (HEAD -> master)
|\  Merge: 2c068fa 6e91002
| | Author: chengyiwei-mac <1485868106@qq.com>
| | Date:   Mon Apr 7 13:14:14 2025 +0800
| | 
| |     Merge branch 'feature-A'
| | 
| * commit 6e9100227dc85b1f806633790bb082bc767dc1e4 (feature-A)
|/  Author: chengyiwei-mac <1485868106@qq.com>
|   Date:   Mon Apr 7 13:02:12 2025 +0800
|   
|       add feature-A
| 
* commit 2c068faea9ab880034ad5cb3cfd5434e8875c61a
| Author: chengyiwei-mac <1485868106@qq.com>
| Date:   Mon Apr 7 00:32:12 2025 +0800
| 
|     insert Index
| 
* commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1
| Author: chengyiwei-mac <1485868106@qq.com>
| Date:   Mon Apr 7 00:08:28 2025 +0800
| 

查看之前所有提交

git reflog

git reflog 能查看仓库所有的提交值,包括没有分支指向的提交

回溯历史版本

git reset --hard

Git 的另一特征便是可以灵活操作历史版本。借助分散仓库的优势,可以在不影响其他仓库的前提下对历史版本进行操作。

我们先回溯历史版本,创建一个名为 fix-B 的特性分支

回溯到创建feature-A分支前

让我们先回溯到前面feature-A分支创建之前,创建一个名为fix-B的特性分支。

要让仓库的HEAD、暂存区、当前工作树回溯到指定状态,需要用到 git reset --hard 命令。只要提供目标时间点的哈希值,就可以完全恢复至该时间点的状态。

git reset --hard [哈希值]
(base) martian148@Mac git_1 % git reset 2c068faea9ab880034ad5cb3cfd5434e8875c61a 
重置后取消暂存的变更:
M	README.md
(base) martian148@Mac git_1 % git log --graph
* commit 2c068faea9ab880034ad5cb3cfd5434e8875c61a (HEAD -> master)
| Author: chengyiwei-mac <1485868106@qq.com>
| Date:   Mon Apr 7 00:32:12 2025 +0800
| 
|     insert Index
| 
* commit e85d662b27b86e1d6693a71e9fec7c127d7b67d1
| Author: chengyiwei-mac <1485868106@qq.com>
| Date:   Mon Apr 7 00:08:28 2025 +0800
| 
|     commit 2
|     
|     delete README.md
| 
* commit c91719612c44dfe4e3338a3917a546935dd2ee11
  Author: chengyiwei-mac <1485868106@qq.com>
  Date:   Mon Apr 7 00:05:06 2025 +0800

我们已经成功回溯到特性分支(feature-A)创建之前的状态。由于所有文件都回溯到了指定哈希值对应的时间点上,README.md文件的内容也恢复到了当时的状态。

创建 fix-B 分支

现在我们来创建特性分支(fix-B)

(base) martian148@Mac git_1 % git checkout -b "fix-B"

切换到一个新分支 'fix-B'

我们在README.md文件中添加一行文字 fix-B

# Git教程

  - fix-B

然后直接提交README.md文件。

(base) martian148@Mac git_1 % git add .
(base) martian148@Mac git_1 % git commit -m "fix-B"
[fix-B 825ac42] fix-B
 1 file changed, 1 insertion(+)

接下来我们的目标主干分支合并 feature-A 分支的修改后,又合并了 fix-B 的修改。

推进至 feature-A 分支合并后的状态

首先恢复到feature-A分支合并后的状态。不妨称这一操作为“推进历史”。

git log 命令只能查看以当前状态为终点的历史日志,可以加上参数 --all,也可以加上格式化让提交更树更美观

(base) martian148@Mac git_1 % git log --oneline --graph --all --decorate

* 825ac42 (HEAD -> fix-B) fix-B
| * 6e91002 (feature-A) add feature-A
|/  
* 2c068fa (master) insert Index
* e85d662 commit 2
* c917196 commit 1

我们将HEAD、暂存区、工作树恢复到这个 feature-A 时间点的状态

我要先执行 git checkout 把 HEAD 移动到 master 位置,然后把 master 推动到 featrue-A 的位置

(base) martian148@Mac git_1 % git reset --hard 6e91002
HEAD 现在位于 6e91002 add feature-A

合并冲突

我们现在有两个分支 feature-Afix-B,我们尝试合并这两个分支

(base) martian148@Mac git_1 % git log --graph --oneline --decorate --all
* 825ac42 (fix-B) fix-B
| * 6e91002 (HEAD -> master, feature-A) add feature-A
|/  
* 2c068fa insert Index
* e85d662 commit 2
* c917196 commit 1
(base) martian148@Mac git_1 % git merge --no-ff fix-B 
自动合并 README.md
冲突(内容):合并冲突于 README.md
自动合并失败,修正冲突然后提交修正的结果

这里系统提示我们产生了合并冲突,不解决冲突就无法完成合并,所以我们打开README.md文件,解决这个冲突。

打开编译器,会发现 README.md 文件变成了这个样子:

# Git 教程

<<<<<<< HEAD
- Feature -A
=======
- fix -B
>>>>>>> fix-B

=======以上的部分是当前HEAD的内容,以下的部分是要合并的fix-B分支中的内容。我们在编辑器中将其改成想要的样子。

# Git 教程


- Feature -A

- fix -B

提交解决后的结果

冲突解决后,执行git add命令与git commit命令。

(base) martian148@Mac git_1 % git add README.md
(base) martian148@Mac git_1 % git commit -m "fix conflict"
[master ff533db] fix conflict
(base) martian148@Mac git_1 % git log --graph --oneline --decorate --all
*   ff533db (HEAD -> master) fix conflict
|\  
| * c093351 (fix-B) fix-B
| * 825ac42 fix-B
* | 6e91002 (feature-A) add feature-A
|/  
* 2c068fa insert Index
* e85d662 commit 2
* c917196 commit 1

与 GitHub 交互

添加远程仓库

Git是分散型版本管理系统,但我们前面所学习的,都是针对单一本地仓库的操作。下面,我们将开始接触远在网络另一头的远程仓库。远程仓库顾名思义,是与我们本地仓库相对独立的另一个仓库。让我们先在GitHub上创建一个仓库,并将其设置为本地仓库的远程仓库。

为防止与其他仓库混淆,仓库名请与本地仓库保持一致,即git-tutorial。创建时请不要勾选Initialize this repository with a README选项。因为一旦勾选该选项,GitHub一侧的仓库就会自动生成README文件,从创建之初便与本地仓库失去了整合性。虽然到时也可以强制覆盖,但为防止这一情况发生还是建议不要勾选该选项,直接点击 Create repository 创建仓库。

我的 GitHub 用户名是 chengyiwei,创建了 git_test 仓库

使用 git remote add 命令将它设置为本地仓库的远程仓库

(base) martian148@Mac git_1 % git remote add origin git@github.com:chengyiwei/git_test.git

执行完之后,Git 会自动将 git@github.com:chengyiwei/git_test.git 远程仓库的名称设置为 origin(标识符)

推送至远程仓库

git push

推送至master分支

如果想将当前分支下本地仓库中的内容推送给远程仓库,需要用到 git push 命令。现在假定我们在master分支下进行操作。

(base) martian148@Mac git_1 % git push -u origin master
枚举对象中: 18, 完成.
对象计数中: 100% (18/18), 完成.
使用 8 个线程进行压缩
压缩对象中: 100% (7/7), 完成.
写入对象中: 100% (18/18), 1.37 KiB | 1.37 MiB/s, 完成.
总共 18(差异 1),复用 0(差异 0),包复用 0(来自  0 个包)
remote: Resolving deltas: 100% (1/1), done.
To github.com:chengyiwei/git_test.git
 * [new branch]      master -> master
分支 'master' 设置为跟踪 'origin/master'

像这样执行git push命令,当前分支的内容就会被推送给远程仓库origin的master分支。

-u 参数是告诉本地本地分支和远程分支的追踪关系(upstream),相当于把 origin 和 master 绑定了,下次如果我再执行 git push 操作就不用手动指定远程分支,否则每次都需要输入 git push origin master,后面使用 git pull Git 也知道拉去到哪里

推送至master以外的分支

除了master分支之外,远程仓库也可以创建其他分支。举个例子,我们在本地仓库中创建feature-D分支,并将它以同名形式push至远程仓库。

(base) martian148@Mac git_1 % git checkout -b "feature-D"
切换到一个新分支 'feature-D'
(base) martian148@Mac git_1 % git branch
  feature-A
* feature-D
  fix-B
  master
(base) martian148@Mac git_1 % git push -u origin feature-D
总共 0(差异 0),复用 0(差异 0),包复用 0(来自  0 个包)
remote: 
remote: Create a pull request for 'feature-D' on GitHub by visiting:
remote:      https://github.com/chengyiwei/git_test/pull/new/feature-D
remote: 
To github.com:chengyiwei/git_test.git
 * [new branch]      feature-D -> feature-D
分支 'feature-D' 设置为跟踪 'origin/feature-D'
image-20250407221029833

现在我们可以从 GitHub 页面看到 feature-D 分支了

从远程仓库获取

git clone

现在我们切换一个目录,从 GitHub 上 clone 这个仓库到本地

(base) martian148@Mac git_2 %  git clone git@github.com:chengyiwei/git_test.git
正克隆到 'git_test'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 18 (delta 1), reused 18 (delta 1), pack-reused 0 (from 0)
接收对象中: 100% (18/18), 完成.
处理 delta 中: 100% (1/1), 完成.
(base) martian148@Mac git_2 % cd git_test 
(base) martian148@Mac git_test %   

执行git clone命令后我们会默认处于master分支下,同时系统会自动将origin设置成该远程仓库的标识符。也就是说,当前本地仓库的master分支与GitHub端远程仓库(origin)的master分支在内容上是完全相同的。

(base) martian148@Mac git_test % git branch -a 
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature-D
  remotes/origin/master

通过 git branch -a 指令可以显示本地仓库和远程仓库的分支信息

获取远程的feature-D分支

我们试着将feature-D分支获取至本地仓库。

(base) martian148@Mac git_test % git branch -a
* feature-D
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature-D
  remotes/origin/master

-b 参数的后面是本地仓库中新建分支的名称。为了便于理解,我们仍将其命名为 feature-D,让它与远程仓库的对应分支保持同名。新建分支名称后面是获取来源的分支名称。例子中指定了origin/feature-D,就是说以名为origin的仓库(这里指GitHub端的仓库)的feature-D分支为来源,在本地仓库中创建feature-D分支。

向本地的feature-D分支提交更改

现在假定我们是另一名开发者,要做一个新的提交。在README. md文件中添加一行文字

# Git 教程


- Feature -A

- fix -B

- feature - D

(base) martian148@Mac git_test % git diff
diff --git a/README.md b/README.md
index d1e0242..2a97f63 100644
--- a/README.md
+++ b/README.md
@@ -4,3 +4,5 @@
 - Feature -A
 
 - fix -B
+
+- feature - D

提交 feature-D 分支

(base) martian148@Mac git_test % git add .
(base) martian148@Mac git_test % git commit -m "add feature-D"
[feature-D c0373a7] add feature-D
 1 file changed, 2 insertions(+)

推送feature-D分支

(base) martian148@Mac git_test % git add .
(base) martian148@Mac git_test % git commit -m "add feature-D"
[feature-D c0373a7] add feature-D
 1 file changed, 2 insertions(+)
(base) martian148@Mac git_test % git push
枚举对象中: 5, 完成.
对象计数中: 100% (5/5), 完成.
使用 8 个线程进行压缩
压缩对象中: 100% (2/2), 完成.
写入对象中: 100% (3/3), 287 字节 | 287.00 KiB/s, 完成.
总共 3(差异 0),复用 0(差异 0),包复用 0(来自  0 个包)
To github.com:chengyiwei/git_test.git
   ff533db..c0373a7  feature-D -> feature-D

从远程仓库获取feature-D分支 在本地仓库中提交更改 再将feature-D分支推送回远程仓库

通过这一系列操作,就可以与其他开发者相互合作,共同培育feature-D分支,实现某些功能。

获取最新的远程仓库分支

git pull

我们回到最早的那个目录,可以从远端拉取 feature-D

$ git pull origin feature-D
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0 (from 0)
展开对象中: 100% (3/3), 267 字节 | 89.00 KiB/s, 完成.
来自 github.com:chengyiwei/git_test
 * branch            feature-D  -> FETCH_HEAD
   ff533db..c0373a7  feature-D  -> origin/feature-D
更新 ff533db..c0373a7
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)

GitHub端远程仓库中的feature-D分支是最新状态,所以本地仓库中的feature-D分支就得到了更新。今后只需要像平常一样在本地进行提交再push给远程仓库,就可以与其他开发者同时在同一个分支中进行作业,不断给feature-D增加新功能。

git fetch

::: warning 提问?

git fetchgit pull 的区别 ?

:::

::: details

命令 含义
git fetch 拉取远程仓库的最新变更,但不做合并。 只是更新你本地的远程分支引用,不会影响你当前的工作区。
git pull 等于 git fetch + git merge 先拉取远程最新变更,再尝试和你当前的分支合并。

假设远程 origin/master 有新的提交。

你现在在本地的 master 分支。

如果你执行:

git fetch origin master

如果你执行:

git pull origin master

:::

配置 SSH

  1. 配置SSH Key
git config --global user.name "这里输入你在GitHub的账户名"
git config --global user.email "这里输入你在GitHub的注册邮箱名" (没有引号)
  1. 生成ssh key,如果已经生成就不用了
ssh-keygen -t rsa -C "这里输入你在 GitHub 的注册邮箱"
  1. 查看是否有sshkey

先后输入

cd ~/.ssh
ls

如果出现

id_rsa  id_rsa.pub

就说明成功了

  1. 复制公钥
cat id_rsa.pub

把显示的密匙复制

  1. 把密匙添加到github账户

Settings > SSH and GPG Keys

New SSH Key

  1. 检查一下 SSH Key 是否安装成功
$ ssh -T git@github.com

如果出现

Hi Juliecodestack! You've successfully authenticated, but GitHub does not provide shell access.

就说明成功了

Fork别人的仓库

如果需要加入别人的项目

Fork别人的项目

然后会发现自己的仓库里面也会多出来这样一个项目

修改好之后Pull request

点击提交,那么就可以发送请求给原作者

参考资料

git官网

廖雪峰老师的Git教程