git教程

1 版本控制

1.1集中化的版本控制系统 svn

集中化的版本控制系统诸如 CVS，svn 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

优点：

• 管理员也可以轻松掌控每个开发者的权限
• 管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易

缺点：

• 中央服务器的单点故障，如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新
• 要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就会有丢失数据的风险。

1.2 分布式的版本控制系统 git

于是分布式版本控制系统面世了。在这类系统中，像 Git，BitKeeper 等。客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。

优点：

• 任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。
• 可以指定和若干不同的远端代码仓库进行交互。
• 分布式的版本控制系统在管理项目时 存放的不是项目版本与版本之间的差异.它存的是索引(所需磁盘空间很少 所以每个客户端都可以放下整个项目的历史记录)
• 断网的情况下也可以进行开发(因为版本控制是在本地进行的)

2 git简史

Git 是目前世界上最先进的分布式版本控制系统。到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结
束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。

• 分支切换速度快
• 容量小(压缩)
• 简单的设计
• 完全分布式
• 对非线性开发模式的强力支持（允许上千个并行开发的分支）
• 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

3 Git 安装

3.1 在 Windows 上安装

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

当你点击 git bash Here 菜单之后，可以看到一个终端窗口，在终端里面输入命令 git --version，如果可以看到 git 的版本信息，则说明安装成功。

git --version

3.2 在 Mac 上安装

git 地址 :https://git-scm.com/download/mac

4 Git 初始化配置

一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。

• 系统中对所有用户都普遍适用的配置。/etc/gitconfig

$ git config --system user.name "damu"
$ git config --system user.email damu@example.com

• 用户目录下的配置文件只适用于该用户。~/.gitconfig

$ git config --global user.name "damu" 
$ git config --global user.email damu@example.com

• 当前项目的 Git 目录中的配置文件。.git/config

$ git config user.name "damu" 
$ git config user.email damu@example.com

每一个级别的配置都会覆盖上层的相同配置

要检查已有的配置信息，可以使用 git config --list 命令
删除配置信息 git config --global --unset user.email

5 Git 底层概念（底层命令）

5.1 基础的 linux 命令

• clear ：清除屏幕
• echo 'test content'：往控制台输出信息
• echo 'test content' > test.txt：创建文件且写入内容
• ll ：将当前目录下的 子文件&子目录平铺在控制台
• find 目录名： 将对应目录下的子孙文件&子孙目录平铺在控制台
• find 目录名 -type f ：将对应目录下的文件平铺在控制台
• rm 文件名 ： 删除文件
• mv 源文件 重命名文件: 重命名，移动文件
• cat 文件的 url : 查看对应文件的内容
• vim 文件的 url(在英文模式下)：进入编辑器模式
  按 i 进插入模式 进行文件的编辑
  按 esc 键 & 按:键 进行命令的执行
  q! 强制退出（不保存）
  wq 保存退出
  set nu 设置行号

5.2 初始化新仓库

命令：git init
解析：要对现有的某个项目开始用 Git 管理，只需到此项目所在的目录，执行：git init
作用：初始化后，在当前目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。不过目前，仅仅是按照既有的结构框架初始化好了里边所有的文件和目录，但我们还没有开始跟踪管理项目中的任何一个文件。

.git 目录

• hooks 目录包含客户端或服务端的钩子脚本；
• info 包含一个全局性排除文件
• logs 保存日志信息
• objects 目录存储所有数据内容；
• refs 目录存储指向数据的提交对象的指针（分支）
• config 文件包含项目特有的配置选项
• description 用来显示对仓库的描述信息
• HEAD 文件指示目前被检出的分支
• index 文件保存暂存区信息

5.3 git 对象

Git 的核心部分是一个简单的键值对数据库。你可以向该数据库插入任意类型的内容，它会返回一个键值，通过该键值可以在任意时刻再次检索该内容。

5.3.1 向数据库写入内容 并返回对应键值

