git操作流程及命令详解笔记

（注，本人先在本地写的笔记，图片过多上传到 CSDN 有些复杂，所以如果有乱码或者图片不全，可以看我上传的 git 仓库 git操作流程及命令详解笔记）

git是基于本地的，官方有一条宣传标语“–everything-is-local”，不提交到GitHub, Gitee, GitLab等网站上也是可以在本地进行版本管理的。

​git更关注内容，识别内容修改，而不是关注文件的时间新旧。

1. Git操作流程

1.1 向Git输入“用户名”和“公开的邮箱地址”

$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email "you@yourdomain.example.com"

--global 表示全局设定。或者使用 git config --local 来进行单独仓库的设置，而非设置全局，如果使用 --local 的话，则需先新建或克隆git仓库。

1.2 新建或克隆git仓库

进入存放代码的目录下，建立git仓库并初始化

$ git init

此时会生成一个 .git 文件夹（里面有很多内容），显示隐藏的项目才可以看到，win10下的操作如下

如果想克隆一个git仓库

    # Git itself (approx. 40MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
    # the Linux kernel (approx. 640MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

获取所有分支

git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote";
done

1.3 向本地仓库中添加所存文件

进行 add/commit 操作之前，如果有不想被git管理的文件，则需要在工作区文件夹的顶层目录中(和 .git 文件夹在同一文件夹下)新建 .gitignore 文件，并在该文件指定git应该忽略的有意未跟踪的文件。需要注意的是，git已跟踪的文件不受 .gitignore 影响，如果想把已追踪的文件变成不再追踪，可以看看 1.4 小节。

.gitignore 文件书写规则

# 以 "#" 开头的一行内容是注释
# 忽略名称为 foo.txt 的文件
foo.txt
# 忽略拓展名为 html 的文件
*.html
# 在“忽略拓展名为 html 的文件”的条件下，特定保留 foo.html 文件
!foo.html

添加文件或文件夹进入缓存区(index)

$ git add . # 符号 . 代表所有文件及文件夹
or
$ git add file1 file2 file3

提交(commit) 已添加的文件进入git仓库进行管理（区分上传到网站的操作）

$ git commit
or
$ git commit -m "first commit" # 通过 -m 和引号，方便直接输入 commit message

当修改文件内容或增加其它文件后，需再次使用 git add 命令添加指定文件及文件夹

查看修改

$ git diff # 查看所有修改的地方，无论是否使用add命令添加如仓库
or
$ git diff --cached # 仅查看被add的文件及文件夹的内容与之前的差异
or
$ git status # 仅查看哪些文件被修改，不查看具体内容

修改完毕后记得再次使用commit，之后commit后的内容才会被存为一个节点

$ git commit -a #会一站式自动选取任何修改过的文件（与文件的时间新旧无关），将它们添加到索引中，然后提交

1.4 查看已/未追踪文件

git ls-files -c # 查看添加入暂存库的文件

git ls-files -o # 未被追踪的文件，无论有没有添加到 .gitignore中

1.5 从缓存区以及本地仓库中删除之前已添加(add commit)的文件

如果经过add、commit 操作后，发现有不想被 git 追踪的文件忘记写入 .gitignore 指定，以导致已经添加进入本地仓库了，可使用

$ git ls-files # 查看已经添加入本地仓库的文件
$ git rm --cached <path>\<filename> # 从本地仓库中删除文件

1.6 查看项目历史

$ git log
or
$ git log -p # 查看每一步的完整差异
or
$ git log --stat --summary # 通常，更改的概述对于了解每一步都很有用

1.7 管理分支(branch)

$ git branch experimental # 创建一个名为 experimental 的分支
$ git branch # 查看项目已有分支

执行第2条命令后，星号标记当前所在的分支

$ git switch experimental # 切换分支 最好不要使用该命令，因为会丢失其它分支的内容
                          # 最好使用 git checkout <commit>，详见 git checkout 命令

切换后并提交的内容，都会在新分支下保存

在master分支下，输入如下命令，可以将 experimental 分支下的修改 合并到 master 分支

$ git merge experimental

以图的方式展示分支结果

$ gitk

删除分支

$ git branch -d experimental # 当master分支与experimental融合后，删除experimental分支
$ git branch -D crazy-idea # 新建一个crazy-idea但是又不想要了，该分支与master有冲突时

1.8 如何恢复之前版本

假设git仓库中使用了tag，并且

$ git tag -l # 展示tag的list
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13
...

方式一：保留 v2.6.13之后提交的所有节点，回到v2.6.13，并在该点创建一个新的分支进行不同任务的开发，则 使用 git switch -c <new_branch_name> <tag or commitId>

$ git switch -c new v2.6.13 # 相当于使用了checkout，详情见下面的啰啰嗦嗦

此命令会创建并切换到一个名为 new 的新分支，并且工作目录中的内容为 项目被标记为v2.6.13时的内容

方式二：不保留 v2.6.17之后提交的所有节点，只想让项目回到 v2.6.17时，则

$ git reset --hard v2.6.17 # 不保留v2.6.17之后的改动，新增的文件也不会被删除
or
$ git reset --soft v.2.6.17 # 保留v2.6.17之后的改动`

v2.6.17之后的节点的所有内容都会在log中、working tree中消失，但是还可以在reflog中找回

方式三：checkout会涉及到改变commit节点或分支，如果不想如此的话，可以使用 git restore

$ git restore -s <tree> <pathspec> # <tree> 可以是commit, branch, tag

1.9 在不创建新分支的情况下检查旧版本

git switch命令通常需要一个分支头，但在用 – detach调用时也会接受任意提交。

$ git switch --detach v2.6.17
Note: checking out 'v2.6.17'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another switch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:

  git switch -c new_branch_name

HEAD is now at 427abfa Linux v2.6.17

总是可以通过先检查正确的修订版来查看文件的旧版本。但是有时能够查看单个文件的旧版本而无需检出任何内容就更方便了。此命令可以这样做:

$ git show v2.5:fs/locks.c

1.10 保存当前内容，但又不想commit

想保留已经进行了一部分的工作，但又不想将其提交，解决这个问题的办法就是 git stash 命令，具体使用方法见下面的 3.17 stash 小节

1.11 利用Git进行协同工作

这里大致翻译一下Git官方的教程：

在同一台服务器上，假设Alice已经在/home/Alice/project中启动了一个带有Git存储库的新项目，而Bob在同一台机器上有一个主目录，他想参与其中，那么Bob可以克隆Alice的项目到自己的地址

bob$ git clone /home/alice/project myrepo # 克隆项目所在地址到当前路径的myrepo(如果没有则创建)文件夹下

之后，在Bob进行commit操作后，Alice可以

alice$ cd /home/alice/project alice$ git pull /home/bob/myrepo master # 拉取（pull）操作 alice$ git fetch /home/bob/myrepo master #获取（fetch）操作
alice$ git log -p HEAD..FETCH_HEAD # fetch来的master分支成为了 FETCH_HEAD
$ gitk HEAD..FETCH_HEAD # 可视化Bob在他们的历史分叉后所做的事情，中间两个小数点
$ gitk HEAD...FETCH_HEAD # 可视化Alice 和 Bob 两个人在分支后做了什么，中间用三个小数点，也意味着“显示从其中一个可以访问的所有内容，但排除从两者都可以访问的任何内容”

获取（fetch）操作会获取更新，但不更改本地现有文件；拉取（pull）操作则做出两个操作：1、获取（fetch）更新，2、并且融合更新到现有的文件中。

如果本地文件和获取的更新有冲突，则需要解决（放弃本地文件或者放弃更新的文件）

通过定义远程存储库的简写，可以方便与同一个存储库反复交互，之后每次fetch或者pull的时候，就不用每次都输入Bob的仓库的路径了

# 以下操作在与gitee github等网站交互时也经常用到
alice$ git remote add bob /home/bob/myrepo # 将路径简化为名称 bob
alice$ git fetch bob # 取代了 git fetch /home/bob/myrepo master 这种使用路径的操作
alice$ git log -p master..bob/master # 此时获取来的分支存储在 bob/master里，而不是FETCH_HEAD了
alice$ git merge bob/master # 融合
or
alice$ git pull . remotes/bob/master # pull操作总是融合到当前分支（branch），不管命令行中给出什么命令

之后Bob再进行操作时，不用再次指定Alice仓库的地址了（之前clone操作已经指定了）

bob$ git pull
bob$ git config --get remote.origin.url # 通过这行命令可以查看被克隆仓库的地址
bob$ git config -l # 通过clone操作进行的完整配置可以通过这行命令查看，查看后按q退出。我反正看不懂
bob$ git branch -r # Git还以origin/master的名称保存了Alice master分支的原始副本

1.12 推送到网站，以Gtiee为例

$ git remote add origin https://... # 在网站上建立仓库后，会给一个网络地址
$ git push -u origin "master" # 选择要推送到的分支

1.13 删除错误的commit

1.13.1 尚未推送，删除本地仓库中的commit

假设程序员因为强迫症，每次只改了一小点代码， 而且每改一次就提交了一次。（下图仅做示意图，用的软件是 fork ）

一直到最后都改完了，发现其实中间的好多次commit都没有保留的必要，那么想把 version0.3、version0.4、version0.5的commit记录都删掉，但是保留version0.5时的文件及文件内容

$ git reset --soft <commitID>

这里把 version0.2 时的 SHA-1值填入 commitID 就可以了，例如我的是 d9e4354(一共很多位，但不如填那么多)。输入该指令后会发现 git 本地仓库中以及回退到了 version0.2，但工作区的文件却保留了 version0.5 时的样子，如下图所示

之后只要再进行 add 操作和 commit 操作就可以了。

1.13.2 删除中间某个/某些commit

背景：在想删除的commit节点后，有很多其余且想保留的节点

目标：想删除 “AD-AD-Processor V0.0.3” 这节点

使用命令：git rebase -i <commit> （这里多说一点，-i 在这里是 --interactive，笔者认为该命令的本意并不是用于删除 commit 节点而制订的，只不过是利用了 交互式rebase 所达到的效果，实现了删除节点的效果）

step 1: git rebase -i <commit>，在<commit>项中输入 “AD-AD-Processor V0.0.3” 节点前一个节点的 commitID

执行后会弹出如下的框（我使用的VScode进行文本编辑，默认有可能是vim进行文本编辑，所以会有差异）：

在该文本编辑器中，删除 “pick 25d26d9 AD-Processor V0.0.3” 这一行，然后保存并关闭（因为上面黑色的界面里提示了 “Waiting for your editor to close the file…” ）

仓库中不同commit中的内容出现冲突，那么就需要手动解决冲突，像下面这张图第一行黄字提示的 hint: Resolve all conflicts manually, mark them as resolved with

此时 working tree 是这样子

step 2: 手动解决冲突：

首先理解一下现在文件的状态是怎样的，如下图。图中“工作副本的变化”中有两个文件，main.c 和 fir_ftt.m，也就是需手动修改并 git add 的文件。

而文件内容中的 <<<<<<< HEAD 到 ======= 之间的内容，是 “AD-Processor V0.0.2” commit中的内容，且该内容在"AD-Processor V0.0.4"中不存在了；

======= 到 >>>>>>> f5c756d (AD-Processor V0.0.4) 是 “AD-Processor V0.0.4” commit中新增的内容

一般来说，我们在 working tree 中已经有 “AD-Processor V0.0.2” 这个节点了（因为 git rebase -i <commit> 时填的就是此节点的 commitID，所以 “AD-Processor V0.0.2” 现在是基），所以我们应该保留 “AD-Processor V0.0.4” 中新增的内容，删除已删除的内容。即从下一图变到下二图。

其余所有有冲突的地方也都这样做，然后保存并关闭文件。

step 3：git add & git rebase --continue

记得上面黑图第二行黄字提醒的 hint: "git add/rm <conflicted_files>", then run "git rebase --continue"

执行 git rebase --continue 后又会弹出一个编辑器，这是让填写 commit message 的。

如需修改，修改完后关闭就行了；不修改就直接关闭。

然后我的 working tree 变成了这样（这里出现了 AD-Processor V0.0.5 是因为从 V0.0.2到V0.0.4的冲突被我手动修改了，V0.0.4到V0.0.5的冲突系统可以自动解决）而仍有一个未提交的更改，是因为 V0.0.5 到 V0.0.6的冲突需要手动更改（如第一行黄字提示的那样）

那么重复 step2 & step3 就行了，一直到最后提示成功

结果：

下图是修改后的 working tree，紫线（有origin）的是远程仓库上的，蓝线是本地修改后的，可以看到本地仓库中的 “AD-Processor V0.0.3” 已经被删除了

1.13.3 已推送，删除远程仓库中的commit

假如说这个程序员，他不仅每次改一点点且每次改都提交，而且他还往远程仓库push。到最后，想要回到version 0.2，删除远程仓库中多余的commit记录

那么除了如 1.12.1 或 1.12.3 之中 使用 git reset --soft 或 git rebase -i <commit> 以外，进行：

$ git push -f

即使用本地仓库强制覆盖远程仓库就可以了

这里push时不指定远程仓库是因为之前push过了，git会记得。

如下图所示的log，进行 git reset --soft 后，远程仓库中还是5个version(由 origin/master 展示)；本地已经回退到version0.2了。

在 git push -f 后，远程仓库也回到了 version0.2

后续再 add commit push 就可以了。

2 Git 中的一些术语

2.1 Working Tree

实际签出(check out)的文件的树。working tree 通常包含 HEAD commit’s tree的内容，以及已经进行但尚未提交的任何本地更改。（working tree）

另外一个理解：仓库内的项目文件是working tree，而.git 文件夹及其下的内容则不属于。

2.2 a commit

在git历史中的一个单独的点（或者理解成版本version）

2.3 ref

以refs/（例如 refs/heads/master）开头的名称，这种ref也称作是 named reference，它指向一个对象名称（object name）或另一个ref（后者称为symbolic ref）

符号引用(symbolic ref)，则不包含SHA-1 id 本身，虽然形式是 refs/some/thing，但在引用时它会递归地取消引用此引用。常见的 symref 则是 HEAD 。

2.4 refspec

fetch和push操作使用 "refspec"来描述 remote ref 和 local ref 之间的映射。

2.5 head

对位于分支顶端的提交的 named reference。

2.6 HEAD

特殊符号 HEAD 总是可以用来指代当前分支。事实上，Git在 .git 目录中使用一个名为HEAD的文件来记住哪个分支是当前的。

更详细地说：working tree 是从HEAD所指的树的状态派生的。HEAD是对存储库中某个head的引用，然而需要注意的是，当使用detached HEAD时，HEAD直接引用任意提交。

当 HEAD 指向（refs to）然后commit 的SHA-1、而不一定是任何特定分支的顶端时，git分支显示您不再在分支上：

$ git switch --detach v2.6.17
Note: checking out 'v2.6.17'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another switch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:

  git switch -c new_branch_name

HEAD is now at 427abfa Linux v2.6.17

在这种情况下，我们称 HEAD 是“分离的(detached)”。

upstream branch

被合并到(merge into)相关分支中的默认分支（或被变基到(be rebased onto)的相关分支）。它通过 branch.<name>.remote 和 branch.<name>.merge 进行配置。如果 A 的上游分支是 origin/B，有时我们会说“A正在跟踪origin/B”。

.. 与 ... 操作符

$ git log test..master

表示在 master分支，不在test分支

$ git log master..test

表示在 test分支，不在master分支

$ git log test...master

表示在test 或 master分支上的节点，但不能同时两个
如果是 <commit> 则..从一个引用或另一个引用可访问的所有提交，但不能同时选择两个

3 Git命令

3.1 config

git-config：获得和设置存储库或全局选项