echo 'test content' | git hash-object -w --stdin

• -w 选项指示 hash-object 命令存储数据对象；若不指定此选项，则该命令仅返回对应的键值，加了-w才会真正往数据库存储
• --stdin（standard input）选项则指示该命令从标准输入读取内容；若不指定此选项，则须在命令尾部给出待存储文件的路径

git hash-object -w 文件路径 存文件
git hash-object 文件路径 返回对应文件的键值

5.3.2 查看 Git 是如何存储数据的

命令：find .git/objects -type f
返回：.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

5.3.3 根据键值拉取数据

命令：git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
返回：对应文件的内容

• -p 选项可指示该命令自动判断内容的类型，并为我们显示格式友好的内容

5.3.4 对一个文件进行简单的版本控制

1. 创建一个新文件并将其内容存入数据库
   命令：
   echo 'version 1' > test.txt
git hash-object -w test.txt
   返回：
   83baae61804e65cc73a7201a7252750c76066a30

2. 向文件里写入新内容，并再次将其存入数据库
   命令：
   echo 'version 2' > test.txt
git hash-object -w test.txt
   返回：
   1f7a7a472abf3dd9643fd615f6da379c4acb3e3a

3. 查看数据库内容
   命令：
   find .git/objects -type f
git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30
git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 返回：blob
   利用 cat-file -t 命令，可以让 Git 告诉我们其内部存储的任何对象类型

问题：

1. 记住文件的每一个版本所对应的 SHA-1 值并不现实
2. 在 Git 中，文件名并没有被保存——我们仅保存了文件的内容
   解决方案：树对象

5.4 树对象

树对象（tree object），它能解决文件名保存的问题，也允许我们将多个文件组织到一起。Git 以一种类似于 UNIX 文件系统的方式存储内容。所有内容均以树对象和数据对象(git 对象)的形式存储，其中树对象对应了 UNIX 中的目录项，数据对象(git 对象)则大致上对应文件内容。

一个树对象包含了一条或多条记录（每条记录含有一个指向 git 对象或者子树对象的 SHA-1 指针，以及相应的模式、类
型、文件名信息）。一个树对象也可以包含另一个树对象。

我们可以通过 update-index；write-tree；read-tree 等命令来构建树对像并塞入到暂存区。

查看暂存区当前的样子
git ls-files -s
查看树对象
git cat-file -p master^{tree}（或者是树对象的 hash）

1. 利用 update-index 命令 为 test.txt 文件的首个版本——创建一个暂存区。该操作并不会存储到数据库
   命令：
   git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 test.txt

• 文件模式为 100644，表明这是一个普通文件; 100755，表示一个可执行文件; 120000，表示一个符号链接。
• \ 一行输入不完的时候使用
• --add因为此前该文件并不在暂存区中 首次需要--add
• --cacheinfo因为将要添加的文件位于 Git 数据库中，而不是位于当前目录下 所有需要--cacheinfo

2. 并通过 write-tree 命令生成树对像。改操作会将暂存区写入数据库，但是暂存区不会清空
3. 新增 new.txt 将 new.txt 和 test.txt 文件的第二个个版本塞入暂存区。并通过 write-tree 命令生成树对像。
   命令：
   echo 'new file' > new.txt
echo 'version 2' > test.txt
git update-index --cacheinfo 100644 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt
git update-index --add new.txt
git write-tree
4. 将第一个树对象加入第二个树对象，使其成为新的树对象
   命令：
   git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
git write-tree

• read-tree 命令，可以把树对象读入暂存区

总结：我们可以认为树对象就是我们项目的快照

5.5 提交对象

我们可以通过调用 commit-tree 命令创建一个提交对象，为此需要指定一个树对象的 SHA-1 值，以及该提交的父提交对象（如果有的话 第一次将暂存区做快照就没有父对象）

1. 创建提交对象
   echo 'first commit' | git commit-tree d8329f
   返回：
   fdf4fc3344e67ab068f836878b6c4951e3b15f3d

2. 查看提交对象
   git cat-file -p fdf4fc3
   返回：
   tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243
committer Scott Chacon <schacon@gmail.com> 1243
first commit

3. 接着，我们将创建另两个提交对象，它们分别引用各自的上一个提交（作为其父提交对象）
   echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
   返回：cac0cab538b970a37ea1e769cbbde608743bc96d
echo 'third commit' | git commit-tree 3c4e9c -p cac0cab
   返回：1a410efbd13591db07496601ebc7a059dd55cfe9

注意： git commit-tree 不但生成提交对象 而且会将对应的快照（树对象）提交到本地库中

6 Git 本地操作（高层命令）

• git init 初始化新仓库
• git status 检查当前文件状态，已跟踪（已提交，已修改或者已暂存） 或 未跟踪
• git add 文件名、git add ./ 跟踪新文件（暂存）
• git diff 当前做的哪些更新还没有暂存
• git diff –cached 或者 git diff –staged(1.6.1 以上) 有哪些更新已经暂存起来准备好了下次提交
• git commit 提交更新 这种方式会启动文本编辑器以便输入本次提交的说明；git commit –m “message xxx” 另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新；git commit -a -m “message xxx” 加上 -a 选项跳过使用暂存区域。
• git rm 记录此次移除文件的操作，相当于rm 文件名，然后git add ./
• git mv 文件改名，运行 git mv 就相当于运行了下面三条命令mv README.txt README、git rm README.txt、git add README
• git log 查看历史记录；git log --pretty=oneline或git log --oneline 单行展示版本记录
• git reflog 可查看到所有历史版本信息，具体教程

7 Git 分支操作（杀手功能）

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

而 Git 的分支模型极其的高效轻量的。是 Git 的必杀技特性，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。

• git branch 分支名 创建分支，并不会自动切换到新分支中去
• git branch 到当前所有分支的一个列表
• git checkout testing 切换分支，每次在切换分支前 提交一下当前分支
• git branch -d name 删除分支，当分支未合并不给删除时，可使用-D强制删除分支
• git branch -v 可以查看每一个分支的最后一次提交
• git branch name commitHash 时光机 新建一个分支并且使分支指向对应的提交对象
• git branch –merged 查看哪些分支已经合并到当前分支，在这个列表中分支名字前没有 * 号的分支通常可以使用git branch -d 删除掉
• git branch --no-merged 查看所有包含未合并工作的分支，尝试使用 git branch -d 命令删除在这个列表中的分支时会失败。可以使用 -D 选项强制删除它。
• git log --oneline --decorate --graph --all 查看项目分叉历史
• git merge 分支名 分支合并
• git cherry-pick 1a2b3c4d cherry-pick合并其他分支的commit
• git cherry-pick --abort 撤回上次cherry-pick合并操作

8 配别名

Git 并不会在你输入部分命令时自动推断出你想要的命令。 如果不想每次都输入完整的 Git 命令，可以通过 git config 文件来轻松地为每一个命令设置一个别名。

$ git config --global alias.ci commit
当要输入 git commit 时，只需要输入 git ci

$ git config --global alias.logall "log --oneline --decorate --graph --all"
当要输入 git log --oneline --decorate --graph --all 时，只需要输入 git logall

9 Git 存储 git stash

9.1 应用场景

1. 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
2. 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。

git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。

9.2 命令详解