3.1.1 语法

 1 git config [<file-option>] [--type=<type>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <name> [<value> [<value-pattern>]]
 2 git config [<file-option>] [--type=<type>] --add <name> <value>
 3 git config [<file-option>] [--type=<type>] [--fixed-value] --replace-all <name> <value> [<value-pattern>]
 4 git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <name> [<value-pattern>]
 5 git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <name> [<value-pattern>]
 6 git config [<file-option>] [--type=<type>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <name-regex> [<value-pattern>]
 7 git config [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch <name> <URL>
 8 git config [<file-option>] [--fixed-value] --unset <name> [<value-pattern>]
 9 git config [<file-option>] [--fixed-value] --unset-all <name> [<value-pattern>]
10 git config [<file-option>] --rename-section <old-name> <new-name>
11 git config [<file-option>] --remove-section <name>
12 git config [<file-option>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
13 git config [<file-option>] --get-color <name> [<default>]
14 git config [<file-option>] --get-colorbool <name> [<stdout-is-tty>]
15 git config [<file-option>] -e | --edit

3.1.2 简介

可以使用此命令查询(query)/设置(set)/替换(replace)/取消设置(unset)选项。name实际上是用点分隔的节(section)和键(key)，值(value)将被转义。

可以使用 --add 将多行(multiple lines)添加到选项中。如果要更新或取消设置可能发生在多行上的选项，则需要给出一个 value-pattern (这是一个扩展的正则表达式，除非给出了 --fixed-value)。仅更新或取消设置与 value-pattern 匹配的现有值。如果要处理与 value-pattern 不匹配的行，只需在前面添加一个感叹号，但请注意，这仅在不使用 --fixed-value 时才起作用。

-- type =<type> 选项指示git config确保传入和传出值(value)在给定的 <type> 下是可规范化的。如果没有给出 -- type =<type>，则不会执行规范化。调用者可能会用 -- no-type 取消设置现有的 -- type 说明符。

读取时，默认情况下，将从系统(system)、全局(global)和存储库本地(repository local)配置文件(configuration files)中读取值(value)，选项 -- system、 -- global、 -- local、 -- worktree和 -- file <filename> 可用于告诉命令仅从该位置读取 (详细可参阅 FILES )。

写入时，默认情况下，新值(value)将写入存储库本地配置文件，选项 -- system，-- global，-- worktree，-- file <filename> 可用于告诉命令写入该位置 (也可以使用 – local，但这是默认的)。

git config 命令执行成功后会返回 0. 返回1~6时可以对比查看是何种错误：

• section或key无效（ret=1），
• 没有提供section或name（ret＝2），
• 配置文件无效（ret＝3），
• 配置文件不可写（ret＝4），
• 您尝试取消设置不存在的选项（ret＝5），
• 您试图取消设置/设置多行匹配的选项（ret=5），或者
• 您尝试使用无效的regexp（ret=6）。

3.1.3 Files

$(prefix)/etc/gitconfig

系统(system)范围的配置文件。

$XDG_CONFIG_HOME/git/config

~/.gitconfig

用户特定的配置文件。当 XDG_CONFIG_HOME 环境变量未设置或为空时，_$HOME/.CONFIG/_ 将用作 _$XDG_CONFIG _HOME_。

这些文件也称为“全局(global)”配置文件。如果两个文件都存在，则按上面给出的顺序读取两个文件。

$GIT_DIR/config

特定于存储库的配置文件(特定于local)。($GIT_DIR 可以理解为存储库当前路径下的 .git/ )

$GIT_DIR/config.worktree

（特定于worktree）这是可选的，只有在 $GIT_DIR/config 中存在 extensions.worktreeConfig 时才会搜索。

3.1.4 CONFIGURATION FILE

Git配置文件包含许多影响Git命令行为的变量。每个存储库中的文件.git/config 和 config.worktree（可选）用于存储该存储库的配置，$HOME/.gitconfig用于存储每个用户的配置作为.git/conconfig文件的回退值。文件/etc/gitconfig可用于存储系统范围内的默认配置。

variables被划分为sections，section name是最后一个小数点之前的全部内容，variable 本身则是被最后一个小数点分割的段（这半句是直译，但是从理解上来说，variable应该是 很多个小数点里，包含最后一个小数点的那一大串东西，比如 user.name 这是一个段）。变量名称不区分大小写，仅允许字母数字字符和 -，并且必须以字母字符开头。有些变量可能会出现多次; 然后我们说变量是多值的。

一个 .git/config 的例子如下

#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#

; core variables
[core]
    ; Don't trust file modes
    filemode = false

; Our diff algorithm
[diff]
    external = /usr/local/bin/diff-wrapper
    renames = true

; Proxy settings
[core]
    gitproxy=proxy-command for kernel.org
    gitproxy=default-proxy ; for all the rest

; HTTP
[http]
    sslVerify
[http "https://weak.example.com"]
    sslVerify = false
    cookieFile = /tmp/cookie.txt

Syntax

语法相当灵活和宽松。空白通常被忽略。第一个注释字符 # 或 ; 会注释该行之后的其余部分。空白行被忽略。

该文件由节(sections)和变量(variables)组成。一个节(section)以方括号中的节的名称开始，一直持续到下一节开始。节名称(section name)不区分大小写。节名称中只允许存在 字母数字字符、符号- 和符号. 。每个变量必须属于某个节，这意味着在变量的第一个设置之前必须有一个节头(section header)。

节可以进一步分为小节(subsection)。要开始一个小节，应将小节名称放在双引号之中，并以空格符与节名称分隔，如下面的示例所示:

[section "subsection"]

子节名称区分大小写，可以包含除换行符和空字节以外的任何字符。如果要在小节名称中输入双引号或反斜杠，则应转义，分别输入 " 和 \，然而其他字符之前的反斜杠在读取时会被丢弃，例如，将 \ t读为t，将 \ 0读为0。节标题不能跨越多行。变量可以直接属于一个部分或给定的小节。当存在 [section “subsection”]时，就不需要 [section]了。

所有其他行 (以及节标题之后的行的其余部分) 都被识别为设置变量，形式为name = value (或者只是name，这是一个简短的说法，即变量是布尔值 “true”)。变量名称不区分大小写，仅允许字母数字字符和-，并且必须以字母字符开头。

定义值(value)的行可以通过以 \ 结尾继续到下一行; 反斜杠和行尾被剥离。name = 后的空格、第一个注释字符 # 或 ; 之后的该行的其余部分、以及该行的尾随空格将被丢弃，除非它们用双引号括起来。值内的内部空白逐字保留。

在双引号(" ")内，双引号 " 和反斜杠 \ 字符必须转义。

识别以下转义序列 (包括 "\ 和 \ ): \n 用于换行字符 (NL)，\t 用于水平制表 (HT，TAB) 和 \b 用于backspace (BS)。其他char转义序列 (包括八进制转义序列) 无效。

Variables

内容很多，可以使用 git help --config 命令获得所有可用配置变量的列表。

例如 user.name、user.email 、pull.rebase等都属于Variables

Values

许多变量(variable)的值(value)被视为一个简单的字符串，但也有一些变量采用特定类型的值，有关于如何拼写它们的规则参见 Values 。

• boolean 型
• integer 型
• color 型
• pathname 型

3.1.5 OPTIONS

• –replace-all
  默认行为是最多替换一行。而使用 --replace all 将替换所有与键(key)（以及可选的value-pattern）匹配的行。
• –add
  在不更改任何现有值(value)的情况下，将新行添加到选项中。这与在 --replace all命令中，将"^$"填入<value-pattern>时相同。
• –get
  常用于查看某项设置。
  获取给定键(key)的值(value)（可以选择通过匹配该值的正则表达式进行筛选）。如果未找到键，则返回错误代码1；如果找到多个键值，则返回最后一个值。
• –get-all
  类似于–get，但返回多值键(multi-valued key)的所有值(value)。
• –get-regexp
  类似于–get-all，但将名称(name)解释为正则表达式并写出键(key)。正则表达式匹配目前是区分大小写的，并且是针对密钥的规范化版本进行的，在该版本中，节(section)和变量(variable)是小写的，但子节名称(subsection names)不是。
• –get-urlmatch <name> <URL>
  当给定一个由两部分组成的名称 section.key 时，将返回 section.<URL>.key 的值，其 <URL> 部分与给定的URL最匹配 (如果不存在这样的键，section.key的值用作回退)。当仅将部分指定为名称时，请对部分中的所有键执行此操作并列出它们。如果找不到值，则返回错误代码1。
• –global
  对于写入选项：写入全局文件 ~/.gitconfig 中，而不是此存储库的 .git/config，如果该文件存在，而 ~/.gitconfig文件不存在，则写入$XDG_config_HOME/git-config文件。
  对于读取选项：只从全局文件 ~/.gitconfig和$XDG_CONFIG_HOME/git/CONFIG读取，而不是从所有可用文件读取。
• –system
  对于写入选项: 写入系统范围的 $(prefix)/etc/gitconfig 中，而不是 存储库的 .git/config。
  对于读取选项: 仅从系统范围的 $(prefix)/etc/gitconfig 中读取，而不是从所有可用文件读取。
• –local
  对于写入选项: 写入存储库文件 .git/config 中。这是默认行为。
  对于读取选项: 只从存储库文件 .git/config 中读取，而不是从所有可用的文件。See also FILES。
• –worktree
  类似于 --local，唯一的区别即当 extensions.worktreeConfig 开启时，写入或读取 $GIT_DIR/config.worktree 。请注意，对于主工作树，$GIT_DIR等于 $GIT_COMMON_DIR，但对于其他工作树，其形式为 $GIT_DIR/worktrees/<id>/ 。 更多内容详见 git-worktree。
• -f <config-file>
  –file <config-file>
  对于写入选项: 写入指定的文件而不是存储库的 .git/config。
  对于读取选项: 仅从指定文件读取，而不是从所有可用文件读取。
• –blob <blob>
  类似于 – file，但使用给定的blob而不是文件。更多细节参阅git-revisions中的 “指定修订”部分。
• –remove-section
  从配置文件中删除给定的节(section)。
• –rename-section
  重命名配置文件中给定的节(section)。
• –unset
  从配置文件中删除与键(key)匹配的行。
• –unset-all
  从配置文件中删除与键(key)匹配的所有行。
• -l
  –list
  列出配置文件中所有的变量(variable)与它们的值(value)
• –fixed-value
  与value-pattern参数一起使用时，将value-pattern视为精确的字符串，而不是正则表达式。这将限制匹配的名称(name)/值(value)对仅与值模式完全相等的名称/值对。
• –type <type>
  git config将确保任何输入或输出在给定的类型约束下有效，并且将以 <type> 的规范形式规范化传出值。
  有效的 <type> 包括:
  bool: 将值规范化为 “真” 或 “假”。
  int: 将值规范化为简单的十进制数。k、m或g的可选后缀将使该值在输入时乘以1024、1048576或1073741824。
  bool-or-int: 如上所述，根据bool或int进行规范化。
  path: 通过将前缀 ~ 添加到 $HOME 的值，并将~user添加到指定用户的主目录来进行规范化。这个说明符在设置值(value)时没有效果 (但是你可以使用 git config section.variable ~/ 命令让你的shell做扩展。)
  expiry-date: 通过从固定或相对日期字符串转换为时间戳来规范化。此说明符在设置值(value)时不起作用。
  color: 获取值时，通过转换为ANSI颜色转义序列进行规范化。设置值时，将执行健全性检查，以确保给定值可规范化为ANSI颜色，但按 “是” 编写(but it is written as-is)。
• –bool
  –int
  –bool-or-int
  –path
  –expiry-date
  选择类型说明符的历史选项。比 --type 更常用
• –no-type
  取消设置先前设置的类型说明符 (type specifier)(如果先前设置了一个)。此选项请求git config不规范检索到的变量。在没有--type =<type> 或 --<type>时， --no-type 就没有效果。
• -z
  –null
  对于输出值(value)和/或键(key)的所有选项，始终以空字符结束值 (而不是换行符)。改用换行符作为键和值之间的分隔符。这允许安全地解析输出，而不会被包含换行符的值混淆。
• –name-only
  仅输出 --list或 --get-regexp的配置变量(config variable)的名称(name)。
• –show-origin
  使用原点类型(origin type) (文件、标准输入、blob、命令行) 和实际原点(actual origin) (配置文件路径、ref或blob id (如果适用)) 增强所有查询的配置选项的输出。
• –show-scope
  与 – show-origin类似，它使用该值(value)的范围 (工作树，本地，全局，系统，命令) 来增强所有查询的配置选项的输出。
• –get-colorbool <name> [<stdout-is-tty>]
  找到 <name> 的颜色设置 (例如color.diff) 并输出 “true” 或 “false”。<stdout-is-tty> 应该为 “true” 或 “false”，并且在配置为 “auto” 时要考虑在内。如果缺少 <stdout-is-tty>，则检查命令本身的标准输出，如果要使用颜色，则以状态0退出，否则以状态1退出。当名称的颜色设置未定义时，命令使用color.ui作为fallback。
• –get-color <name> [<default>]
  找到为name (例如color.diff.new) 配置的颜色，并将其作为ANSI颜色转义序列输出到标准输出。如果没有为name配置颜色，则使用可选的默认参数。
  -type = color [-default =<default>] 优于-get-color (但请注意-get-color将省略-type = color打印的尾随换行符)。
• -e
  –edit
  打开一个编辑器来修改指定的配置文件; 或者 – system，-- global或repository (默认)。
• –[no-]includes
  根据include.* 指令，选择是否在查找值时包含指定的配置文件 。给定特定文件时该指令默认为关闭 (例如，使用 – file，-- global等)，并在搜索所有配置文件时打开。
• –default <value>
  当使用 – get时，并且未找到请求的变量，其行为就好像 <value> 是分配给该变量的值。

branch.<name>.merge
这项配置很有必要熟悉一下。这项配置只在使用 fetch pull rebase push等命令时不指定分支名时有用，如果对该配置不是很理解，强烈建议输入命令时指定分支名。
与branch.<name>.remote一起定义了给定分支的上游分支（upstream branch，在本文的第2节有解释）。这项配置指定git fetch, git pull或git rebase要合并(merge)哪个分支，并且可以影响git push（参见push.default）。
当在分支<name>中时，它会指定git fetch要合并入FETCH_HEAD的要标记的默认refspec。
（翻译的不好，可以看原文理解理解，结合对refspec的解释，refspec是remote ref 和 local ref之间的映射关系，我的理解是指定哪个分支的远程与本地的映射被git fetch修改了）。
该值的处理方式类似于refspec的远程部分，并且必须与从 “branch.<name>.remote” 给定的远程获取的ref匹配。
合并信息被git pull命令 (首先调用git fetch) 使用来查找合并的默认分支。如果没有此选项，git pull将默认合并第一个获取的refspec。指定多个值以达到多合并的效果。
如果您希望设置git pull，以便它从本地存储库中的另一个分支合并到 <name>，则可以将branch.<name>.merge指向所需的分支，并使用相对路径设置 .(句点) 代表branch.<name>.remote。

3.2 add

3.2.1 简介

将文件内容加入暂存库(index)中

3.2.2 语法

$ git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
      [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--sparse]
      [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
      [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]]
      [--] [<pathspec>…​]

3.2.3 OPTIONS

• -n
  –dry-run
  不实际添加文件，只显示它们是否存在和/或将被忽略。
• -v
  –verbose
  指令执行后，输出详细内容。
• -f
  –force
  允许添加其他被忽略的文件（例如已添加到 .gitignore 中的）
• –sparse
  允许更新“稀疏签出锥(sparse-checkout cone)”外部的暂存库条目(index entries)
  
  通常，git add拒绝更新路径不适合稀疏签出锥的暂存库条目，因为这些文件可能会在没有警告的情况下从工作树中删除。
  
  更多详细内容参考 git-sparse-checkout
• -i
  –interactive
  以交互方式将工作树中修改后的内容添加到索引中。可以提供可选的路径参数，以将操作限制在工作树的子集上。
  
  有关详细信息，请参阅“Interactive mode”。
• -p
  –patch
  交互式地在暂存库和工作树之间选择补丁块(hunks of patch)，并将它们添加到暂存库中。这让用户有机会在将修改后的内容添加到暂存库之前查看差异。
  这有效地运行了add-interactive，但跳过了初始命令菜单，直接跳到patch子命令。
• -e
  –edit
  在编辑器中打开diff与暂存库，让用户进行编辑。关闭编辑器后，调整 hunk标头并将补丁(patch)应用于暂存库。
  
  此选项的目的是拾取和选择要应用的修补程序的行，甚至修改要暂存的行的内容。这比使用交互式块选择器更快、更灵活。然而，很容易混淆自己，并创建一个不适用于索引的补丁。请参阅下面的 EDITING PATCHES。
• -u
  –update
  更新暂存库中已有的、且与<pathspec>匹配的条目(entries)。这将删除和修改暂存库中的条目以匹配工作树，但不会添加新文件。
  
  如果在使用 -u 选项时没有给出<pathspec>，则整个工作树中所有被跟踪的文件都会更新（旧版本的Git用于将更新限制在当前目录及其子目录）。|
• -A
  –all
  –no-ignore-removal
  更新暂存库中与<pathspec>匹配的来自工作树的文件、暂存库中原有的条目。这会添加、修改和删除暂存库中的条目（index entries），以匹配工作树。
  
  如果在使用 -A 选项时没有给出 <pathspec>，则整个工作树中的所有文件都会更新（旧版本的Git用于将更新限制在当前目录及其子目录）。
• –no-all
  –ignore-removal
  通过添加暂存库未知的新文件和在工作树中修改过的文件来更新暂存库，但忽略已从工作树中删除的文件。当不使用＜pathspec＞时，此选项无任何操作。
  
  这个选项主要是为了帮助那些习惯于旧版本Git的用户，他们的"Git-add<pathspec>…​是“git-add--no-all＜pathspec＞…​”，即忽略已删除的文件。
• -N
  –intent-to-add
  只记录稍后将添加路径的事实。仅将路径的条目被放置在暂存库中，而没有任何内容。这对于使用git diff显示此类文件的未暂存内容并使用git commit -a提交这些文件非常有用。
• –refresh
  不添加文件，而只是在暂存库中刷新它们的stat() 信息。
• –ignore-erroes
  如果某些文件由于索引错误而无法添加，不中止操作，而是继续添加其他文件。命令仍应以非零状态退出。配置变量 add.ignoreErrors 可以设置为true，使其成为默认行为。
• –ignore-missing
  此选项只能与 --dry-run 一起使用。通过使用此选项，用户可以检查是否会忽略任何给定的文件，无论它们是否已经存在于工作树中。
• –no-warn-embedded-repo
  |默认情况下，在不使用 git submodule add 在 .gitmodules 中创建条目的情况下，将嵌入存储库(an embedded repository)添加到暂存区(index)，git add 将发出警告。此选项将抑制警告（例如，如果您手动对子模块执行操作）。
• –renormalize
  略
• –chmod=(+|-)x
  覆盖所添加文件的可执行位。可执行位只在暂存库中更改，磁盘上的文件保持不变。（我不知道详细作用）
• –pathspec-from-file=<file>
  pathspec 是在 <file> 中传递的，而不是在命令行参数中。如果 <file> 是 -，则使用标准输入。pathspec元素由LF或CR/LF分隔(CR, Carriage Return，表示回车；LF, Line Feed，表示换行)。pathspec元素可以引用配置变量 core.quotePath 的解释（参见git-config）。另请参阅路 --pathspec-file-nul 和全局 --literal-pathspecs。
• –pathspec-file-nul
  仅对 --pathspec-from-file 有意义。<pathspec>元素用NUL字符分隔，所有其他字符都按字面意思 (包括换行符和引号)。
• --
  用于分隔，告诉git不要将更多的参数解释为选项。
• <pathspec>
  限制受操作影响的路径。

3.2.4 Interactive Mode

当命令进入交互模式时（即使用 -i | --interactive），它会显示状态子命令的输出，然后进入其交互命令循环。
命令循环显示可用的子命令列表，并给出提示 What now> 。通常，当提示以单个 > 结束时，只能选择给定的选项之一并键入return，如下所示：

    *** Commands ***
      1: status       2: update       3: revert       4: add untracked
      5: patch        6: diff         7: quit         8: help
    What now> 1

status	这显示了每个路径的HEAD和暂存库之间的修改（即，当使用 git commit 时将提交什么），以及暂存库和工作树文件之间的变化
update	这将显示状态信息并发出“Update>>”提示。当提示以双>>结尾时，可以进行多个选择，并用空格或逗号连接。也可以说范围。例如“2-5 7,9”，从列表中选择2,3,4,5,7,9。如果一个范围中的第二个数字被省略，则所有剩余的补片都将被采用。例如，“7-”从列表中选择7,8,9。 也可以使用 * 来选择所有，当使用 * 时被选中的将被高亮。 要删除所选内容，请在输入前加上-，例如：Update>> -2 选择后，用空行回答以暂存暂存库中所选路径的工作树文件的内容。
revert	所选路径的暂存信息将恢复为HEAD版本的信息。 恢复新路径会使它们不受跟踪。
add untracked	将未受跟踪的路径添加入暂存库
patch	这使您可以从类似状态的选择中选择一条路径。选择路径后，它会显示索引和工作树文件之间的差异，并询问您是否要对每个大块进行更改。您可以选择以下选项之一并键入return： y - 暂存这个块(hunk) n - 不要暂存这个块 q - 退出；不要暂存这个块或剩下的任何一个 a - 暂存这个块和文件中后续的块 d - 不暂存这个块和文件中后续的块 g - 选择要跳转到的块 / - 搜索与给定正则表达式匹配的块 j - 先不决定如何操作这个块，即跳过，看看下一个未被决定如何操作的块 J - 先不决定如何操作这个块，即跳过，看看下一个块 k - 先不决定如何操作这个块，看看上一个未被决定如何操作的块 K - 先不决定如何操作这个块，即跳过，看看上一个块 s - 将当前块分割成更小的块 e - 手动编辑当前块 ? - 打印帮助 在决定了所有块的命运后，如果有任何大块头被选中，则暂存库会用所选的块更新。 通过将配置变量 interactive.singleKey 设置为true，您可以省略在此处键入return的操作。
diff	查看将要提交的内容（即在HEAD和索引之间）。

3.3 status

3.3.1 简介

显示工作树状态。笔者注：该命令侧重于显示哪些文件被修改了，且修改后未提交导致working directory中与tree中不一致。如果是想查看 被追踪/未被追踪的文件有哪些，更推荐使用 git ls-files -c/-o

显示Index文件和当前HEAD提交之间存在差异的路径，工作树和Index文件之间存在差异，以及工作树中未被Git跟踪的的路径（且该路径未被 gitignore 忽略）。第一项中的内容是通过运行git-commit来提交的内容；第二项和第三项是可以通过在运行git commit 之前运行git add来提交的内容。

3.3.2 语法

git status [<options>] [--] [<pathspec>…​]

3.3.3 OPTIONS

• -s
  –short
  以简短的格式给出输出。
• -b
  –branch
  显示分支和跟踪信息，可以以简短格式输出。
• –show-stash
  显示当前隐藏(stash)的条目数（详见git stash理解 stash 的含义）。|
• –porcelain[<version]
  为脚本提供易于解析的输出格式。这与简短输出类似，但无论用户配置如何，在Git版本中都将保持稳定。有关详细信息，请参见下文。
  version参数用于指定格式版本。这是可选的，默认为原始版本v1格式。|
• –long
  以长格式输出。这是默认设置。
• -v
  –verbose
  除了显示已更改的文件的名称外，还显示要提交的文本更改（例如，类似于 git diff --cached 的输出）（已使用 git add 的）。如果指定了两次 -v，那么还显示工作树中尚未暂存的更改（例如，类似于git diff的输出）（未使用 git add 的）。
• -u[<mode>]
  –untracked-files[=<mode>]
  显示未跟踪的文件。（与 git ls-files -o 不同之处在于，git status -u 显示的是 未添加至.gitignore 文件终且未被追踪的文件，而 git ls-files -o 显示的是 working directory 中不会被git的所有文件，即使有文件已被添加入 .gitignore）
  mode参数用于指定对未跟踪文件的处理。它是可选的：它默认为all，如果指定，它必须紧紧接在选项后（例如，应为 -uno，但不是 -u no）。
  可能的选项包括：
  no - 不显示未跟踪的文件。
  normal - 显示未跟踪的文件和目录。
  all - 还显示未跟踪目录中的单个文件。|
• –ignore-submodules[=<when>]
  在查找更改时忽略对子模块的更改。<when>可以是“none”、“untracked”、“dirty”或“all”，all是默认值。
• –ignored[=<mode>]
  显示被忽略的文件。（同样与 git ls-files -o 对比，但我词尽了，不太会描述）
  mode参数用于指定对被忽略文件的处理。它是可选的：默认为 traditional。
  可能的选项包括：
  traditional - 显示被忽略的文件和目录，除非指定–untracked files=all，在这种情况下，将显示被忽略目录中的单个文件。
  no - 不显示被忽略的文件。
  matching - 显示与忽略模式匹配的被忽略文件和目录。
  当指定匹配模式时，将显示显式匹配被忽略模式的路径。如果目录与忽略模式匹配，则会显示该目录，但不会显示被忽略目录中包含的路径。如果某个目录与忽略模式不匹配，但忽略了所有内容，则不会显示该目录，而是显示所有内容。
• -z
  用NUL(Null character，表示空字符)而不是LF(LF, Line Feed，表示换行)终止条目。如果没有给出其他格式，这意味着–porcelain=v1输出格式。
• –column[=<options>]
  –no-column
  按列显示未跟踪的文件。有关选项语法，请参阅配置变量 column.status.
  
  在没有options 情况下 --column 和 --no-column分别等效于“always”和“never”。
• –ahead-behind
  –no-ahead-behind
  显示或不显示分支相对于其上游分支的详细提前/滞后计数。默认为true。
• –renames
  –no-renames
  无论用户配置如何，都可以打开/关闭重命名检测。另请参阅git-diff --no-renames。
• –find-renames[=<n>]
  启用重命名检测，可以选择设置相似性阈值。另请参阅git-diff --no-renames。
• <pathspec>…`
  略

3.4 diff

3.4.1 简介

显示提交与提交之间、提交和工作树之间等的更改

git diff [<options>] [--] [<path>…​]

此形式用于查看相对于暂存库(index，下一次提交的暂存区域)所做的更改。可以使用git add暂存这些更改。

git diff [<options>] --no-index [--] <path> <path>

这种形式是比较文件系统上给定的两条路径。当在Git控制的工作树中运行命令并且至少有一条路径指向工作树之外时，或者在Git控制的工作树之外运行命令时，可以省略--no-index选项。这种形式意味着--exit-code。

git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>…​]

此形式用于查看为下一次提交进行的暂存，相对于名称为<commit>的提交的更改。如果不提供<commit>，它默认为HEAD，即与最新的提交进行比较。如果HEAD不存在并且没有提供<commit>，它会显示所有已暂存的更改。--staged等同于--cached。
如果给定--merg-base，而不是使用<commit>，则使用<commit>和HEAD的合并基。git diff --cached --merge-base A等价于git diff --cached $(git merge-base A HEAD)。

git diff [<options>] [--merge-base] <commit> [--] [<path>…​]

此形式用于查看您在工作树中相对于名称为<commit>的提交的更改。您可以使用HEAD将其与最新提交进行比较，或者使用分支名称将其与不同分支的尖端进行比较。
如果给定--merg-base，而不是使用<commit>，则使用<commit>和HEAD的合并基。git diff --merge-base A 等同于 git diff $(git merge-base A HEAD)

git diff [<options>] [--merge-base] <commit> <commit> [--] [<path>…​]

这是为了查看两个任意<commit>之间的变化。如果给定--merg-base，则将两次提交的合并基当做“之前”端。git diff --merge-base A B 等同于 git diff $(git merge-base A B) B

git diff [<options>] <commit> <commit>…​ <commit> [--] [<path>…​]

此形式用于查看合并提交的结果。第一个<commit>必须是合并本身；其余两个或多个<commit>应该是它的父级。生成所需修订集的便捷方法是使用后缀^@和^！。如果 A 是合并提交，则git diff A A^@、git diff A^! 和 git show A 都给出相同的组合diff。

git diff [<options>] <commit>..<commit> [--] [<path>…​]

此形式也可以用于查看两个任意<commit>之间的更改。如果省略一侧的<commit>，则被默认为 HEAD。

git diff [<options>] <commit>...<commit> [--] [<path>…​]

此形式用于查看从两个<commit>的共同祖先开始，到包含并且上至第二个<commit>的分支上的更改（即如果该分支上在第二个<commit>还有节点，是不管的）。git diff A… B等价于 git diff $(git merge-base A B) B 。如果省略一侧的<commit>，则被默认为 HEAD。

git diff [<options>] <blob> <blob>

此形式用于查看两个Blob对象的原始内容之间的差异。

3.4.2 语法

git diff [<options>] [<commit>] [--] [<path>…​]
git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>…​]
git diff [<options>] [--merge-base] <commit> [<commit>…​] <commit> [--] [<path>…​]
git diff [<options>] <commit>…​<commit> [--] [<path>…​]
git diff [<options>] <blob> <blob>
git diff [<options>] --no-index [--] <path> <path>

3.4.3 options

• -p
  -u
  –patch
  生成补丁（请参阅 Generating patch text with -p）。这是默认值。
• -s
  –no-patch
  抑制来自比较差异机制的所有输出。对于像git show这样的命令很有用，这些命令默认显示补丁以压制它们的输出，或者取消命令行前面别名中的--patch、--stat等选项的效果。
• -U<n>
  –unified=<n>
  使用<n>行上下文而不是通常的三行生成差异。默认使用--patch。
• –output=<file>
  将差异信息输出到特定文件而不是标准输出。
• –output-indicator-new=<char>
  –output-indicator-old=<char>
  output-indicator-context=<char>
  指定用于指示生成补丁中的新、旧或上下文行的字符。通常它们分别是+、-和’'。
• –raw
  以原始格式生成差异。
• –patch-with-raw
  等同于 -p --raw
• –indent-heuristic
• –no-indent-heuristic
• –minimal
• –patience
• –histogram
• –anchored=<text>
• –diff-algorithm={patience|minimal|histogram|myers}
• –stat[=<width>[,<name-width>[,<count>]]]
• –compact-summary
• –numstat
• –shortstat
• -X[<param1,param2,…​>]
  –dirstat[=<param1,param2,…​>]
• –cumulative
• –dirstat-by-file[=<param1,param2>…\​]
• –summary
• –patch-with-stat
• -z
• –name-only
• –name-status
• –submodule[=<format>]
• –color[=<when>]
• –no-color
• –color-moved[=<mode>]
• –no-color-moved
• –color-moved-ws=<modes>
• –no-color-moved-ws
• –word-diff[=<mode>]
• –word-diff-regex=<regex>
• –color-words[=<regex>]
• –no-renames
• –[no-]rename-empty
• –check
• –ws-error-highlight=<kind>
• –full-index
• –binary
• –abbrev[=<n>]
• -B[<n>][/<m>]
  –break-rewrites[=[<n>][/<m>]]

3.5 commit

3.5.1 简介

记录对存储库的更改。
创建一个新的提交，其中包含暂存库的当前内容和一条用户给定的日志消息。新提交是HEAD（通常时当前分支的尖端）的直接子级，并且分支被更新为指向它（除非没有分支与工作树相关联，在这种情况下HEAD被“分离(detached)”）。

可以通过多种方式指定要提交的内容：

1. 在使用提交命令之前，使用git-add逐步“添加”对暂存库的更改（注意：即使是修改后的文件也必须“添加”）；
2. 在使用提交命令之前，使用git-rm从工作树和暂存库中删除文件；
3. 通过将文件作为提交命令的参数列出（不使用--active或--patch），在这种情况下，提交将忽略暂存库中暂存的更改，而是记录列出文件的当前内容（Git必须已经知道）；
4. 通过使用带有-a的提交命令，自动“添加”所有已知文件（即暂存库中已经列出的所有文件）的更改，并自动“删除”暂存库中已从工作树中删除的文件，然后执行实际提交；
5. 在最终完成操作之前，通过使用带有--Interactive或--patch 的提交命令来逐个决定除了暂存库中的内容之外，哪些文件或大块(hunk)应该是提交的一部分。请参阅git-add的“交互模式”部分以了解如何操作这些模式。

--dry-run选项可用于通过提供相同的一组参数（选项和路径）来获取上述5种方式中任何一种中所包含的下一次提交的摘要。

如果您进行了提交，然后在之后立即发现错误，您可以使用git reset 进行弥补。

3.5.2 语法

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>)]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])…​] [-S[<keyid>]]
	   [--] [<pathspec>…​]

3.5.3 options

• -a
  –all

• -p
  –patch
  使用交互式补丁选择界面来选择要提交的更改。有关详细信息，请参阅 [git-add](Git - git-add Documentation (git-scm.com))。

• -C <commit>
  –reuse-message=<commit>
  获取现有的提交对象，并在创建提交时重用日志消息和作者信息（包括时间戳）。

• -c <commit>
  –reedit-message=<commit>
  与-C类似，但使用-c调用编辑器，以便用户可以进一步编辑提交消息。

• –fixup=[(amend|reword):]<commit>
  创建一个新的提交，当应用git rebase --autosquash时，该提交将“修复”<commit>。普通--fixup=<commit>创建一个“fixup!”提交，它更改<commit>的内容，但不更改其日志消息。--fixup=amend:<commit>类似，但创建了一个“amend!”提交，该提交还将<commit>的日志消息替换为“amend!”提交的日志消息。--fixup=reword:<commit>创建一个“amend!”提交，它用自己的日志消息替换<commit>的日志消息，但不对<commit>的内容进行任何更改。

  普通--fixup=<commit>创建的提交有一个由“fixup!”组成的主题，后跟<commit>中的主题行组成，该提交由git rebase --autosquash特别识别。-m选项可用于补充已创建提交的日志消息，但一旦“fixup!”提交被git rebase --autosquash压缩为<commit>，则附加注释将被丢弃。

  --fixup=amend:<commit>创建的提交类似，但其主题以“amend!”为前缀。<commit>的日志消息被复制到“amend!”提交的日志消息中，并在编辑器中打开，以便对其进行细化。当git rebase --autosquash将“amend!”提交压缩为<commit>时，<commit>的日志消息将被来自“amend!”提交的细化日志消息所取代。除非指定了--allow empty message，否则“amend!”提交的日志消息为空是错误的。

  --fixup=reword:<commit>是--fixup=amend:<commit> --only的简写。它只使用一条日志消息（忽略暂存库中的任何更改）创建一个“amend!”提交。当被git rebase --autosquash压缩时，它将替换<commit>的日志消息，而不进行任何其他更改。

  当git rebase --autosquash应用时，"fixup!"和"amend!"都不更改<commit>的作者身份。见 [git-rebase](Git - git-rebase Documentation (git-scm.com))。

• –squash=<commit>
  构造用于rebase --autosquash的提交消息。提交消息主题行取自指定的提交，前缀为“squash!”。可与其他提交消息选项（-m/-c/-C/-F）一起使用。有关详细信息，见 [git-rebase](Git - git-rebase Documentation (git-scm.com))。

• –reset-author

• –short
  进行试运行(dry-run)时，以短格式给出输出。默认使用 --dry-run。

• –branch

• –porcelain

• –long

• -z
  –null

• -F <file>
  –file=<file>

• –author=<author>

• –date=<date>

• -m <msg>
  –message=<ms>

• -t <file>–template=<file>

• -s
  –signoff
  –no-signoff

• –trailer <token>[(=|:)<value>]

• -n
  –[no-]verify

• –allow-empty

• –allow-empty-message

• –cleanup=<mode>
  此选项用于确定在提交之前应如何清理提供的提交消息。<mode>可以是strip, whitespace, verbatim , scissors , default
  strip
  去除前导和尾随空行、尾随空格、注释和折叠连续空行。
  whitespace
  与strip相同，只是不删除 # 注释
  verbatim
  不对信息进行修改
  scissors
  与 whitespcae 相同，只是如果要编辑消息，则来自（和包括）下面一行的所有内容都将被截断。"#"可以使用core.commentChar自定义。
  # ------------------------ >8 ------------------------
  default
  如果要编辑消息，则与 strip 相同。否则为 whitespace。
  默认值可以通过commit.cleanup变量更改

• -e
  –edit

• –amend
  通过创建一个新的提交来替换当前分支的顶端。被记录的树照常准备（包括-i和-o选项和显式路径规范的效果），当没有通过-m、-F、-c等选项从命令行指定其他消息时，使用原始提交的消息作为起点，而不是空消息。新的提交与当前提交具有相同的父级和作者（--reset-author选项可以抵消这一点）。

  如果您修改已发布的提交，您应该了解重写历史记录的含义。(见 [git-rebase](Git - git-rebase Documentation (git-scm.com)) 中的 RECOVERING FROM UPSTREAM REBASE)

• –no-post-rewrite

• -o
  –only

• –pathspec-from-file=<file>

• –pathspec-file-nul

• -u[<mode>]
  –untracked-files[=<mode>]
  显示未跟踪的文件。
  mode参数是可选的（默认为all），用于指定对未跟踪文件的处理；不使用-u时，默认为normal，即显示未跟踪的文件和目录。

• -v
  –verbose
  显示HEAD提交与提交消息模板底部将提交的内容之间的统一差异，通过提醒提交有哪些更改来帮助用户描述提交。请注意，此差异输出的行没有以#为前缀。此差异不会成为提交消息的一部分。请参阅git-config中的commit.verbose变量。

  如果指定两次，则另外显示将提交的内容和工作树文件之间的统一差异，即对跟踪文件的未暂存更改。

• -q
  –quiet
  抑制提交摘要消息。

• –dry-run
  不创建提交，而是显示要提交的路径列表、具有未提交的本地更改的路径以及未跟踪的路径。

• –status
  使用编辑器准备提交消息时，在提交消息模板中包含git-status的输出。默认为on，但可用配置变量 conf. status 进行覆盖。

• –no-status
  使用编辑器准备默认提交消息时，不要在提交消息模板中包含git-status的输出。

• -S[<keyid>]
  –gpg-sign[=<keyid>]
  –no-gpg-sign
  GPG签名提交。keyid参数是可选的，默认为提交者身份；如果指定，它必须以不带空格的方式紧紧附在选项之后。

• --
  分隔符，此后的内容不被识别为 options。

• <pathspec>
  略

3.6 notes

3.7 restore

3.7.1 简介

注意：该命令是实验性的，以下内容适用于git version 2.42.0，该命令的具体行为之后可能会改变。

使用还原源中的某些内容还原工作树中的指定路径。如果某路径被跟踪但在还原源中不存在，则会将其删除以匹配该源。
该命令还可以用于使用 --staged 恢复暂存区(index)中的内容，或者使用 --stage --worktree 恢复工作树和索引。
默认情况下，如果给定 --staged，则从HEAD还原内容，否则从暂存区还原内容。使用 --source 从其他提交(commit)进行恢复。
“Reset，restore and revert”这三个命令之间的差异。

《一次搞清 git checkout，git restore 和 git reset》

下图是经我测试并理解git reference中的话，总结了一张图：

3.7.2 语法

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>…​
git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>…​]

3.7.3 OPTIONS

• -s <tree>--source=<tree>
  使用给定树中的内容恢复工作树(working tree)文件。通常通过给出提交(commit)、分支(branch)或标签(tag)的名称来指定源树。如果未指定，则在给定 --staged 的情况下从 HEAD 还原内容，否则从暂存区还原内容。作为一种特殊情况，如果正好有一个合并基(merge base)，则可以使用 “A…B” 作为A和B的合并基的快捷方式。您最多可以省略A和B中的一个，在这种情况下，它默认为HEAD。
• -p--patch
  在还原源和还原位置之间的差异中交互选择块。请参阅gitadd的“交互模式(Interactive Mode)”部分，了解如何操作 --patch 模式。
• -W
--worktree
-S
--staged
  指定还原位置。如果两个选项都未指定，则默认情况下将恢复工作树。指定 --staged 只会恢复暂存区。指定两者都可以恢复两者。
• -q
--quiet
  安静，抑制反馈信息。暗示 --no-progress 。
• -pogress–no-progress|默认情况下，当标准错误流连接到终端时，会在标准错误流上报告进度状态，除非指定–quiet。此标志启用进度报告，即使未连接到终端，或已指定 --quiet。|
• –ours–theris|当从索引恢复工作树中的文件时，对未合并的路径使用 stage #2（ours）或 #3（theirs）。请注意，在 git-rebase 和 gitpull–rebase 期间，ours 和 theirs 可能会出现交换。有关详细信息，请参阅 git checkout 中对相同选项的解释。|
• -m
  –merge
  从暂存区恢复工作树上的文件时，请在未合并的路径中重新创建冲突的合并。
• --conflict=<style>
  略
• --ignore-unmerged
  略
• --ignore-skip-worktree-bits
  略
• –recurse-submodules
--no-recurse-submodules
  略
• --overlay
--no-overlay
  在覆盖模式下，该命令在恢复时从不删除文件。在无覆盖模式下，未出现在 --source 树中的被跟踪文件将被删除，以使它们与<tree>完全匹配。默认为无覆盖模式。
• --pathspec-from-file=<file>
  略，在git add处已解释过
• --pathspec-file-nul
  略
• --
  略
• <pathspec>…​
  略

3.8 reset

3.9 rm

3.9.1 简介

git-rm 从工作树(working tree)和暂存区(index)中删除文件。

删除 暂存区 或 工作树和暂存区 中与 pathspec 匹配的文件。git rm不会仅从工作目录中删除文件 (没有选项只能从工作树中删除文件，但仍将其保留在暂存库中)。要删除的文件必须与分支的尖端相同，并且不能在索引中暂存对其内容的更新，尽管可以使用 -f 选项覆盖该默认行为。当给出 – cached 时，暂存的内容必须与分支的尖端或磁盘上的文件相匹配，从而允许仅从索引中删除文件。当使用稀疏校验时 (请参阅git-稀疏-checkout )，git rm只会删除稀疏校验模式中的路径。

3.9.2 语法

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch]
      [--quiet] [--pathspec-from-file=<file> [--pathspec-file-nul]]
      [--] [<pathspec>…​]

3.9.3 Options

<pathspec>…​

即要删除的文件。可以给出一个前导目录名称以删除目录中的所有文件，并递归地删除所有子目录（例如输入 dir 会删除 dir/file1和dir/file2），但这需要显式给出 -r选项。 该命令仅删除Git已知的路径。 文件全局匹配跨目录边界。因此，给定两个目录d和d2，使用git rm 'd * '和 git rm ‘d/*’ 之间存在差异，因为前者也将删除目录d2的全部。 有关更多详细信息，请参阅 gitglossary 中的 pathspec条目。

• -f
--force
  覆盖最新检查
• -n
--dry-run
  实际上不会删除任何文件，而只显示它们是否存在于索引（Index）中，否则会被命令删除。
• -r
  在给定前导目录名时允许递归删除。
• --
  此选项可用于将命令行选项与文件列表分开 (在文件名可能被误认为是命令行选项时很有用)。
• --cached
  使用此选项可以仅从索引中取消和删除路径。工作树文件，无论是否修改，都将被保留。
• --ignore-unmatch
  即使没有匹配的文件，也以零状态退出。
• --sparse
  允许更新稀疏签出锥(sparse-checkout cone)外部的索引项。通常，git-rm拒绝更新路径不适合稀疏签出锥的索引项。有关详细信息，请参阅 git-sparse-checkout 。
• -q
--quiet
  git rm通常为每个删除的文件输出一行 (以rm命令的形式)。使用此选项将抑制该输出，即删除文件时不输出信息|
• --pathspec-from-file=<file>
  略
• --pathspec-file-nul
  略

3.10 mv

3.11 branch

3.11.1 介绍
用于列出、创建或删除分支。
如果给出了--list，或者没有非选项参数，则列出现有分支；当前分支将以绿色突出显示，并用星号标记。在链接的工作树中签出(checkout)的任何分支都将以青色突出显示并用加号标记。选项-r将列出远程跟踪分支，选项-a同时显示本地和远程分支。

如果给定了<pattern>，它将被用作shell通配符，以将输出限制为匹配的分支。如果给定了多个patterns，那么如果分支与任一pattern匹配，就会显示该分支。

请注意，当提供<pattern>时，必须使用--list；否则该命令可以被解释为分支创建。

有了--contains，只显示包含指定提交的分支（换句话说，其顶部提交(tip commit)是指定提交的后代的分支），--no contains效果相反。有了--merged，只列出合并到指定提交中的分支（即，可以从指定提交访问到其顶部提交的分支）。--no-merged将只列出未合并到指定提交中的分支。如果缺少<commit>参数，则默认为HEAD（即当前分支的顶部）。

该命令的第二种形式创建一个名为<branchname>的新分支头，该分支头指向当前head，或在给定<startpoint>的情况下指向<startpoint>。作为一种特殊情况，对于<start-point>，如果正好有一个合并基，则可以使用“A...B”作为a和B的合并基的快捷方式。您最多可以省略A和B中的一个，在这种情况下，被省略的会被默认为HEAD。

注意，该命令将创建新的分支，但不会将工作树切换到它；使用git switch <newbranch>切换到新分支。

使用-m或-M选项，<oldbranch>将被重命名为<newbranch>。如<oldbranch>有一个相应的reflog，它会被重命名以匹配<newbranch>，并创建一个reflog条目来记住这次分支重命名操作。如果<newbranch>存在，则必须使用-M来强制进行重命名。

-c和-C选项与-m和-M具有完全相同的语义，只是分支不会被重命名，而是会被复制到一个新名称，以及它的config和reflog。

使用-d或-D选项，<branchname>将被删除。您可以指定多个要删除的分支。如果分支当前有一个reflog，那么该reflog也将被删除。

将-r与-d一起使用可以删除远程跟踪（remote-tracking）分支。请注意，只有当远程跟踪分支不再存在于远程存储库中，或者git fetch被配置为不再提取这些分支时，删除这些分支才有意义。有关清理所有过时的远程跟踪分支的方法，请参阅gitremote的prune子命令。

3.11.2 语法

git branch [--color[=<when>] | --no-color] [--show-current]
	[-v [--abbrev=<n> | --no-abbrev]]
	[--column[=<options>] | --no-column] [--sort=<key>]
	[--merged [<commit>]] [--no-merged [<commit>]]
	[--contains [<commit>]] [--no-contains [<commit>]]
	[--points-at <object>] [--format=<format>]
	[(-r | --remotes) | (-a | --all)]
	[--list] [<pattern>…​]
git branch [--track[=(direct|inherit)] | --no-track] [-f]
	[--recurse-submodules] <branchname> [<start-point>]
git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
git branch --unset-upstream [<branchname>]
git branch (-m | -M) [<oldbranch>] <newbranch>
git branch (-c | -C) [<oldbranch>] <newbranch>
git branch (-d | -D) [-r] <branchname>…​
git branch --edit-description [<branchname>]

3.11.3 OPTIONS

• -d
  –delete
  删除分支。分支必须在其上游分支中完全合并，如果没有使用--track或--set upstream设置上游分支，则该分支必须在HEAD中完全合并。
• -D
  --delete --force的简写
• –create-reflog
  创建分支的reflog。这将激活对分支引用(ref)所做的所有更改的记录，从而允许使用基于日期的sha1表达式，如“<branchname>@｛yesterday｝”。请注意，在非裸存储库中，reflog通常默认由core.logAllRefUpdates配置选项启用。否定的形式--no create reflog只覆盖早期的--create refog，但当前不否定core.logAllRefUpdates的设置。
• -f
  –force
  将<branchname>重置为<start point>，即使<branchname>已经存在。如果没有-f，git分支将拒绝更改现有分支。与-d（或-delete）结合使用，允许删除分支，而不管其合并状态如何，或者它是否指向有效的提交。与-m（或--move）结合使用时，即使新的分支名称已经存在，也允许重命名该分支，这同样适用于-c（或--copy）。
  请注意，git branch -f <branchname> [<start point>]，即使使用-f，也拒绝更改在链接到同一存储库的另一个工作树中签出的现有分支<branchname>。
• -m
  –move==
  移动/重命名分支及其配置和reflog。
• -M
  --move --force的简写
• -c
  –cpoy
  复制分支及其配置和reflog。
• -C
  --copy --force的简写
• –color[=<when>]
  为分支着色以突出显示当前、本地和远程跟踪分支。该值必须是“always”（默认值）、“never”或“auto”。
• –no-color
  关闭分支颜色，即使配置文件为颜色输出提供了默认值。与--color=never相同。
• -i
  –ignore-case
  排序和筛选分支不区分大小写。
• –omit-empty
  不要在格式化的refs之后打印换行符，其中格式扩展为空字符串。
• –column[=<options>]
  –no-column
  以列形式显示分支列表。有关选项语法，请参阅配置变量column.branch。不带选项的--column和--no-column分别等效于“always”和“never”。
  此选项仅适用于非详细模式。
• -r
  –remotes
  列出或删除（如果与-d一起使用）远程跟踪分支。与--list组合以匹配可选模式(pattern)。
• -a
  –all
  列出远程跟踪分支和本地分支。与--list组合以匹配可选模式。
• -l
  –list
  列出分支。使用可选的<pattern>...，例如git branch --list 'maint-*'，只列出与模式匹配的分支。
• –show-current
  打印当前分支分支的名称。在分离的(detached)HEAD状态下，不打印任何内容。
• -v
  -vv
  –verbose
  在列表模式下，显示每个头部的sha1和提交主题行，以及与上游分支的关系 (如果有)。如果给定两次，则打印链接的worktree的路径 (如果有) 和上游分支的名称 (另请参阅git remote show <remote>)。请注意，当前worktree的头部不会打印其路径 (它将始终是您的当前目录)。
• -q
  –quiet
  创建或删除分支时要更加安静，禁止显示非错误消息。
• –abbrev=<n>
  在显示提交对象名称的详细列表中，显示唯一引用对象的最短前缀，该前缀的长度至少为<n>个六进制数字。默认值为7，可由core.abbrevconfig选项覆盖。
• –no-abbrev
  在输出列表中显示完整的sha1，而不是缩写它们。
• -t
  –track[=(direct|inherit)]
  创建新分支时，设置branch.<name>.remote和branch.<name>.merge配置条目以设置新分支的“上游”跟踪配置。此配置将告诉git在git status和git branch-v中显示两个分支之间的关系。此外，当签出新分支时，它指示不带参数的git pull从上游进行pull。
  确切的上游分支是根据可选参数选择的：其中-t、--track或--track=direct表示使用起点分支本身作为上游；--track=inherit表示复制起点分支的上游配置。
  branch.autoSetupMerge配置变量指定在既没有指定--track也没有指定--no track时git switch、git checkout和git branch的行为：
  默认选项true的行为就像在起点为远程跟踪分支时给定--track=direct一样。false的行为就好像没有给出--no-track。always表现得好像给定了--track=direct。inherit的行为就像给定了--track=inherit一样。simple的行为就像只有当起点是远程跟踪分支并且新分支与远程分支同名时才给出--track=direct一样。
  请参阅git pull和git config，以了解branch.<name>.remote和branch.<name>.merge选项如何使用。
• –no-track
  即使设置了branch.autoSetupMerge配置变量，也不要设置“upstream”配置。
• –recurse-submodules
• –set-upstream
  已弃用，请改用--track或--set upstream。
• -u <upstream>
  –set-upstream-to=<upstream>
  设置<branchname>的跟踪信息，使<upstream>被视为<branchname>的上游分支。如果没有指定<branchname>，则默认为当前分支。这里提示一下，使用方法是git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
• –unset-upstream
  删除<branchname>的上游信息。如果未指定分支，则默认为当前分支。
• –edit-description
  打开编辑器并编辑文本以解释分支的用途，供各种其他命令使用（例如format-patch、request-pull和merge（如果启用））。可以使用多行解释。
• –contains [<commit>]
  仅列出包含指定提交的分支（如果未指定，则为HEAD）。该option默认使用--list。
• –no-contains [<commit>]
  仅列出不包含指定提交的分支（如果未指定，则为HEAD）。该option默认使用--list。
• –merged [<commit>]
  仅列出其顶端可从指定的提交（如果未指定，则为HEAD）访问的分支。该option默认使用--list。
• –no-merged [<commit>]
  略
• <branchname>
  
• <start-point>
  
• <oldbranch>
  
• <newbranch>
  
• –sort=<key>
  略
• –points-at <object>
  仅列出给定对象的分支。
• –format <format>
  从显示的分支引用及其指向的对象中插入%(fieldname)的字符串。格式 git-for-each-ref相同。

3.12 checkout

从本地仓库获取内容，放入工作区(workspace)

3.13 switch

3.13.1 简介

用于切换分支

3.13.2 语法

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

3.13.3 options

• -c <new-branch>
  –create <new-branch>
  从<start-point>开始创建一个名为<new-branch>的新分支并切换到新分支。

• -C <new-branch>
  –force-create <new-branch>
  与-c相似，不同之处在于如果<new-branch>存在，则新分支会重置到<start-point>

• -d
  –detach
  切换到提交以进行检查和可丢弃的实验。关于“分离的”详细内容见 git-checkout DETACHED HEAD

• –guess
  –no-guess
  如果未找到<branch>，但在一个具有匹配名称的远程（称为<remote>）中确实存在跟踪分支，则将其视为等效于:

  $ git switch -c <branch> --track <remote>/<branch>
  

  如果分支存在于多个远程中，并且其中一个由checkout.defaultRemote配置变量命名，我们将使用该分支来消除歧义，即使<branch>在所有远程中不是唯一的。如果<branch>可能引起歧义但存在于远程仓库origin中，将其设置为例如checkout.defaultRemote=origin。另请参阅 git-config 中的checkout.defaultRemote。

  --guess是默认行为。使用--no-guess禁用它。默认行为可以通过checkout.guess配置变量设置。

• -f
  –force
  –discard-changes
  即使暂存库或工作树与HEAD不同，也要继续。暂存库和工作树都将恢复(restore)以匹配切换目标。如果指定了--recurse-submodules，子模块内容也将恢复以匹配切换目标。这用于丢弃本地更改。

• -m
  –merge
  如果您对当前分支和要切换到的分支之间不同的一个或多个文件进行了本地修改，则该命令拒绝切换分支以在上下文中保留您的修改。但是，使用此选项，当前分支、您的工作树内容和新分支之间的三方合并就完成了，您将在新分支上。

  当发生合并冲突时，冲突路径的暂存库条目未合并，您需要解决冲突并使用git add标记已解决的路径（如果合并应导致路径删除，则使用git rm）。

• –conflict=<style>

• -q
  –quiet
  略

• –progress
  –no-progress
  默认情况下，当标准错误流附加到终端时，会在标准错误流上报告进度状态，除非指定了--quiet。即使没有附加到终端，--progress标志也可以启用进度报告，而不管--quiet。

• -t
  –track [direct|inherit]
  创建新分支时，设置“上游”配置。-c是隐含的。有关详细信息，请参阅git-branch中的--track。

  如果没有给出-c选项，则新分支的名称将从远程跟踪分支派生，方法是查看为相应远程配置的refspec的本地部分，然后将初始部分剥离为“*”。这将告诉我们在origin/hack（或remotes/origin/hack，甚至是refs/remotes/origin/hack）时使用hack作为本地分支。如果给定的名称没有斜杠，或者上述猜测导致名称为空，则猜测将中止。在这种情况下，您可以显式地给出一个带有-c的名称。

• –no-track
  不要设置“上游”配置，即使branch.autoSetupMerge配置变量为 ture。

• –orphan <new-branch>
  创建一个新的孤立分支，名为<new-branch>。所有跟踪的文件都被删除。

• –ignore-other-worktrees
  当所需的参考已经被另一个工作树签出(checkout)时，git switch会拒绝。此选项使其无论如何都要签出参考。换句话说，ref可以由多个工作树保存。

• –recurse-submodules
  –no-recurse-submodules
  使用--recurse-submodules将根据超级项目中记录的提交更新所有活动子模块的内容。如果什么都没有使用（或使用了--no-recurse-submodules），子模块工作树将不会更新。就像 git-submodule一样，这将分离子模块的HEAD。

3.14 merge

3.14.1 简介

将两个或多个开发历史连接在一起。

将来自给定名称的提交（自其历史记录与当前分支偏离时起）中的更改合并到当前分支中。此命令可被git pull命令用来合并来自另一个存储库的更改，也可被手动使用进行将来自一个分支的更改合并到另一个分支中的操作。

假设存在以下历史记录并且当前分支是“master”：

          A---B---C topic
	     /
    D---E---F---G master

git merge topic会在master分支上重做 topic 分支自从master分支分离后（即从节点 “E” 分离出去）至其当前提交 “C” 所做的更改，并将结果、两个父提交的名称、一条新的来自用户描述所做更改的日志信息三项记录成一个新的提交。

          A---B---C topic
	     /         \
    D---E---F---G---H master

第二种语法 git merge --abort 只能在合并导致冲突后运行。git merge --abort 将中止合并过程并尝试重建合并前的状态。但是，如果合并开始时有未提交的更改（特别是如果这些更改在合并开始后被进一步修改），git merge --abort 在某些情况下将无法重建原始（合并前）更改。因此

警告：不鼓励使用重要的(non-trivial)的未提交更改运行git merge：如果这么做的话，可能会在有冲突情况下使您难以退出。

第三种语法git merge --continue 只能在合并导致冲突后运行。

笔者注：如果合并操作已经完成（即解决冲突后 commit 了），想撤销合并操作，可以使用git reset --hart <commitID>

3.14.2 语法

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
	[--into-name <branch>] [<commit>…​]
git merge (--continue | --abort | --quit)

3.14.3 options

• –commit
  –no-commit
• –edit
  -e
  –no-edit
• –cleanup=<mode>
• –ff
  –no-ff
  –ff-only
• -S[<keyid>]
• –log[=<n>]
  –no-log
• –signoff
  –no-signoff
• –stat
  -n
  –no-stat
• –squash
  –no-squash
• –[no-]verify
• -s<strategy>
• -X<option>
• –verify-signatures
• –summary
• -q
  –quiet
• -v
  –verbose
• –porgress
  –no-progress
• –autostash
  –no-autostash
• –allow-unrelated-histories
• -m<msg>
• –into-name<branch>
• -F<file>
• –rerere-autoupdate
• –overwrite-ignore
• –abort
  中止当前的冲突解决过程，并尝试重建合并前的状态。如果存在autostash条目，请将其应用于工作树。
• –quit
  舍弃当前正在进行的合并。保持暂存库和工作树不变。如果MERGE_AUTOSTASH存在，则存储条目将保存到存储列表(stash list)中。
  笔者注：舍弃的意义在于，即因为文件冲突产生了未提交的更改，如果进行修改 - git add - git commit，产生的节点也不会是合并节点，如果进行 修改 - git add -git merge --continue则会报错，因为没有中断的融合操作。
• –continue
  在git merge由于冲突而停止后，您可以通过运行git merge --continue来完成合并操作。笔者注：要先 修改 - git add
• <commit>…

3.14.4 快速合并

通常当前分支头是给定名称提交的祖先。这是最常见的情况，尤其是从 git pull 调用时：您正在跟踪上游存储库，您没有提交本地更改，现在您想更新到更新的上游版本。在这种情况下，不需要新的提交来存储组合的历史记录；相反，HEAD（连同暂存库）被更新为指向给定名称提交，而不会创建额外的合并提交。

可以使用--no-ff选项抑制此行为。

3.14.5 真正的合并

除了快速合并（见上文），要合并的分支必须由合并提交绑定在一起，该提交将它们两者都作为其父级。

提交一个协调所有要合并的分支的更改的合并版本，并且您的HEAD、暂存库和工作树都会更新到该版本。只要它们不重叠，就可以在工作树中进行修改；更新将保留它们。

当不清楚如何协调更改时，会发生以下情况：

1. HEAD指针保持不变。
2. MERGE_HEADref设置为指向另一个分支头。
3. 干净合并的路径会在暂存库文件和工作树中更新。
4. 对于冲突路径，暂存库文件最多记录三个版本：stage 1 存储来自公共祖先的版本，stage 2 存储来自HEAD，stage 3 存储来自MERGE_HEAD（您可以使用git ls-files -u检查阶段stage）。工作树文件包含合并操作的结果；即具有熟悉冲突标记的3路合并结果 <<< === >>>。
5. 写入一个特殊的ref AUTO_MERGE，指向与工作树当前内容相对应的树（包括针对文本冲突的冲突标记）。请注意，此ref仅在使用ort合并策略时写入（默认）。
6. 不会进行其他更改。特别是，您在开始合并之前进行的本地修改将保持不变，它们的暂存库条目保持不变，即匹配HEAD。

如果您尝试合并导致复杂的冲突并想要重新开始，您可以使用git merge --abort进行恢复。

3.14.6 如何解决冲突

看到冲突后，可以做两件事：

• 决定不合并。您需要的唯一清理是将暂存库文件重置为HEAD提交以反转2.并清理2.和3.所做的工作树更改；git merge --abort可用于此目的。
• 解决冲突。Git将在工作树中标记冲突。编辑文件并使用git add将它们添加到暂存库中。使用git commit或git merge --continue以完成合并。git merge --continue命令在调用git commit之前检查是否有（中断的）合并正在进行中。
  您可以使用多种工具解决冲突：
• 使用mergetool。git mergetool启动一个图形合并工具以帮助您进行合并的完整操作。
• 关注差异。git diff将显示一个三向差异，突出显示来自HEAD和MERGE_HEAD版本的更改。git diff AUTO_MERGE将显示到目前为止为解决文本冲突所做的更改。
• 查看每个分支的差异。git log --merg -p <path> 将首先显示HEAD版本的差异，然后显示MERGE_HEAD版本的差异。
• 查看原件。git show :1:filename显示共同祖先，git show :2:filename显示HEAD版本，git show :3:filename显示MERGE_HEAD版本。

3.16 log

3.16.1 简介

显示提交日志

3.16.2 语法

git log [<options>] [<revision-range>] [[--] <path>…​]

3.16.3 options

• -L<start>,<end>:<file>
  -L:<funcname>:<file>

3.16.4 提交的限制

• -<number>
  -n <number>
  –max-count=<number>
• –author=<pattern>
  –committer=<pattern>

3.16.5 提交的格式

• –pretty[=<format>]
  <format>可以是oneline, short, medium, full, fuller, reference, email, raw, format:<string> 和 tformat:<string>
• –abbrev-commit
• –graph

示例

建议使用 gitk 命令 以及 git log --graph

$ git log
or
$ git log --all --pretty=oneline --abbrev-commit --graph

1 $ git show f0d93848084e73193d2eb877b40bb1a232d4dbd4
2 $ git show HEAD # 当前分支的尖端/提示（我也不知道翻译成哪个好）
3 $ git show experimental # "experimental" 分支的尖端/提示

每个提交（commit）通常都有一个指向项目先前状态的“父”提交：

1 $ git show HEAD^ # to see the parent of HEAD
2 $ git show HEAD^^ # to see the grandparent of HEAD
3 $ git show HEAD~4 # to see the great-great grandparent of HEAD

合并提交（merge commit）可能有多个父级：

$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
$ git show HEAD^2 # show the second parent of HEAD

也可以给每次的提交（commit）命名，之后任何需要指向“提交”的Git命令都可以使用这些名称中的任何一个

$ git tag v2.5 1b2e1d63ff # 可以将1b2e1d63ff命名为v2.5
$ git diff v2.5 HEAD # compare the current HEAD to v2.5
$ git branch stable v2.5 # start a new branch named "stable" based # at v2.5
$ git reset --hard HEAD^ # 将当前分支和工作目录重置为“HEAD^”状态，小心使用

此外，不要在其他开发人员从中提取的公开可见分支上使用 git reset，因为这会迫使其他开发人员进行不必要的合并以清理历史。

$ git revert # 撤消已推送的更改

$ git grep "hello" v2.5 # 在v2.5中搜索所有出现的“hello”
$ git grep "hello" # 搜索当前目录中git管理的任何文件中出现的“hello”

搜索指定范围内的commit后的log

$ git log v2.5..v2.6 # commits between v2.5 and v2.6
$ git log v2.5.. # commits since v2.5
$ git log --since="2 weeks ago" # commits from the last 2 weeks
$ git log v2.5.. Makefile # commits since v2.5 which modify # Makefile

git log 命令有一个缺点：当提交多次后又融合回之前一个点时，该命令给出的list列表会显得没有意义

3.17 stash

3.17.1 介绍

git stash - 将修改贮藏在脏工作目录(dirty working directory)中。
使用情况：想保留已经进行了一部分的工作，但又不想将其提交，解决这个问题的办法就是 git stash 命令

大佬文章：git-stash用法小结

3.17.2 语法

$ git stash list [<log-options>]
$ git stash show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
$ git stash drop [-q | --quiet] [<stash>]
$ git stash pop [--index] [-q | --quiet] [<stash>]
$ git stash apply [--index] [-q | --quiet] [<stash>]
$ git stash branch <branchname> [<stash>]
$ git stash [ push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet] [-u | --include-untracked]
            [-a | --all] [(-m | --message) <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]]
            [--] [<pathspec>…​] ]
$ git stash save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
                 [-u | --include-untracked] [-a | --all] [<message>]
$ git stash clear
$ git stash create [<message>]
$ git stash store [(-m | --message) <message>] [-q | --quiet] <commit>

3.17.3 COMMANDS

• push
  将本地修改保存到一个新的存储条目中，并将它们回滚到HEAD（在工作树和索引中）。<message>部分是可选的，它提供了描述以及隐藏的状态。为了快速制作快照，可以省略“push”。在这种模式下，不允许使用无选项参数，这可以防止拼写错误的子命令生成不需要的隐藏条目（比如不允许使用 --staged 这种无参数的）。这方面的两个例外是 stash -p，它充当 stash push -p 和 pathspec元素 的别名，在双连字符 “–” 之后允许使用，以消除歧义。
• save
  此选项已被弃用，取而代之的是 git stash push。它与“隐藏推送”的不同之处在于，它不能采用路径规范。相反，所有非选项参数都连接在一起，形成隐藏消息。
• list
  列出当前拥有的存储条目。
• show
  将存储条目（stash entry）中记录的”内容修改“显示为存储内容（stashed contents）与首次创建存储条目时提交的内容之间的差异。默认情况下，该命令显示diffstat，但它将接受 git diff 已知的任何格式（例如，git stash show-p stash@｛1｝以补丁形式查看第二个最新条目）。如果没有提供＜diff-option＞，默认行为将由stash.showStat 和 stash.sowPatch配置变量给出。您也可以使用 stash.showIncludeUntracked 来设置默认情况下是否启用 --include untracked。|
• pop
  从存储列表(stash list)中删除单个存储状态，并将其应用于当前工作树状态之上，即执行 git stash push的反向操作。工作目录必须与暂存库(index)匹配。
  应用状态可能会因冲突而失败；在这种情况下，它不会从存储列表中删除。您需要手动解决冲突，然后手动调用 git stash drop。|
• apply
  和 pop 命令类似，但不会从存储列表(stash list)中删除状态。与pop命令不同之处在于，<stash> 可以是任何由stash push或stash create创建的看起来像提交(commit)的提交。|
• branch
  从最初创建<stash>的提交处，创建并签出（checkout）一个名为<branchname>的新分支，并将<stash>中记录的更改应用于新的工作树和索引。
  
  如果成功，并且<stash>是表单stash@｛<revision>｝的引用，则它将删除stash｝。
• clear
  删除所有存储条目（stash entries）。请注意，这些条目将被修剪，并且可能无法恢复。
• drop
  从存储条目列表中删除一个存储条目。
• create
  创建一个存储条目（它是一个常规的提交对象）并返回其对象名称，而不将其存储在 ref命名空间（ref namespace）中的任何位置。这对脚本(scripts)很有用
• store
  将通过 git stash create 创建的给定存储（这是一个悬挂的合并提交）存储在存储引用中，更新存储reflog。这对脚本非常有用。

3.17.4 OPTIONS

• -a
--all
  此选项仅对 push 和 save 命令有效。
  所有被忽略和未跟踪的文件也会被贮藏（stash）起来，然后用 git clean 进行清理。
• -u
--include-untracked
--no-include-untracked
  当使用 push 或 save 命令时，所有未跟踪的文件也会被贮藏起来，然后用 git clean 进行清理。
  与show命令一起使用时，将stash条目中未跟踪的文件显示为diff的一部分。
• --only-untracked
  此选项仅对 show 命令有效。
  仅显示stash条目中未跟踪的文件作为差异的一部分。
• --index
  此选项仅对 pop 和 apply 命令有效。
  尝试不仅恢复工作树的更改，还恢复暂存库中的更改。但是，当有冲突（这些冲突存储在暂存库中，因此您无法再像最初那样应用更改）时，这可能会失败。
• -k
--kep-index
--no-keep-index
  此选项仅对 push 和 save 命令有效。
  已添加到暂存库中的所有更改都保持不变。
• -P
--patch
  此选项仅对 push 和 save 命令有效。
  
  交互地从HEAD和要贮藏的工作树之间的差异中选择 块(hunks)。存储条目的构造使其暂存库状态与存储库(repository)的暂存库状态相同，并且其工作树仅包含交互式选择的更改(changes)。然后，所选更改将从工作树中回滚。请参阅git-add的“Interactive Mode”部分，了解如何操作 --patch 模式。
  
  当指定 --patch 时会默认指定 --keep-index，可以使用 --no-keep-index 来覆盖此项。|
• -S
--staged
  此选项仅对 push 和 save 命令有效。
  
  只保存当前正在进行的更改。这类似于基本的git commit，只是状态被提交到贮藏库(stash)而不是当前分支。
  
  –patch 选项的优先级高于此选项。|
• --pathspec-from-file=<file>
--pathspec-file-nul
  与前文效果一致
• -q
--quied
  略
• --
  此选项仅对 push 命令有效。其余与前文效果一致
• <pathspec>
  略
• <stash>
  此选项仅对 apply, branch, drop, pop, show命令有效。
  
  stash@{<revision>} 的引用。当没有给出<stash>时，假设是最新的 stash（即stash@{0}）。|

3.18 tag

3.18.1 语法

git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
    <tagname> [<commit> | <object>]
git tag -d <tagname>…​
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
    [--points-at <object>] [--column[=<options>] | --no-column]
    [--create-reflog] [--sort=<key>] [--format=<format>]
    [--merged <commit>] [--no-merged <commit>] [<pattern>…​]
git tag -v [--format=<format>] <tagname>…​

3.18.2 简介

除非指定 -d/-l/-v 来删除、列出或验证标记，否则使用 git tag 命令就是在 refs/tags/ 中添加标记引用(tag reference)。

除非指定 -f ，否则即将使用的标记名称一定还不存在。

如果传递了 -a、-s、-u<key id> 中的一个，则该命令创建标签对象(Tag objects)的同时，需要一条标记消息(tag message)。如果不给出 -m<msg>或 -F<file>，就会启动一个编辑器，供用户键入标记消息。但反过来，如果给定 -m<msg>或 -F<file>，但没有给出 -a、-s、-u<key id> 中的任意一个，则git会认为你想使用 -a 。

如果上述提到的<options>都没有给出的话，将创建直接指向给定对象的标记引用（即，轻量级标签，lightweight tag）。

当使用 -s 或 -u<key id> 时，将创建GnuPG签名的标记对象。如果不使用 -u<key id> ，则使用当前用户的提交者标识来查找用于签名的GnuPG密钥。配置变量gpg.program 用于指定自定义GnuPG二进制文件。

标签对象(Tag objects)（使用 -a、-s 或 -u 创建）称为“注释(annotated)”标记；它们包含创建日期、标记者的名称和电子邮件、标记消息以及可选的GnuPG签名。而轻量级标签(lightweight tag)只是一个对象（通常是一个提交对象）的名称。

注释标签用于发布，而轻量级标签用于私有或临时对象标签。出于这个原因，一些用于命名对象的git命令（如git-descripte）默认情况下会忽略轻量级标记。

3.18.3 OPTIONS

• -a
--annotate
  生成一个未签名、带注释的标签对象
• -s
--sign
  使用默认电子邮件地址的密钥制作一个GPG签名的标签。如果配置变量 tag.gpgSign 存在，则标签GPG签名的默认行为由它控制（如果存在），否则禁用。详见 git-config
• --no-sign
  覆盖 tag.gpgSign 配置变量，该变量设置为强制对每个标签进行签名。
• -u <key-id>
--local-user=<key-id>
  使用给定的密钥制作一个GPG签名的标签
• -f
--force
  强制用给定的名称替换现有标记（不会失败）
• -d
--delete
  删除具有给定名称的现有标记
• -v
--verify
  验证给定标签名称的GPG签名
• -n<num>
＜num＞指定在使用 -l 时打印注释(annotation)中的行数（如果有的话）。-l 即 --list。
  默认情况下不打印任何注释行。如果指定 -n 而又没有指定数字，则只打印第一行。如果标记没有注释，则会显示提交消息(commit message)。
• -l
--list
  列出标签。
  如果使用可选的<pattern>，例如 git tag --list ‘v-*’，则只列出与<pattern>匹配的标签。
  运行不带参数的“git-tag”也会列出所有标记。该模式是shell通配符（即，使用fnmatch(3)进行匹配）。可以给出多个<pattern>；如果其中任何一个匹配，则会显示标记。
  如果提供了任何其他类似列表的选项（如 --contains），则会隐式提供此选项。有关详细信息，请参阅每个选项的文档。
• --sort=<key>
  根据给定的键<key>进行排序。前缀 - 表示按值的降序排序。您可以多次使用 --sort=<key>选项，在这种情况下，最后一个键将成为主键(primary key)。还支持 “version:refname” 或 “v:refname” (标记名称被视为version)。“version:refname” 排序顺序也会受到 versionsort.suffix 配置变量的影响。支持的键与git for-each-ref中的键相同。排序顺序默认为标签配置的值。如果存在，则排序变量; 否则为字典顺序。
• --color[=<when>]
  首选 --format选项中指定的任何颜色。<when>字段必须是always，never，auto中的一个 (如果 <when> 是不存在的，则按照 always 执行)。
• -i
--ignore-case
  排序和筛选标记不区分大小写
• --omit-empty
  不要在格式化的refs之后打印换行符，因为格式化的refs的格式扩展为空字符串。
• --column[=<options>]
--no-column
  在列中显示标记列表。有关选项语法，请参阅配置变量column.tag。没有选项的 – column和 – no-column分别等同于always和never。
• --contains [<commit>]
  仅列出包含指定提交的标记（如果未指定，则为HEAD）。该options会默认使用 -l/–list
• --no-contains [<commit>]
  仅列出不包含指定提交的标记（如果未指定，则为HEAD）。该options会默认使用 -l/–list
• --merged [<commit>]
  仅列出可从指定的提交访问的提交的标签（如果未指定，则为HEAD）。
• --no-merged [<commit>]
  仅列出不可从指定的提交访问的提交的标签（如果未指定，则为HEAD）。
• --points-at <object>
  仅列出给定对象的标记（如果未指定HEAD）。该options会默认使用 -l/–list
• -m <msg>
--message=<msg>
  使用给定的标签消息（而不是题词(prompting)）。如果给定了多个-m选项，则它们的值将连接为单独的段落。如果没有给定-a、-s或-u＜key id＞，则隐含-a。
• -F <file>
--file=<file>
  从给定的文件中获取标签消息。使用 - 从标准输入中读取消息。如果没有给定-a、-s或-u<key id>，则隐含-a。
• -e
--edit
  从带有 -F 的文件和带有 -m 的命令行获取的消息通常用作未修改的标签消息。此选项允许您进一步编辑从这些来源获取的消息。
• --cleanup=<mode>
  此选项设置如何清理标记消息。<mode>可以是verbatim(逐字)、whitespace(空白)和strip(条形)中的一种。条形图模式为默认模式。逐字模式根本不会更改消息，空白只删除前导/尾随空白行，strip同时删除空白和注释(commentary)。|
• --create-reflog
  为标签创建reflog。要全局启用标签的reflog，请参阅git-config中的core.logAllRefUpdates。否定的形式 --no-create-relog 只覆盖早期的 --create-relog，但不否定现在的 core.logAllRefUpdates 的设置。
• --format=<format>
  从显示的标记ref插入 %(fieldname) 的字符串及其指向的对象。格式与git-for-each-ref 的格式相同。如果未指定，则默认为 %(refname:strip=2)。

<tagname>
要创建、删除或描述的标签的名称。新标签名称必须通过 git-check-ref-format 定义的所有检查。其中一些检查可能会限制标签名称中允许的字符。

<commit>

<object>

新标签(new tag)将引用(will refer to)的对象(object)，通常是提交(commit)。默认为HEAD。

3.18.4 CONFIGURATION

默认情况下，默认签名模式 (-s) 中的 git标签 将使用您的提交者身份 (形式为 Your Name <your@email.address> ) 来查找密钥。如果要使用其他默认密钥，可以在存储库配置中指定它，如下所示：

[user]
signingKey = <gpg-key_id>

仅当以列表形式展示标签时（即当使用或暗示使用 -l 时），才考虑 pager.tag。默认情况下使用pager。请参见git-config。

3.19 worktree

暂略

3.20 fetch

fetch操作的定义：从另一个存储库下载对象和引用（原文：git-fetch - Download objects and refs from another repository）。

fetch操作会获取分支(branch)、标签(tags)（branch和 tags统称为引用，即"refs"）、和历史记录相关的对象(objects)，获取到的branch、tags、objects被存入 .git/FETCH_HEAD

**3.20.1 语法**

```bash
1 $ git fetch [<options>] [<repository> [<refspec>…​]]
2 $ git fetch [<options>] <group>
3 $ git fetch --multiple [<options>] [(<repository> | <group>)…​]
4 $ git fetch --all [<options>]

3.20.2 options

• –all
  获取全部远程仓库
• -a
  –append
  将ref names和object names附加到 ".git/FETCH_HEAD"的已有内容中。如果不使用该命令，原已有内容会被覆盖
• –atomic
  使用原子事务来更新本地引用。要么更新了所有引用，要么出现错误，不更新任何引用。
• –depth=<depth>
  将从每个远程分支历史记录(remote branch history)的尖端(tips)提取(fetch)限制为指定的提交数(commits)。
  如果提取到使用 --depth=<depth> 选项的git clone创建的浅层存储库 (请参阅git-clone)，则将历史记录加深或缩短为指定的提交数。未获取加深提交的标签。
• –deepen=<depth>
  指定从当前浅边界的提交的数量，而不是从每个远程分支历史记录的尖端提交的数量
• –shallow-since=<date>
  加深或缩短浅存储库的历史记录，以包括 <date> 之后的所有可访问提交。
• –shallow-exclude=<revision>
  加深或缩短浅存储库的历史记录，以排除从指定的远程分支或标记可访问的提交。可以多次指定此选项。
• –unshallow
  如果源存储库已完成，则将浅存储库转换为完整存储库，从而消除浅存储库施加的所有限制。
  如果源存储库较浅，请尽可能多地获取，以使当前存储库具有与源存储库相同的历史记录。
• –update-shallow
  默认情况下，当从浅层存储库中提取时，git fetch拒绝需要更新的refs。git/shallow此选项更新。git/浅并接受这样的参考。
• –negotiation-tip=<commit|glob>
  默认情况下，Git将向服务器报告所有本地refs可访问的提交，以查找公共提交，以尝试减小要接收的packfile的大小。如果指定，Git将仅报告从给定提示可到达的提交。当用户知道哪个本地ref可能具有与被提取的上游ref共同的提交时，这对于加速提取是有用的。
  
  可以多次指定此选项; 如果是这样，Git将报告可从任何给定提交中访问的提交。
  
  此选项的参数可以是参考名称上的glob、参考或提交的 (可能缩写) SHA-1。指定一个glob相当于多次指定这个选项，每个匹配的ref名称一个。
  
  另请参阅git-config中记录的fetch.Negotionationalgorithm和push.Negotil配置变量，以及下面的 – negotil-only选项。
• –negotiate-only
  不要从服务器获取任何内容，而是打印提供的 – negotifation-tip = * 参数的祖先，这是我们与服务器的共同点。
  
  这与 – recurse-submodules = [是 | 按需] 不兼容。内部这是用来实现push.negotiate选项的，参见git-config。
• –dry-run
  显示将要做的事情，而不进行任何更改。
• –porcelain
  以易于解析的格式将输出打印到脚本的标准输出。有关详细信息，请参见git-fetch中的输出部分。
  
  这与 – recurse-submodules = [是 | 按需] 不兼容，并且优先于fetch.output config选项。
• –[no-]write-fetch-head
  直接在 $GIT_DIR下的FETCH_HEAD文件中写入获取的远程refs列表。这是默认的。从命令行传递 --no-write-fetch-head告诉Git不要写入文件。在 --dry-run选项下，永远不会写入文件。
• -f
  –force
  当git fetch与 <src>:< dst> refspec一起使用时，它可能会拒绝更新本地分支，如下面的 <refspec> 部分所述。此选项覆盖该检查。
• -k
  –keep
  保留下载包
• –multiple
  允许指定几个 <repository> 和 <group> 参数。可能没有指定 <refspec>。
• –[no-]auto-maintenance
  –[no-]auto-gc
  最后运行git维护Run --auto，以便在需要时执行自动存储库维护。(–[no-]auto-gc是同义词。)默认情况下，这是启用的。
• –[no-]write-commit-graph|获取后写一个提交图。这将覆盖配置设置fetch.Writecompmitgraph。|
• –prefetch|修改配置的refspec，将所有refs放入refs/预取/命名空间。参见git-maintenance[1] 中的预取任务。|
• -p
  –prune
  在获取之前，请删除远程仓库上不再存在的所有远程跟踪引用。如果仅由于默认标签自动跟随或由于 --Tags选项而提取标签，则不会进行修剪。但是，如果由于显式的refspec (在命令行或远程配置中，例如，如果使用 – mirror选项克隆了远程) 而提取了标签，则它们也将受到修剪的影响。提供-修剪标签是提供标签refspec的简写。
  
  有关更多详细信息，请参见下面的修剪（PRUNING）部分。
• -P
  –prune-tags
  在获取之前，如果启用了 --prune，请删除遥控器上不再存在的任何本地标签。这个选项应该更仔细地使用，不像 --prune它会删除任何已经创建的本地引用 (本地标记)。此选项是提供显式标记refspec以及-prune的简写，请参阅其文档中的讨论。
  
  有关更多详细信息，请参见下面的修剪部分。
• -n
  –no-tags
  默认情况下，指向从远程存储库下载的对象的标签将被获取并存储在本地。此选项禁用此自动标记跟随。远程仓库的默认行为可以用remote指定。<name>.tagOpt设置。请参阅git-config。
• –refetch
  此选项无需与服务器协商以避免转移本地已经存在的提交和关联对象，而是将所有对象作为新克隆获取。使用它可以从配置中重新应用部分克隆过滤器，或者在过滤器定义更改时使用 --filter=。自动获取后维护将执行对象数据库包整合，以删除任何重复的对象。
• –refmap=<refspec>
  从远程获取所有标签 (即，将远程标签refs/tags/* 提取到具有相同名称的本地标签中)，除此之外，还可以获取其他任何标签。即使使用-prune，单独使用此选项也不会对标签进行修剪 (尽管如果标签也是显式refspec的目的地，则无论如何都可以修剪标签; 请参阅-prune)。
• -t
  –tags
  从远程获取所有标签 (即，将远程标签refs/tags/* 提取到具有相同名称的本地标签中)，除此之外，还可以获取其他任何标签。即使使用-prune，单独使用此选项也不会对标签进行修剪 (尽管如果标签也是显式refspec的目的地，则无论如何都可以修剪标签; 请参阅-prune)。
• –recurse-submodules[=yes|on-demand|no]
  此选项控制是否以及在什么条件下也应获取新的子模块提交。通过子模块递归时，git fetch总是尝试获取 “更改” 的子模块，即具有由新获取的超级项目提交引用但在本地子模块克隆中丢失的提交的子模块。更改后的子模块可以被获取，只要它在本地存在，例如在 $ GIT_DIR/modules/ (请参见gitsubmodules[7]); 如果上游添加了一个新的子模块，则该子模块无法获取，直到它被克隆，例如git子模块更新。
  
  设置为按需时，仅获取更改的子模块。设置为 “是” 时，将获取所有填充的子模块，并获取未填充和更改的子模块。设置为 “否” 时，永远不会获取子模块。
  
  如果未指定，则使用fetch.recurseSubmodules的值 (请参阅git-config[1])，如果未设置，则默认为按需。当此选项在没有任何值的情况下使用时，它默认为是。|
• -j
  –jobs=<n>
  用于所有形式的获取的并行子级的数量。
  
  如果指定了 – multiple选项，则将并行获取不同的遥控器。如果多个子模块被提取，它们将被并行提取。要独立控制它们，请使用config设置fetch.parallel和submodule.fetchJobs (请参阅git-config)。
  
  通常，并行递归和多远程获取会更快。默认情况下，提取是按顺序执行的，而不是并行执行的。
• –no-recurse-submodules
  禁用子模块的递归提取 (这与使用 – recurse-submodules = no选项具有相同的效果)。
• –set-upstream
  如果远程成功获取，则添加上游 (跟踪) 引用，由无参数git-pull和其他命令使用。有关更多信息，请参见git-config中的branch.<name>.merge和branch.<name>.remote。
• –submodule-prefix=<path>
  将<path>前置到信息消息中打印的路径，如“Fetching submodule foo”。此选项在子模块上递归时在内部使用。
• –recurse-submodules-default=[yes|on-demand]|此选项在内部用于临时为 – recurse-submodules选项提供非负默认值。配置fetch子模块递归的所有其他方法 (例如gitmodules和git-config中的设置) 都覆盖此选项，就像直接指定-[no-]递归子模块一样。
• -u
  –update-head-ok
  默认情况下，“git fetch” 拒绝更新与当前分支相对应的头部(head)。该标志禁用该项检查。这纯粹是为了内部使用 “git pull” 与 “git fetch” 进行通信，除非您正在实现自己的"Porcelain"，否则您不应该使用它。
• –upload-pack <upload-pack><br>当给定，并且要从中提取的存储库由git fetch-pack处理时，-- exec=<upload-pack> 传递给命令，为在另一端运行的命令指定非默认路径。
• -q
  –quiet
  将 – quiet传递到git-fetch-pack，并使任何其他内部使用的git命令静音。进度不会报告给标准错误流。
• -v
  –verbose
  输出更信息的信息
• –progress
  除非指定了-q，否则默认情况下，当标准错误流附加到终端时，会在标准错误流上报告进度状态。即使标准错误流未定向到终端，此标志也会强制执行进度状态。
• -o <option>
  –server-option=<option>
  使用协议版本2进行通信时，将给定的字符串传输到服务器。给定的字符串不得包含NUL或LF字符。服务器对服务器选项 (包括未知选项) 的处理是特定于服务器的。当给出多个 – server-option =<option> 时，它们都按照命令行上列出的顺序发送到另一侧。
• –show-forced-updates<br>
  默认情况下，git会检查在获取期间是否强制更新了分支。可以通过fetch.showForcedUpdates禁用此功能，但是 --show-forded-updates选项可以保证此检查的发生。参见 git-config.
• –no-show-forced-updates
  禁用是否强制更新了分支的检查
• -4
  –ipv4
  仅使用IPv4地址
• -6
  –ipv6
  仅使用IPv6地址

<repository>

远程仓库是获取(fetch)或者拉取(pull)的源头，此参数既可以是URL链接(see the section GIT URLS )也可以是远程仓库(see the section REMOTES)的名字

<group>

包含远程仓库名的一个列表，在配置文件中配置(See git-config[1]).

<refspec>

指明哪一条 refs （再次重申，branch和 tags统称为引用，即"refs"）要获取以及哪一条本地的refs要被更新。当命令中不出现<refspec>时，会读取 remote.<repository>.fetch 中设置的 refs(see CONFIGURED REMOTE-TRACKING BRANCHES ）

上述链接的细节内容，建议有空看看git官网中的描述。

3.21 pull

3.21.1 语法

$ git pull [<options>] [<repository> [<refspec>…​]]
$ git pull <远程主机名> <远程分支名>:<本地分支名>

3.21.2 简介

将远程存储库中的更改合并到当前分支中。如果当前分支位于远程之后，则默认情况下，它将快进当前分支以匹配远程。如果当前分支和远程已经分叉(diverged)，则用户需要指定如何使用 --rebase 或 --no-rebase (或相应的配置选项 pull.rebase )。

更准确地说，git pull 使用给定的参数运行 git fetch，然后根据配置选项或命令行标志，将调用 git rebase 或 git merge 来协调不同的分支。

<repository> 应该是传递给 git-fetch 的远程存储库的名称。<refspec> 可以命名任意远程ref (例如，标记的名称)，甚至可以命名具有相应远程跟踪分支的ref集合 (e.g., refs/heads/*:refs/remotes/origin/*)，但通常它是远程存储库中一个分支的名称。

<repository> 和 <branch> 的默认值是从 git-branch --track 设置的当前分支的 “remote” 和 “merge” 配置中读取的。

3.21.3 OPTIONS

• -q
  –quiet
  这被传递到底层 git fetch 和 git merge 命令，以禁止输出本来在传输或融合过程中会产生的报告
• -v
  –verbos
  将 --verbose 传递给 git fetch 和 git merge
• –[no-]recurse-submodules[=yes|on-demand|no]
  略

和 合并(merging) 相关的 options

• –commit
  –no-commit
  执行合并(merge)并提交(commit)结果。此选项可用于覆盖 --no-commit。仅在合并时有用。
  使用 --no-commit 则会执行合并(merge)，并在创建合并提交(merge commit)之前停止，以使用户有机会在提交之前检查并进一步调整合并结果。
  请注意，快进更新(fast-forward updates)不会创建合并提交，因此无法使用 --no-commit 停止这些合并。因此，如果要确保合并命令不会更改或更新分支，请使用 --no-ff 和 --no-commit。
• –edit
  -e
  –no-edit
  在提交成功的呆板合并之前调用编辑器以进一步编辑自动生成的合并消息，以便用户可以解释和证明合并。–no-edit 选项可用于接受自动生成的消息 (通常不建议这样做)。
  
  旧脚本可能依赖于不允许用户编辑合并日志消息的历史行为。当他们运行 git merge 时，他们会看到一个编辑器打开。为了更容易地将这些脚本调整为更新后的行为，可以在它们的开头将环境变量 GIT_MERGE_AUTOEDIT 设置为 no。
• –cleanup=<mode>
  此选项决定提交前如何清理合并消息。更多细节请参见 git-commit 。此外，如果 <mode> 被赋值 scissors ，在合并冲突的情况下，scissors 将被附加到 MERGE_MSG 上，然后再传递给提交机制。
• –ff-only
  如果没有不同的本地历史记录，则仅更新到新的历史记录。当没有提供协调分歧历史记录的方法时，这是默认设置 (通过 --rebase=* flags )。
• –ff
  –no-ff
  当进行合并而不是重新设置基线(rebase)时，指定当并入的历史已经是当前历史的后代时如何处理合并。如果请求合并，则默认使用 --ff，除非合并的注释的(annotated)（可能已签名）标记(tag)未存储在 refs/tags/ 层次结构的自然位置，在这种情况下，将使用 --no-ff。
  使用 --ff，如果可能，将合并作为快进来解决(fast-forward)（仅更新分支指针以匹配合并的分支；不创建合并提交(merge commit) ）。如果不可能（合并的历史记录不是当前历史记录的后代），则创建合并提交。
  使用 --no-ff，在所有情况下都创建合并提交，即使合并可以作为快进解决。
• -S[<keyid>]
  –gpg-sign[=<keyid>]
  –no-gpg-sign
  略
• –log[=<n>]
  –no-log
  略
• –signoff
  –no-signoff
  略
• –stat
  -n
  –no-stat
  略在合并结束时显示 diffstat。diffstat 同样受配置选项 merge.stat 控制。
  使用 -n 或 --no-stat 选项，在合并结束时不显示 diffstat。
• –squash
  –no-squash
  略
• –[no-]verify
• -s <strategy>
  –strategy=<strategy>
  略
• -X <option>
  –strategy-option<option>
  略
• –verify-signatures
  –no-verify-signatures
  略
• –summary
  –no-summary
  略
• –autostash
  –no-autostash
  略
• –allow-unrelated-histories
  略
• -r
  –rebase[=false|true|merges|interactive]
  略
• –no-rebase
  这是 --rebase=false 的简写。

和 获取(fetching) 有关的 options

• –all
  获取(fetch)所有远程仓库（有疑问的是，这并不能拉取所有远程分支）
• -a
  –append
  将获取的引用名称和对象名称附加到的现有内容。git/FETCH_HEAD。中没有此选项的旧数据。git/FETCH_HEAD将被覆盖。
• –atomic
  
• –depth=<depth>
  略
• –deepen=<depth>
  略
• –shallow-since=<date>
  略
• –shallow-exclude=<revision>
  
• –unshallow
  略
• –update-shallow
  略
• –negotiation-tip=<commit|glob>
  略
• –negotiate-only
  略
• –dry-run
  略
• –porcelain
  略
• -f
  –force
  略
• -k
  –keep
  略
• –prefetch
  略
• -p
  –prune
  在获取之前，请删除远程上不再存在的任何远程跟踪引用(remote-tracking references)。如果仅由于默认标记自动跟随或由于 --tags 选项而获取标记，则标记不会被修剪。但是，如果由于显式refspec (在命令行上或在远程配置中，例如，如果远程是使用 --mirror 选项克隆的) 而获取标记，则它们也会受到修剪。提供 --prune-tags 是提供标签 refspec的简写。
• –no-tags
  略
• –refmap=<refspec>
  略
• -t
  –tags
  略
• -j
  –jobs=<n>
  略
• –set-upstream
  略
• –upload-pack <upload-pack>
  略
• –progress
  略
• -o <option>
  –server-option=<option>
  略
• –show-forced-updates
  略
• –no-show-forced-updates
  略
• -4–ipv4
  略
• -6–ipv6
  略

3.22 push

3.22.1 简介

更新远程仓库中的引用(refs)和相关联的对象。
使用本地引用更新远程引用，同时发送完成给定引用所需的对象。
通过在存储库中设置挂钩，您可以在每次推入存储库时使其发生有趣的事情。请参阅 git-receive-pack 文档。
当命令行没有使用<repository>参数指定推送位置时，将咨询当前分支的 branch.*.remote 配置以确定推送位置。如果缺少配置，则默认为 origin。

笔者注：*号在这里代指master等内容，实际使用时并不是填*符号就可以了。比如可以执行命令：$ git config --local branch.master.remote，使用命令$ git config [--local | --global] -l也能看到一些别的设置选项，用于加深理解，更详细内容参阅git-config。

当命令行没有指定用<refspec>...参数或--all、--mirror、--tags选项推送什么时，该命令通过查阅 remote.*.push 配置来找到默认的<refspec>，如果找不到，则使用 push.default 配置来决定要推送什么（有关push.default的含义，请参阅git-config）。

当命令行和配置都没有指定推送内容时，将使用默认行为，该行为对应于push.default的简单值：当前分支被推送到相应的上游分支，但作为安全措施，如果上游分支与本地分支的名称不相同，则推送将中止。

3.22.2 语法

git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
	   [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
	   [-u | --set-upstream] [-o <string> | --push-option=<string>]
	   [--[no-]signed|--signed=(true|false|if-asked)]
	   [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
	   [--no-verify] [<repository> [<refspec>…​]]

3.22.3 OPTIONS

• –all
  –branches
  推送所有分支（即refs/heads/下的refs）；不能与其他<refspec>一起使用。
• –prune
  删除没有在本地对应分支的远程分支。例如，如果本地分支中不再存在名称为tmp的分支，则远程分支tmp将被删除。该动作同样遵守refspecs（refspec是一种规则，在本文的第2节中描述过），例如git push--prune remote refs/heads/*：refs/tmp/*将确保在refs/heads/soo不存在的情况下删除远程refs/tmp/foo。
• –mirror
  指定 refs/（包括但不限于refs/heads/、refs/remotes/和refs/tags/）下的所有ref都镜像到远程存储库，而不是命名每个要推送的ref。新创建的本地引用将被推送到远程端，本地更新的引用将在远程端强制更新，删除的引用将从远程端删除。如果配置选项 remote.<remote>.mirror 被置1，则–mirror是默认的options
• -n
  –dry-run
  在使用其它option时可使用[-n|–dry-run]，用途是会执行其它option指定的操作但不发送更新到远程仓库。
• –porcelain
  产生机器可读的输出。每个ref的输出状态行将以制表符分隔，并发送到stdout而不是stderr。将给出refs的完整符号名称（symbolic names）。
• -d
  –delete
  所有列出的引用都将从远程存储库中删除。这与在所有引用前面加一个冒号(colon)是一样的。
• –tags
  除了命令行上明确列出的refspec之外，refs/tags下的所有refs也都被推送。（可以理解为指定加过标签的refspec都会被推送）
• –follow-tags
  不仅推送不指定此选项的情况下会被推送的所有refs，还推送refs/tags中的注释标记(annotated tags)，这些标记在远程仓库中丢失、但指向可从被推送refs访问的commit ish。这也可以用配置变量 push.followTags 指定。有关更多信息，请参阅git-config中的push.follwTags。
• –[no-]signed
  –signed=(true|false|if-asked)
  略
• –[no-]atomic
  略
• -o <option>
  –push-option=<option>
  将给定的字符串传输到服务器，服务器将它们传递到预接收和后接收挂钩(hook)。给定的字符串不能包含NUL或LF字符(NUL代表空；LF, Line Feed，表示换行)。当给出多个--push option=<option>时，它们都会按照命令行上列出的顺序发送到另一侧。当命令行中没有给出--push option=<option>时，将使用配置变量push.pushOption的值。
• –receive-pack=<git-receive-pack>
  –exec=<git-receive-pack>
  略
• –[no-]force-with-lease
  –force-with-lease=<refname>
  –force-with-lease=<refname>:<expect>
  略
• -f
  –force
  通常情况下，push命令会拒绝更新一个不属于用来覆盖它的本地引用祖先的远程引用。 另外，当使用 --force-with-lease 选项时，命令会拒绝更新一个当前值与预期不符的远程引用。
  这个标志禁用了这些检查，并可能导致远程版本库丢失提交，使用时要小心。
  注意，--force 适用于所有被推送的引用，因此在 push.default 设置为 matching 的情况下使用它，或者在 remote.*.push 配置了多个推送目的地的情况下，可能会覆盖当前分支以外的引用（包括严格落后于其远程对应的本地引用）。 要强制推送到一个分支，请在推送的引用规范前面使用+（例如 git push origin +master，强制推送到 master 分支） 。详情见上面的 <refspec>... 部分。
• –[no-]force-if-includes
  仅当远程跟踪引用的提示已在本地集成时才强制更新。
• –repo=<repository>
  此选项相当于<repository>参数。如果同时指定了两者，则命令行参数优先。
• -u
  –set-upstream
  对于每个最新或成功推送的分支，添加上游（跟踪）引用，由无参数的git-pull和其他命令使用。有关详细信息，请参见在git-config中branch.<name>.merge。
• –[no-]thin
• -q
  –quiet
  略
• -v
  –verbose
  略
• –progress
  略
• –no-recurse-submodules
  –recurse-submodules=check|on-demand|only|no
  略
• –[no-]verify
• -4
  –ipv4
  略
• -6
  –ipv6
  略

3.23 remote

3.23.1 简介

管理您跟踪其分支的一组存储库 (“remote”)，即管理远程仓库。

3.23.2 语法

git remote [-v | --verbose]
git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=(fetch|push)] <name> <URL>
git remote rename [--[no-]progress] <old> <new>
git remote remove <name>
git remote set-head <name> (-a | --auto | -d | --delete | <branch>)
git remote set-branches [--add] <name> <branch>…​
git remote get-url [--push] [--all] <name>
git remote set-url [--push] <name> <newurl> [<oldurl>]
git remote set-url --add [--push] <name> <newurl>
git remote set-url --delete [--push] <name> <URL>
git remote [-v | --verbose] show [-n] <name>…​
git remote prune [-n | --dry-run] <name>…​
git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…​]

3.23.3 OPTIONS

get-url

• -v
  –verbose
  使得输出更详细一点，会在名称后显示远程url。对于promisor remote，还显示配置了哪个过滤器 (blob:none等)。注意: 这必须放在远程和子命令之间。
  例如，仅输入 git remote 则一般会显示 origin (一般来说远程仓库的名字就是这个)。但使用 git remote -v 则会显示：

origin git://git.kernel.org/pub/scm/git/git.git (fetch)
origin git://git.kernel.org/pub/scm/git/git.git (push)

add相关
为位于 <URL> 的存储库添加一个名为 <name> 的远程仓库(remote)。然后可以使用命令 git fetch <name> 来创建和更新远程跟踪分支 <name>/<branch>。
命令：$ git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=(fetch\|push)] <name> <URL>|

• -t <branch>
  将创建一个只跟踪＜branch>的 refspec，而不是用于远程的跟踪 refs/remotes/<name>/ 命名空间下所有分支的默认 glob refspec。您可以指定多个 -t <branch> 来跟踪多个分支，而无需抓取(grabbing)所有分支。
• -m <master>|使用 -m <master> 选项，符号 ref refs/remotes/<name>/HEAD 被设置为指向 remote 的 <master> 分支。另请参见 set head 命令。
• -f
  在设置远程信息后立即运行 git fetch <name>。
• –tags
  配合 -f 使用，git fetch <name> 从远程存储库(remote repository)导入每个标签(tag)。默认情况下，仅导入获取的分支上的标签，详见 git fetch
• –no-tags
  配合 -f 使用，git fetch <name> 不从远程存储库(remote repository)导入标签。
• –mirror=fetch
  略
• –mirror=push
  略

rename 将名为 <old> 的远程仓库重命名为 <new>。将更新远程仓库的所有远程跟踪分支和配置设置.
如果 <old> 和 <new> 相同，并且 <old> 是 $ GIT_DIR/remotes或 $ GIT_DIR/branches下的文件，那么远程仓库将被转换为配置文件格式。
命令：$ git remote rename [--[no-]progress] <old> <new>

remove
rm
删除名为 <name> 的远程仓库。将删除远程仓库的所有远程跟踪分支和配置设置。
命令：$ git remote remove <name>

set-head
设置或删除远程仓库默认分支 (即 symbolic-ref refs/remotes/<name>/HEAD 的目标）。不需要为远程设置默认分支，但可以指定远程的名称来代替特定的分支。例如，如果将 origin 的默认分支设置为 master，则可以在指定 origin/master 的任何位置使用指定 origin 来替代。
命令：$ git remote set-head <name> (-a | --auto | -d | --delete | <branch>)

• -d
  –delete
  symbolic ref refs/remotes/<name>/HEAD 会被删除
• -a
  –auto
  使用-a或–auto，将查询远程仓库以确定其 HEAD，然后将symbolic ref refs/remotes/<name>/HEAD设置为此分支。例如，如果远程 HEAD 指向next，git remote set HEAD origin-a 将把symbolic ref refs/remotes/origin/HEAD 设置为 refs/remotes/origin/next。只有当refs/remotes/origin/next已经存在时，这才会起作用；否则，必须先提取(fetch)。
• <branch>
  使用 <branch> 显式(明确地)设置symbolic ref refs/remotes/<name>/HEAD。例如，git remote set head origin master 将symbolic ref refs/remotes/origin/head 设置为 refs/remotes/origin/master。只有在 refs/remotes/origin/master 已经存在的情况下，这才会起作用；否则，必须先提取。

set-branches
更改由指定的远程仓库跟踪的分支列表。这可用于在远程仓库的初始设置之后跟踪可用远程分支的子集。
命名的分支将被解释为使用git远程添加命令行上的 -t 选项指定的分支。（注 -t 在上面add的部分解释了）
命令：$ git remote set-branches [--add] <name> <branch>…

• -add
  将分支添加到该列表，而不是替换当前跟踪的分支的列表。

get-url
检索远程的url。insteadOf 和 pushInsteadOf 的配置在此处展开。默认情况下，仅列出第一个URL。
命令：$ git remote get-url [--push] [--all] <name>

• –push
  查询 push url 而不是 fetch url（在这里 push 和 fetch 是名词含义）
• –all
  将列出远程仓库的所有url（默认情况下 git remote 也是这个效果）

sel-url
更改远程仓库的 url。将与正则表达式 <oldurl> 匹配的远程仓库 <name> 的第一个URL (如果未给出 <oldurl>，则为第一个URL) 设置为 <newurl>。如果 <oldurl> 不 匹配任何URL，则会发生错误，并且不会更改任何内容。
请注意，push URL和 fetch URL，即使它们可以设置为不同的内容，但必须指向相同的位置。推送到 push URL 的内容应该是从fetch URL中获取的内容。如果您试图从一个地方 (例如您的上游) 获取并推送到另一个地方 (例如您的发布存储库)，请使用两个单独的远程仓库。
命令：

$ git remote set-url [--push] <name> <newurl> [<oldurl>]<br>
$ git remote set-url --add [--push] <name> <newurl><br>
$ git remote set-url --delete [--push] <name> <URL>

• –push
  操作 push url 而不是fetch url。
• –add
  添加新的URL，而不是改变现有的URL
• –delete
  删除远程仓库 <name> 中与正则表达式 <URL> 匹配的所有URL。尝试删除所有非 push url 是错误的。

show
输出有关远程仓库 <name> 的一些信息。
命令：$ git remote [-v \| --verbose] show [-n] <name>…

• -n
  使用 -n 选项，不会首先使用 git ls-remote <name> 查询远程头; 而是使用缓存的信息。

prune
删除与 <name> 关联的过时引用(references)。默认情况下，删除 <name> 下的过时远程跟踪分支，但是，根据全局配置和远程配置，我们甚至可以修剪没有被推送的本地标签。与 git fetch -- prune <name> 唯一不同在于此命令不会获取新的引用(references)。
参阅 git-fetch 的 PRUNING部分，了解它将根据各种配置进行何种修剪。
命令：$ git remote prune [-n \| --dry-run] <name>…​

• –dry-run
  报告要修剪的树枝，但不要实际修剪。

update
获取存储库中由 remotes.<group> 定义的远程仓库或远程组的更新。如果在命令行上既没有指定 group 也没有指定 remote，则将使用配置参数 remotes.default；如果未定义remotes.default，则所有 配置参数 remote的remote<name>.skipDefaultUpdate 没有被设置为true的远程仓库将被更新。（请参阅git-config）。
命令：$ git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…​]

• –prune
  对所有更新的远程设备运行修剪。

3.24 submodule

3.33 cherry-pick

3.33.1 简介

应用某些现有提交所引入的更改。
给定一个或多个已存在的commit，应用这些commit引入的change，并将其每一个都记录为一个新的commit。
当如何应用一个变化不明显时，会发生以下情况：

1. 当前的分支和 HEAD 指针均指向最后一次成功提交的位置。
2. CHERRY_PICK_HEAD 引用被设置为指向引入难以应用的修改的那个提交。
3. 在暂存区(index)文件和工作区中，更改应用得很干净的路径都被更新。
4. 对于冲突的路径，暂存区文件最多记录三个版本，如git-merge的“TRUE MERGE”部分所述。工作树文件将包括一个有关冲突的描述，此描述用通常的冲突标记符<<<<<<< 和 >>>>>>>括起来
5. 不做其他修改。

有关解决此类冲突的一些提示，请参阅git-merge。

3.33.2 语法

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

3.33.3 options

• <commit>
• -e
  –edit
  使用此选项，gitcherry-pick 将允许您在提交之前编辑commit message。
• –cleanup=<mode>
  此选项确定提交消息在传递到提交机制之前将如何清理。有关更多详细信息，请参阅git-commit --cleanip=<mode>。特别是，如果<mode>的值为scissors，则在发生冲突时，将在传递之前修剪(scissor)MERGE_MSG。
• -x
  在记录一项提交时，附加一行内容为“（cherry picked from commit …​​）”到原始提交消息，以指示此更改是从哪个提交中cherry-picked(注：有的翻译此为“精心挑选”)的。这只适用于没有冲突的cherry picks。如果您是从私人分支中进行cherry pick，请不要使用此选项，因为这些信息对收件人没有用。另一方面，如果您是在两个公开可见的分支之间cherry pick（例如，从开发分支向维护分支回传一个旧版本的修正），添加这些信息可能很有用。如果不指定-x则默认不附加此内容。
• -m <parent-number>
  –mainline <parent-number>
  通常，您不能cherry-pick一项合并(merge)，因为您不知道合并的哪一边应该被视为主线。此选项指定主线的父编号（从1开始），并允许cherry-pick相对于指定的父编号重做之前的更改。
• -n
  –no-commit
• -s
  –signoff
• -S[<keyid>]
  –gpg-sign[=<keyid>]
  –no-gpg-sign
• –ff
  如果当前HEAD与cherry-pack’ed提交的父级相同，则将执行此提交的快进。
• –allow-empty
• –allow-empty-message
• –keep-redundant-commits
• –strategy=<strategy>
• -X<option>
  –strategy-option=<option>
• –rerere-autoupdate
  –no-rerere-autoupdate

3.33.4 EXAMPLES

3.35 rebase

3.35.1 简介

指路一位大佬写的博文：git rebase详解（图解+最简单示例，一次就懂）

3.35.2 语法

3.35.3 OPTIONS

• -i
  –interactive
  列出将要重新以为基(reabased)的提交。让用户在重新定基之前编辑该列表。此模式也可用于拆分提交（请参阅下面的 SPLITTING COMMITS）。
  可以通过设置配置选项 rebase.instructionFormat 来更改提交列表格式。自定义的指令格式将自动为该格式添加长提交哈希。
  另请参见下面的 INCOMPATIBLE OPTIONS 。

SPLITTING COMMITS

在交互模式(interactive mode)中，您可以使用"edit"操作标记提交。然而，这并不一定意味着 git-rebase 期望此编辑的结果恰好是一次提交。实际上，您可以撤消提交，也可以添加其他提交。这可用于将提交拆分为两部分：

• 使用 git rebase -i <commit>^ 启动交互式rebase，其中 <commit> 是要拆分的提交。事实上，任何提交范围都可以，只要它包含该提交即可。
• 用“edit”操作标记要拆分的提交。
• 当涉及到编辑该提交时，请执行 git reset HEAD^。其效果是HEAD向前倒带一次，index也随之而来。但是，工作树保持不变。
• 现在，将要在第一次提交时进行的更改添加到索引中。您可以使用 git-add（可能是交互式的）或 git-gui（或两者都使用）来实现这一点。
• 提交现在的当前索引，无论其提交消息是否恰当。
• 重复最后两个步骤，直到工作树清洁为止。
• 使用 git rebase --continue 继续变基操作。

如果您不能绝对确定中间修订是否一致（它们编译、通过测试套件等），则应在每次提交、测试后使用 git stash 来贮藏尚未提交的更改，并在需要修复的情况下修改提交。

3.36 revert

git reset 是回滚到对应的commit-id，相当于是删除了commit-id以后的所有的提交，并且不会产生新的commit-id记录，如果要推送到远程服务器的话，需要强制推送-f
git revert 是反做撤销其中的commit-id，然后重新生成一个commit-id。本身不会对其他的提交commit-id产生影响，如果要推送到远程服务器的话，就是普通的操作git push就好了
【git revert】使用以及理解（详解）

$ git revert [--[no-]edit] [-n] [-m <parent-number>] [-s] [-S[<keyid>]] <commit>…​
$ git revert (--continue | --skip | --abort | --quit)

3.37 ls-files

3.37.1 简介

显示有关Index和working tree中文件的信息。(本人经常用此命令来查看哪些文件已经被添加入Index暂存库中)
这会将Index中的文件列表与实际工作目录列表合并（虽然原文中使用的词是merge，但好像和 git-merge 操作不相关），并显示两者的不同组合。
可使用下面的一个或多个选项，用于确定显示的文件；如果Index中有多个条目或多个状态适用于相关文件选择选项，则每个文件可能会打印多次。

3.37.2 语法

git ls-files [-z] [-t] [-v] [-f]
        [-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
        [-s|--stage] [-u|--unmerged] [-k|--killed] [-m|--modified]
        [--resolve-undo]
        [--directory [--no-empty-directory]] [--eol]
        [--deduplicate]
        [-x <pattern>|--exclude=<pattern>]
        [-X <file>|--exclude-from=<file>]
        [--exclude-per-directory=<file>]
        [--exclude-standard]
        [--error-unmatch] [--with-tree=<tree-ish>]
        [--full-name] [--recurse-submodules]
        [--abbrev[=<n>]] [--format=<format>] [--] [<file>…​]

3.37.3 OPTIONS

• -c
  –cached
  显示Git Index中缓存的所有文件，即所有被跟踪的文件。（如果未指定-c/-s/-d/-o/-u/-k/-m/--resolve-undo选项，则此选项为默认选项。）
• -d
  –deleted
  显示包含未暂存删除（unstaged deletion）的文件。（个人理解”未暂存删除“的意思是，删除后没有git add）
• -m
  –modified
  显示具有未记录修改（unstaged modification）的文件（请注意，未记录的删除也算作未记录修改）
• -o
  –others
  在输出中显示其他（即未跟踪的(untracked)）文件
• -i
  –ignored
  在输出中仅显示被忽略的文件。必须与显式 -c 或 -o 一起使用。
  在Index中显示文件时（即与-c一起使用时），只打印那些与排除模式匹配的文件。
  当显示“其他”文件时（即与-o一起使用时），只显示那些与排除模式匹配的文件。标准忽略规则不会自动激活，因此至少需要一个 --exclude* 选项。
• -s
  –stage
  在输出中显示已提交内容（staged contents）的模式位、对象名称和分段编号。(基本用不到)
• –directory
  如果整个目录被分类为“其他”，则只显示其名称（带斜杠），而不显示其全部内容。使用该选项时必须与 -o/--others 选项配合使用。
• –no-empty-directory
  不要列出空目录。使用该选项时必须与 --directory 选项配合使用。
• -u
  –unmerged
  在输出中显示有关未合并文件的信息，但不显示任何其他跟踪的文件（forces --stage, overrides --cached）。
• -k
  –killed
  显示文件系统上由于文件/目录冲突而需要删除的未跟踪文件，以便将跟踪的文件写入文件系统。
• –resolve-undo
  显示Index中具有解析撤消信息(resolve-undo information)的文件及其解析撤消信息。（resolve undo信息用于实现“git checkout-m$PATH”，即重新创建意外解决的合并冲突）|
• -z
  详细内容请参阅下面的 OUTPUT。
• –deduplicate
  当只显示文件名时，抑制来自合并过程中具有多个阶段、或同时提供 --deleted 和 --modified 选项时可能产生的重复项。当使用 -t, --unmerged或--stage选项中的任何一个时，此选项都无效。
• -x <pattern>
  –exclude=<pattern>
  跳过与模式匹配的未跟踪文件。请注意，该模式是shell通配符模式。有关更多信息，请参阅下面的 EXCLUDE PATTERNS。
• -X <file>
  –exclude-from=<file>
  从<file>中读取排除模式；每条线路1个。
• –exclude-per-directory=<file>
  已弃用；请改用–exclude-standard。
• –exclude-standard
  添加标准的Git排除：每个目录中的.Git/info/exclude、.gitignore以及用户的全局排除文件。
• –error-unmatch
  如果任何<file>没有出现在Index中，则将其视为错误（返回1）。
• –with-tree=<tree-ish>
  当使用 --error unmatch 将用户提供的<file>（即路径模式）参数扩展到路径时，假设自命名的<tree ish>以来在索引中删除的路径仍然存在。
  将此选项与 -s 或 -u 选项一起使用没有任何意义。
• -t
  将状态标记与文件名一起显示。请注意，出于脚本目的，git status --porcelain 和 git diff files --name-status 是更好的替代方案，用户应该查看git status --short 或 git diff --name status 以获得更用户友好的替代方案。
  此选项提供了以状态标记（后面跟着空格，然后是文件名）的形式显示每个文件名的原因。状态标记都是以下列表中的单个字符：
  H 跟踪文件中的未合并或跳过工作树的
  S 跟踪文件中的跳过工作树的文件
  M 跟踪文件中的未合并文件
  R 跟踪文件中的未暂存删除(unstaged removal/deletion)的文件
  C 跟踪文件中的未暂存修改(unstaged modification/change)的文件
  K 未跟踪的路径是文件/目录冲突的一部分，该冲突阻止签出跟踪的文件
  ? 未跟踪文件
  U 具有解析撤消信息(resolve-undo information)的文件
• -v
  类似于 -t，但对标记为假定未更改(assume unchanged)的文件使用小写字母（请参阅git-update-index）。
• -f
  类似于 -t，但对标记为fsmonitor有效的文件使用小写字母（请参阅git-update-index）
• –full-name
  从子目录运行时，该命令通常输出相对于当前目录的路径。此选项强制输出相对于项目顶部目录的路径。
• –recurse-submodules
  递归调用存储库中每个活动子模块上的ls个文件。目前只支持 --cached 和 --stage 模式。
• –abbrev[=<n>]
  不显示完整的40字节十六进制对象行，而是显示唯一引用对象的最短前缀，该前缀的长度至少为<n>个十六进制数字。可以使用--abbrev=<n>指定非默认位数。
• –debug
  在描述文件的每一行之后，添加更多关于其缓存项的数据。这是为了显示尽可能多的信息，以便手动检查；确切的格式可能随时改变。
• –eol
  显示文件的<eolinfo>和<eolattr>。<eolinfo>是Git在“text”属性为“auto”（或未设置且 core.autocrlf 不为false）时使用的文件内容标识。<eolinfo>是"-text"、“none”、“lf”、“crlf”、“mixed"或”“。
  ”“表示该文件不是常规文件，不在索引中或在工作树中不可访问。
  <eolattr>是签出或提交时使用的属性，它可以是”“、”-text"、“text”、“text=auto”、“ext-eol=lf"和"text-eol=crlf”。自Git 2.10开始支持"text=auto +eol=lf"和"text=auto eol=crlf"。
  对于常规文件，Index(“i/<eolinfo>”) 和工作树(“w/<eolinfo>”) 中的<eolininfo>都会显示，后面跟着 (“attr/<eolabtr>”)。
• –sparse
  如果Index是稀疏(sparse)的，则显示稀疏目录，而不扩展到包含的文件。稀疏目录将显示为带有尾部斜杠，例如“x/”代表稀疏目录“x”。
• –format=<format>
  详细内容请参阅下面的 FIELD NAMES。笔者注：用该选项输出的都是一堆数字，其具体含义笔者不知道
• –
  分隔符
• <file>
  要显示的文件。如果未给定任何文件，则显示符合其他指定条件的所有文件。

OUTPUT

git ls-files 只输出文件名，除非指定 --stage 使输出信息更详细：

[<tag> ]<mode> <object> <stage> <file>

git ls-files --eol 会输出 i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>

git ls-files --unmerged 和 git ls-files --stage 可用于检查有关未合并路径的详细信息。

对于未合并的路径，Index不记录单个模式SHA-1对，而是最多记录三个这样的对：一个来自阶段1中的树O、阶段2中的A和阶段3中的B。用户（或porcelain）可以使用这些信息来查看最终应该在路径上记录什么。（有关状态的详细信息，请参阅 git-read-tree）

如果没有 -z 选项，带有“unusual”字符的路径名将被引用，正如配置变量 core.quotePath 所解释的那样（请参阅git-config）。使用 -z，文件名被逐字输出，行以NUL字节结束。

可以使用 --format 选项以自定义格式打印，该选项可以使用 %(fieldname) 表示法插入不同的字段。例如，如果您只关心“objectname”和“path”字段，则可以使用特定的“--format”执行，如

git ls-files --format='%(objectname) %(path)

FIELD NAMES

每个路径的显示方式可以通过使用 --format=<format> 选项进行自定义，使用 %(fieldname) 对 Index 中各个条目(entry)的 <format> 字符串进行插值 。“字段名(fieldname)”的含义如下：

objectmode
记录在Index中的文件的模式。

objecttype
记录在Index中的文件的类型。

objectname
记录在Index中的文件的名称。

objectsize[:padded]
记录在Index中的文件的大小（如果对象是提交或树，则为“-”）。它还支持大小为 %(objectsize:padded) 的填充格式。.

stage
记录在索引中的文件的状态。

eolinfo:index
eolinfo:worktree

指定路径在Index或工作树中内容的<eolinfo>（请参阅 --eol 选项的描述）。

eolattr
应用于路径的<eoattr>（请参阅 --eol 选项的描述）。

path
记录在Index中的文件的路径名。

3 后续待更新