• git stash：能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录。
• git stash save “msg”：作用等同于git stash，区别是可以加一些注释
• git stash list：查看当前stash中的内容
• git stash pop：将当前stash中的内容弹出，并应用到当前分支对应的工作目录上。注：该命令将堆栈中最近保存的内容删除（栈是先进后出）
• git stash apply：将堆栈中的内容应用到当前目录，不同于git stash pop，该命令不会将内容从堆栈中删除，也就说该命令能够将堆栈的内容多次应用到工作目录中，适应于多个分支的情况。
• git stash apply stash@{1}：指定恢复哪个stash到当前的工作目录
• git stash drop stash@{1}：从堆栈中移除某个指定的stash
• git stash clear：清除堆栈中的所有内容
• git stash show：查看堆栈中最新保存的stash和当前目录的差异。
• git stash show stash@{1}：查看指定的stash和当前目录差异。
• git stash show -p：查看详细的不同
• git stash branch：从最新的stash创建分支。

10 撤销&重置

10.1 撤销工作区文件

撤销工作区文件且该文件在版本库被管理过

• git checkout -- fileName.txt：git checkout -- [file] 是一个危险的命令，这很重要。 你对那个文件做的任何修改都会消失 - 你只是拷贝了另一个文件来覆盖它。
• git restore fileName.txt

10.2 撤销暂存区文件

撤销暂存区文件

• git reset [HEAD] fileName.txt：HEAD可以省略
• git restore --staged fileName.txt

10.3 撤销版本

场景1：假如提交的时候信息写错了
git commit --amend：直接执行该命令，按i重新书写注释，然后ESC，:wq保存
场景2：假如有信息漏提交了
git add ./
git commit --amend
这2种情况的操作，都只会记录一次提交信息。
其实git commit --amend命令相当于git reset --soft HEAD~+git commit的语法糖

10.4 reset 三部曲

git ls-files -s：查看暂存区
git cat-file -p hash：根据键值拉取数据，列如git cat-file -p HEAD查看当前提交对象
git ls-tree -r HEAD：查看当前提交对象对应的树对像的内容

10.4.1 移动 HEAD

git reset –soft HEAD~

• HEAD~（HEAD 的父结点）
• 其实就是把该分支移动回上一次提交的位置，而不会改变暂存区和工作目录。
• 相当于撤销了一次git commit

10.4.2 更新暂存区（索引）

git reset --mixed HEAD~等同于git reset HEAD~

• --mixed 可以省略
• 改变HEAD和暂存区，不改变工作目录
• 相当于撤销了git commit和git add ./

10.4.3 更新工作目录

git reset --hard HEAD~

• 改变HEAD、暂存区和工作目录
• --hard 标记是 reset 命令唯一的危险用法，它也是 Git 会真正地销毁数据的仅有的几个操作之一。

10.5 数据恢复 时光机

在你使用 Git 的时候，你可能会意外丢失一次提交。 通常这是因为你强制删除了正在工作的分支，但是最后却发现你还需要这个分支；亦或者硬重置了一个分支，放弃了你想要的提交。 如果这些事情已经发生，该如何找回你的提交呢？

假设你已经提交了五次
$ git log --pretty=oneline
ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
484a59275031909e19aadb7c92262719cfcdf19a added repo.rb
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit

现在，我们将 master 分支硬重置到第三次提交
$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9
HEAD is now at 1a410ef third commit

$ git log --pretty=oneline
1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit

最方便，也是最常用的方法，是使用一个名叫 git reflog 的工具。当你正在工作时，Git 会默默地记录每一次你改变 HEAD 时它的值。 每一次你提交或改变分支，引用日志都会被更新。
$ git reflog
1a410ef HEAD@{0}: reset: moving to 1a410ef
ab1afef HEAD@{1}: commit: modified repo.rb a bit
484a592 HEAD@{2}: commit: added repo.rb
。。。

git reflog 并不能显示足够多的信息。为了使显示的信息更加有用，我们可以执行 git log -g，这个命令会以标准日志的格式输出引用日志

恢复
看起来下面的那个就是你丢失的提交，你可以通过创建一个新的分支指向这个提交来恢复它。 例如，你可以创建一个名为 recover-branch 的分支指向这个提交（ab1afef）
git branch recover-branch ab1afef

10.6 checkout深入理解

git checkout branchName 和 git reset --hard commithash 特别像
相同点：

• 都重置HEAD、暂存区、工作目录
  区别：
• checkout对工作目录是安全的，而reset --hard 是强制覆盖
• checkout 动HEAD时不会带着分支走而是切换分支，reset --hard 时是带着分支走

checkout + 路径

• git checkout commithash fileName：重置暂存区和工作目录
• git checkout --fileName：重置工作目录

11 打 tag

Git 可以给历史中的某一个提交打上标签，以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点（v1.0 等等）。

11.1 列出标签

git tag
git tag -l 'v1.8.5*'：v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3

11.2 创建标签

Git 使用两种主要类型的标签：轻量标签 与 附注标签

轻量标签很像一个不会改变的分支 - 它只是一个特定提交的引用
git tag v1.4
git tag v1.4 commitHash

附注标签是存储在 Git 数据库中的一个完整对象。 它们是可以被校验的；其中包含打标签者的名字、电子 邮件地址、日期时间；还有一个标签信息；通常建议 创建附注标签，这样你可以拥有以上所有信息；但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的
git tag -a v1.4
git tag -a v1.4 commitHash
git tag -a v1.4 commitHash -m 'my version 1.4'

11.3 查看特定标签

git show 可以显示任意类型的对象（git 对象 树对象 提交对象 tag 对象）
git show tagname

11.4 远程标签

默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到 共享服务器上。你可以运行
git push origin [tagname]

如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。这将会把所有不在远程仓库 服务器上的标签全部传送到那里。
git push origin --tags

11.5 删除标签

删除标签 要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>。例如，可以使用下面的命令删除掉 一个轻量级标签：
git tag -d v1.4

应该注意的是上述命令并不会从任何远程仓库中移除这个标签，你必须使用git push <remote> :refs/tags/<tagname> 来更新你的远程仓库：
git push origin :refs/tags/v1.4

11.6 检出标签

如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令
git checkout tagname

虽然说这会使你的仓库处于“分离 头指针（detacthed HEAD）”状态。在“分离头指针”状态下，如果你做了某些更改然后提交它们，标签不会发生变化，但你的新提交将不属于任何 分支，并且将无法访问，除非访问确切的提交哈希。因此，如果你需要进行更改——比如说你正在修复旧版本的错 误——这通常需要创建一个新分支
git checkout -b version2

12 忽略某些文件 .gitignore

一般我们总会有些文件无需纳入 Git 的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。

.gitignore 的格式规范

• 所有空行或者以注释符号 ＃ 开头的行都会被 Git 忽略。
• 可以使用标准的 glob 模式匹配。* 代表匹配任意个字符；?代表匹配任意一个字符；** 代表匹配多级目录
• 匹配模式前跟反斜杠/ 这个斜杠代表项目根目录
• 匹配模式最后跟反斜杠/说明要忽略的是目录。
• 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号!取反。

示例

# 此为注释 – 将被 Git 忽略
# 忽略所有 .a 结尾的文件
*.a
# 但 lib.a 除外
!lib.a
# 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
/TODO
# 忽略 build/ 目录下的所有文件
build/
# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录下所有扩展名为 txt 的文件
doc/**/*.txt（**通配符从 Git 版本 1.8.2 以上已经可以使用）

GitHub 有一个十分详细的针对数十种项目及语言的 .gitignore 文件列表，你可以在 https://github.com/github/gitignore 找到它!!!

13 远程仓库

13.1 远程协作基本流程

GitHub 上 的 项 目 可 通 过 HTTP 或 SSH 访 问 ， 格 式 是 ：

HTTP ： https://github.com//<project_name> ，
SSH ： git@github.com:/<project_name> 。

Git 可以通过以上两种 URL 进行抓取和推送，但是用户的访问权限又因连接时使用的证书不同而异。

通常对于公开项目可以优先分享基于 HTTP 的 URL，因为用户克隆项目不需要有一个 GitHub 帐号。 如果你分享 SSH URL，用户必须有一个帐号并且上传 SSH 密钥才能访问你的项目。 HTTP URL 与你贴到浏览器里查看项目用的地址是一样的。

创建本地库
git init
远程仓库配置别名&用户信息
git remote add <shortname> <url>：添加一个新的远程 Git 仓库，同时指定一个你可以轻松引用的简写
git remote –v：显示远程仓库使用的 Git 别名与其对应的 URL
git remote show [remote-name]：查看某一个远程仓库的更多信息
git remote rename oldName newName：重命名
git remote rm [remote-name]：移除一个远程仓库

推送本地项目到远程仓库
git push [remote-name] [branch-name]：将本地项目的 master 分支推送到 origin （别名）服务器
克隆远程仓库到本地
git clone url：默认克隆时为远程仓库起的别名为 origin
git clone url -o booyah：那么你默认的远程仓库别名为 booyah

git fetch [remote-name]：这个命令会访问远程仓库，从中拉取所有你还没有的数据。 执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看
git fetch --all：本地同步拉取所有远程分支

13.2 跟踪分支

从一个远程跟踪分支（origin/master）检出一个本地分支会自动创建一个叫做 “跟踪分支（有时候也叫做 ” “上游分支” ：master）。只有主分支 并且 克隆时才会自动建跟踪分支。

如果你愿意的话可以设置其他的跟踪分支，或者不跟踪 master 分 支。
git checkout -b [branch] [remotename]/[branch]：例如git checkout -b serverfix origin/serverfix
git checkout --track origin/serverfix：如果想要将本地分支与远程分支设置为相同的名字

设置已有的本地分支跟踪一个刚刚拉取下来的远程分支，或者想要修改正在跟踪的跟踪分支，你可以在任意时间使用 -u 选项运行 git branch 来显式地设置
git branch -u origin/serverfix （--set-upstream-to）
git branch -vv：查看设置的所有跟踪分支

13.3 删除远程分支

• git push origin --delete branchName：删除远程分支
• git remote prune origin --dry-run：列出仍在本地跟踪但是远程已被删除的无用分支
• git remote prune origin：清除上面命令列出来的远程跟踪

13.4 pull request 流程 Fork

如果你想要参与某个项目，但是并没有推送权限，这时可以对这个项目进行“派生”（Fork）。 派生的意思是指，GitHub 将在你的空间中创
建一个完全属于你的项目副本，且你对其具有推送权限。通过这种方式，项目的管理者不再需要忙着把用户添加到贡献者列表并给予他们推送权限。 人们可以派生这个项目，将修改推送到派生出的项目副本中，并通过创建合并请求（Pull Request）来让他们的改动进入源版本库。

基本流程：

1. 从 master 分支中创建一个新分支 （自己 fork 的项目）
2. 提交一些修改来改进项目 （自己 fork 的项目）
3. 将这个分支推送到 GitHub 上 （自己 fork 的项目）
4. 创建一个合并请求
5. 讨论，根据实际情况继续修改
6. 项目的拥有者合并或关闭你的合并请求

每次在发起新的 Pull Request 时 要去拉取最新的源仓库的代码而不是自己 fork 的那个仓库。

• git remote -v
• git remote add <shortname 源仓库别名> <url 源仓库url>
• git remote -v
  方式一：
• git fetch 远程仓库名字
• git merge 对应的远程跟踪分支
  方式二：当前分支和源分支一样的话
• git pull <shortname 源仓库别名>

13.5 SSH

ls -al ~/.ssh：查看是否存在现有的 SSH 密钥
ssh-keygen -t rsa -C "your email"：生成公私钥
ssh-keygen -t ed25519 -C "your_email@example.com"：生成新 SSH 密钥
.ssh 文件位置：C:\Users\Administrator\.ssh，带.pub后缀的为公匙，需要配置到github网站上去
ssh -T git@github.com ：测试公私钥是否已经配对