Git命令

1 前言

        最近根据需要，需要使用Git来管理项目，所以这里整理了一下Git的相关笔记，主要方便后续回顾。以后若有新的相关内容还会在本篇中进行更新。

2 安装

        首先从Git官网下载安装包，地址：GitGit官网Git 。然后点击下图红色箭头所指位置，下载安装包（图中，Windows版本，根据自己情况下载）。下好后点击安装即可。

安装好后，可以创建一个空文件夹，在此文件夹中右键鼠标，可以选择：

• Open Git GUI here

• Open Git Bash here

一个是图形界面，一个是命令行界面。一般使用命令行界面。如图：

PS：在命令行界面，输入命令后加-h参数可以查看相关参数说明。如：

git -h
git branch -h

这里提前说下，后续命令在使用时若不了解从参数，便可以尝试下-h参数。

2 配置命令

git config

参数：

1. 省略：本地配置，仅对本地仓库有效。
2. --global：全局配置，对所有仓库有效。
3. --system：系统配置，对所有用户生效。

git config --global user.name "<用户名>"	#配置用户名
git config --global user.email "<邮箱>"	#配置邮箱
git config --global credential store	#保存配置(保存于本地，这里就不过多解释了，感兴趣的话可以查一查)
git config --global --list	#查看配置信息

配置后才可以Commit。

3 创建仓库

两种方式：

1. git init
2. git clone

git init

git init	#将当前目录设置为一个仓库（会在此目录下创建一个.git隐藏文件）
#or
git init <文件夹名>	#在当前目录下创建一个文件夹，并以此文件夹为仓库（.git文件在创建的文件夹内）

git clone

git clone <远程仓库的地址，如https://github.com/xxxxxx.git>	#将github上的远程仓库克隆下来

4 Git的工作区域与文件状态

4.1 工作区

分为三个工作区：

1. 工作区（.git所在目录）
2. 暂存区（.git/index）
3. 本地仓库（.git/object）

工作区，就是我们主要操作的目录，修改等之类的操作在这里完成。

暂存区，是一个中间区域，我们处理的文件在提交之间会先存放到暂存区内，方便我们多次将修改文件放入暂存区内，之后再一次性提交。

本地仓库，存储代码与版本信息的主要位置。

4.2 文件状态

四种文件状态：

1. 未跟踪（仓库没有追踪、管理到这个文件）
2. 未修改（仓库已管理到，但未修改过）
3. 已修改（仓库已管理到，且已修改）
4. 已暂存（将文件添加到暂存区）

通常来说，未跟踪的文件添加一次暂存区就会被跟踪了。空文件夹是不会被跟踪了，即使git add .进行暂存区添加，也不会将其添加到其中，所以也跟踪不了。

5 查看状态、添加、提交等常用命令

git status

git status	#查看git仓库状态

git add

git add <xxx.后缀>	#将xxx文件添加到暂存区
#or
git add .	#将目录下所有文件添加到暂存区

git commit

git commit -m "<提交备注>"	#将暂存区中的内容提交到仓库
# 若没有使用-m来添加备注，则会进入vim编辑界面，在其中可以添加备注，保存再退出即可
#or
git commit -am "<提交备注>"	#可将工作区文件直接提交到仓库，跳过添加到暂存区的操作，但实际上还是添加的暂存区的，跳过的只是我们的操作

git ls-files

git ls-files	#查看暂存区内容（感觉这么说不准确，应该是被仓库所追踪的文件，因为提交commit仓库之后，此命令依然可以查询到文件）

ls -al	#查看当前目录下内容，一般是看工作区（显示隐藏文件、显示详细内容）

git log

git log	#查看当前分支log信息（提交列表）
#or
git log --oneline	#查看当前分支log信息，简化版本

git reflog

git reflog	#查看操作历史

6 回退版本

git reset

将自身回退到提交列表中的某一个版本（某次提交），根据参数可分为三种命令：

1. git reset --soft （软回退）
2. git reset --hard （硬回退）
3. git reset --mixed （同无参git reset）（混合回退）

PS：回退是在某一分支上进行回退。

6.1 软回退

        回退版本后，保留工作区、暂存区中的修改内容。比如有按时间排序的版本列表（历史记录）1、2、3，我目前处于3版本，现在软回退到1版本，则回退完成后，从1到3之间修改的文件也会被保存下来（工作区、暂存区）。通常来说软回退可用将多次提交进行合并，比如我们刚刚回到1了，但工作区、暂存区的修改文件都有，我马上再次提交一个版本，那么我就可以还原到软回退之前的状态，且提交列表是1、3。减少了提交列表内容数目，方便管理。

git reset --soft <target>	#软回退（回退后，保存工作区、暂存区修改内容），target是回退目标后面再说

6.2 硬回退

        回退版本后，工作区、暂存区中的修改内容全部删除。可以理解为完全还原成目标版本状态。（谨慎操作）

git reset --hard <target>	#硬回退（回退后，删除工作区、暂存区修改内容）

6.3 混合回退

        回退版本后，保留工作区修改内容，删除暂存区修改内容。

git reset --mixed <target>	#混合回退（回退后，保存工作区修改内容，删除暂存区修改内容）
#or
git reset <target>

6.4 回退目标target

        target一般是填对应的记录id的。如下：

#1、提交id
git log	--oneline	#查询提交列表
#一般会打印如下内容，最前面的就是ID，后面是提交备注
#002393a (HEAD -> master) delete other.log
#dc73c9b test ignore log
git reset 002393a	#根据id回退到对应版本

#2、操作id
git reflog	#查看操作历史
#打印内容也是包含id的
git reset <id>	#版本回退
# hard回退后，工作区、暂存区的修改都没了，提交列表中也回退到的当前记录，那么再想返回去的话，靠提交列表是不行的，那就要采用操作id来找到之前的版本提交，进行再次回退。

#3、HEAD
git reset HEAD^	#使用HEAD来回退，HEAD^指回退到上一版本

7 查看差异

        查看差异更建议使用图形界面，但git diff最好也要掌握，因为不是什么时候都有图形界面可用。

#查看“工作区”与“暂存区”之间的差异
git diff

#查看“工作区、暂存区”与“仓库”之间的差异
git diff HEAD

#查看“暂存区”与“仓库”之间的差异
git diff --cached
#or
git diff --staged

#查看“提交（版本）”之间的差异
git diff <提交id> <提交id>
#or
git diff HEAD~ HEAD	#HEAD是当前版本，HEAD~同HEAD^都是上一版本。HEAD~之后可跟数字，HEAD~2代表上上一版，然后还可以HEAD~3、HEAD~4。

#查看“分支”之间的差异
git diff <分支name> <分支name>

8 删除文件

8.1 一般方法

        使用一般删除命令（非git，linux下的，如rm），或是直接在可视化界面里删除工作区文件。之后再添加到暂存区。然后再提交到仓库。 稍微麻烦，因为还要进行一次添加暂存区操作。所以git也提供了相关命令。

8.2 git rm

git rm <文件名>	#删除文件（工作区、暂存区）
#or
git rm --cached <文件名>	#删除文件（保留工作区，删除暂存区）
#or
git rm -r *	#当前目录下大清空（递归删除子目录与文件，工作区、暂存区）

#最后要提交到仓库

9 .gitignore文件

        记录到此文件中的文件会在版本管理中被忽略。

9.1 通常需要忽略的文件

• 系统或者软件自动生成的文件。
• 编译产生的中间文件和结果文件。
• 运行时生成的日志文件、缓存文件、临时文件。
• 涉及身份、密码、口令、密钥等敏感信息的文件。

9.2 如何忽略

        可以通过vim来编辑.gitignore文件，在其中添加我们想要忽略的文件。如aa.txt，或是*.log等等。

PS：.gitignore生效前提是，修改的文件不能是已经添加到版本库中的文件。已经添加到版本库的文件不会被忽略，已经被正常版本管理。如果想忽略就得将其从版本库中删除，直接删即可。

        除了忽略文件外，也可以忽略文件夹，如文件夹Test，以Test/形式加入到.gitignore文件中即可。

PS：空文件夹是不会被git纳入版本管理的。

9.3 .gitignore中忽略文件匹配规则

        匹配规则可从git官网查询，也就是正则表达式之类的东西。

9.4 预设.gitignore文件获取

从GitHub上可以获取到各种.gitignore文件。地址：https://github.com/github/gitignore。Unity的.gitignore文件也有。

10 GitHub SSH、克隆仓库

        虽然是以GitHub为例，但同样适用于GitLab。

10.1 GitHub的使用

        略。这块就不讲了。

10.2 配置shh密钥

cd ~	#首先回到用户根目录
mkdir .ssh	#创建一个.ssh文件夹，有就不用创了
cd .ssh	#进入此文件夹
ssh-keygen -t rsa -b 4096	#生成SSH KEY

建议直接使用默认名字，否则就要添加配置文件，如下：

vi config	#添加配置文件（GitHub）（与创建的密钥文件在同一个目录）
#加入下面5行

# github
Host github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/TheFirstKey

        注意私钥、公钥。私钥是自己的，不要给别人，公钥是分发给别人的。这里我们复制了公钥中的内容后，将其复制到GitHub或GitLab设置中的SSH设置中，形成公钥。私钥不用管，就保存在我们电脑里。这样后续我们pull、push的时候就不需要登录，很方便。在GitHub中创建公钥：

10.3 克隆远程仓库

#先复制公钥，在添加到github上去。

git clone <ssh url>	#本地使用ssh url克隆仓库，不建议http

#之后会提示输入密码验证，输入ssh密码即可

11 远程仓库

11.1 关联到远程空仓库的例子

        本地创建仓库再关联到远程仓库 ：

echo "# F" >> README.md	#创建readme文件
git init	#仓库初始化
git add README.md	#将readme文件添加到暂存区
git commit -m "first commit"	#提交
git branch -M main	#重命名当前分支为main
git remote add origin git@github.com:Helckorz/F.git	#配置本地的远程仓库，origin即仓库名，git remote add <远程仓库名> <远程仓库地址>
git push -u origin main	#将本地仓库推送到远程仓库。完整写法是git push -u <远程仓库名> <本地分支名>:<远程分支名>，本地与远程分支名相同即可只写一个

        本地已有仓库关联到远程仓库 ：

git remote add origin git@github.com:Helckorz/F.git
git branch -M main
git push -u origin main

11.2 远程仓库相关命令

11.2.1 本地配置远程仓库

git remote add <远程仓库名> <url>	#添加一个新的远程仓库。指定远程仓库的名称和url，将其添加到本地仓库中，建立一种“沟通关系”，注意与“关联”区分开始，“关联”是本地分支与远程分支的一种对应关系。

11.2.2 查看本地配置的远程仓库

git remote	#查看本地仓库已配置的远程仓库列表
#or
git remote -v	#（包含url，更详细）

git remote show <远程仓库名>	#显示指定远程仓库的详细信息，包括url和跟踪分支。

11.2.3 查看远程仓库分支信息

git branch -r	#查看远程仓库的分支信息

11.2.4 将本地分支关联到远程分支

git branch --set-upstream-to=<远程仓库名>/<远程仓库分支名> <本地分支名>  #关联远程仓库分支（关联后可以快速push、pull操作）

11.2.5 设置配置的远程仓库信息

git remote rename <远程仓库old_name> <远程仓库new_name>	#将已配置的远程仓库重命名。

git remote set-url <远程仓库名> <new_url>	#修改指定远程仓库的url。

11.2.6 移除本地配置的远程仓库

git remote remove <远程仓库名>	#从当前仓库中删除指定的远程仓库。（不是删除远程仓库，只是删除添加到本地的远程仓库“沟通关系”，与add对应）

11.2.7 移除远程仓库中的某一分支（影响远程）

git push <远程仓库名> --delete <远程仓库分支名>	# 删除远程仓库分支，也可以推个空分支过去，在下面push里有讲

11.3 git pull

git pull <远程仓库名> <远程分支名>:<本地分支名>	#以上面关联为例，这里的远程仓库名就是origin
#or
git pull <远程仓库名> <远程分支名>	#直接拉取到本地当前分支
#or
git pull	#若省略，则是直接将本地对应的远程仓库的主分支拉取到本地合并，前提是他们之间是默认关联的，本体仓库使用git remote add来关联，前面有说明

11.4 git push

git push <远程仓库名> <本地分支名>:<远程分支名>	#本地与远程分支名相同即可只写一个
#or
git push <远程仓库名> :<远程分支名>	#若不写本地分支名，则意味着将其远程分支删除！
#or
git push -u <远程仓库名> <本地分支名>:<远程分支名>	#-u参数相当于记录了push到远端分支的默认值，这样当下次我们还想要继续push的这个远端分支的时候，只需要git push即可。

PS：在push时，远程仓库需要存在，否则报错，若分支不存在则会在远程仓库创建分支。

11.5 git fetch

        首先，git pull可以理解为git fetch + git merge。我们可以认为本地有两种类型的分支：

1. 本地分支
2. 远程分支

远程分支就是远程仓库所有的分支，本地分支就是只有本地有，远程没有的。git fetch的作用就是更新远程分支到最新状态。

git fetch <远程仓库名> <远程分支名>	#更新某个远程仓库分支信息
#or
git fetch --all	#更新远程仓库所有分支信息（应该是关联的远程仓库）

大概就是下图这种感觉：

12 分支

        我对分支的理解，因为之前我的理解的确有偏差，所以这里记录下：

1. 分支准确说，是指分支图中的分支节点组合，或者说分支是以仓库为基础而存在的。一个分支有多个分支节点，每个分支节点都是这个分支的组成部分，这些部分的单元便是仓库，“提交仓库，形成节点”。

2. 在某一分支上进行文件的创建、修改、删除，然后无论添加还是不添加暂存区，在其他分支上都是可以看到变化的，会看到新创文件，会看到文件内容改变了，会看到某些文件删除了，因为这这些内容目前不属于任何一个分支。但当在某一分支提交之后，提交分支会应用刚才的那些文件操作，在其他分支上就会还原，新文件没有了，修改的内容也变回去了，删除的文件又出现了。此时，刚才的文件操作内容就仅属于那个提交的分支了。

3. （接2）这里还需要说一点，前面说增删改这些操作在别的分支可见，是有前提的，修改当前分支不提交然后切换其他分支是需要注意一些问题的，下面就更详细的说下。假设有两个分支A和B，我们在A分支上操作。创建文件的话，需要注意的是创建同名文件的问题，再A分支创建一个与B分支已有文件的同名文件，不提交情况下切换B分支将不被允许，且报错。删除的话，分情况说，在A分支删除与B分支上相同（同名、同内容）的文件，不提交切换到B分支会发现相同文件也会消失，在A提交后，B上的就恢复了；若删除A分支有但B分支没有的文件，删除后不提交切换到B分支再切换回A分支，会发现被删除文件恢复了；若文件同名但内容有差别，那么在A删除后，不提交情况下切换到B分支会发现同名文件不会被删除，并且再切换A就发现自己的同名文件给还原了。修改的话，要求修改的文件需要是A、B两个分支都拥有的相同文件，即名称、内容相同，否则在A上修改后，在没有提交的情况下切换B分支将不被允许且提醒错误。总之，建议，在某一分支上操作的时候，若突然需要切到另外一个分支来做一些处理的时候，最好直接把当前分支上的操作内容提交了，保证这些操作不会影响别的分支，这样提交之后就可以放心切到别的分支处理其他工作了。

12.1 查看分支信息

git branch	#查看分支信息
#or
git branch -vv	#更详细的分支信息，包括与远程仓库的关联关系，-v的不包括关联信息

git branch -r	#查看远程仓库的分支信息

12.2 创建分支

git branch <分支名>	#创建分支
#or
git branch <分支名> <提交id>	#创建某一版本的分支
#or
git branch <分支名> <tag名>	#创建某一tag对应提交的分支

12.3 切换分支/撤销操作

git checkout <分支名>	#切换到不同分支上
#or
git checkout -b <分支名>	#使用-b参数表示：创建、并切换到分支上，相当于两步操作。
#or
git checkout -b <分支名> <提交id/分支名/tag名>	#创建某一版本的分支，并切过去

PS：git checkout潜在问题。git checkout除了切换分支外，还可以让文件恢复到某一状态，比如让一个修改的文件恢复到没有修改的状态。那么在文件名与分支名同名时，使用git checkout就会产生歧义，默认切换分支。

因此后续官方提供了新命令git switch命令，专门来切换分支。

git switch <分支名>	#切换分支

        git checkout除了切换分支，另一个常见操作就是撤销操作，让工作区中的文件回到最近一次git add或git commit的状态。

git checkout -- .	# 让工作区中的所有文件撤销更改
#or
git checkout -- <file1>	# 让工作区中的某个些文件撤销更改
#or
git checkout -- <file1> <file2>	# 让工作区中的某些文件撤销更改

12.4 合并分支

12.4.1 合并

git merge <分支名>	#将目标分支合并到当前分支，合并后会自动提交一次，让我们输入提交备注，可以直接wq保存，使用默认备注即可。
#or
git merge --no-ff <分支名>	#使用--no-ff选项可以100%保留原有的分支结构信息，并将其包含在合并后的提交记录中。这样一来就很方便查询合并分支原先的记录。下面有更详细说明。

PS：

1. 分支合并后，git branch可以看到合并的分支是依旧存在的，可以手动删除这些分支，减少分支数目方便管理。那删除后会影响分支结构图吗？答案是：合并的不会，没合并的会。
2. 当然，若是继续开发，最好是删除这些分支再重新创建分支。为什么？比如A分支要合并到主分支上，A分支可能包含其他分支的合并内容，那么A分支合并到主分支上后，A分支相比主分支是缺少内容的，这时候我们想以较完整的内容为起点开发，就不能再使用A分支了，需要删除A分支（删除后面有讲），再基于主分支创建A分支。
3. 另外，合并分支实际上是合并提交。假设有A、B两个分支内容相同，首先将B分支中的部分内容删除且提交，A分支增加新文件new且提交，然后将A分支合并到B分支，那么B分支只会多出new文件，之前删除的内容是不会复原的。

12.4.2 --no-ff参数

        首先要明确，默认的git merge真实面貌是git merge --ff，即fast-forward合并。所以我们要探讨的实际上是两种合并方式：

1. fast-forward合并（fast-forward，FF）
2. 非fast-forward合并（no fast-forward，noFF）

        虽然默认的git merge是FF合并，但也不是什么时候都适用的，具体会不会使用也不用我们关心，可FF合并时git便会FF合并，不能FF合并时git便会noFF合并。以下图为例，来了解：

1. 什么是FF合并
2. 什么是noFF合并
3. git merge时候才可以FF合并

        如图所示，前者是可以FF合并的情况，后者是不可以FF合并的情况。前者，可以看到若b1分支是main分支是线性连续的，即main分支在b1分出来后并未有新的提交节点，那么这种情况git merge就会默认使用FF合并。后者，若b1分支分出后，main分支有了新的提交节点，形成了一种并行结构，这个时候只能进行noFF合并。

        由此我们知道了git merge对FF和noFF合并的使用时机，同时大概也知道了FF和noFF合并方式的区别，但还要更具体说下这两个合并方式，首先看图：

图中，以线性结构为例展示了默认的FF合并，以及强制noFF合并的情况。

“FF合并”

        首先我们会有一个main指针来指向本地主分支的最新节点，以此表示主分支情况。FF合并则是将这个main指针往后移动，以图中为例的话，就是从2移动到了b，进而得到合并结果。需要注意的是合并后，main分支git log打印的log中并不会新增merge的记录，增加的记录是b提交后那个时间点所得到的log记录，分支结构图也还是那个时间点的结构图。下面分别展示了分支提交和分支合并时的结构图与log。（图中主分支是master，分支是b4）：

b4提交

b4合并

对比可知，master主分支log中并没有增加merge的记录，而是将b4的提交记录拿了过来，结构图无变化（HEAD是当前所在分支，无视）。

“noFF合并”

        这个就很好理解了，创建了一个新节点，将main和b1进行合并。log会有merge记录，分支结构图会有更新，如图：

b4提交

同前面的图，略。

b4合并

log除了b4提交，还新增了merge记录。结构图则是更新成了“真正的”合并样式。

PS：这里说一下b4合并到master主分支后，master主分支log中会增加什么记录吧。

• FF合并：b4分支本身的所有提交记录。
• noFF合并：b4分支本身的所有提交记录 + 最后这一次的合并记录。

若是团队开发，建议多使用noFF合并，可以清晰的记录每次合并，方便查询历史。

12.5 查看分支图

git log --graph --oneline --decorate --all	#在命令行查看分支图

12.6 删除分支

git branch -d <分支名>	#删除已经合并的分支，若没有合并则不能使用-d参数
#or
git branch -D <分支名>	#强制删除分支，一般删除没有合并的分支

PS：

• 已经合并的分支，删除后不影响分支结构图。（-d）
• 未合并的分支，删除后将从分支结构图中消失。（-D）

13 解决合并冲突

        执行git merge冲突后，解决方法：

1. 编辑冲突文件，调整内容。
2. git add添加暂存区。
3. git commit提交仓库，即可自动合并。

若想终止合并，可使用如下命令：

git merge --abort	#终止合并

14 rebase

14.1 介绍

        rebase也可以用来合并分支，这里可以用“嫁接”这个词来形容它。

git rebase <目标分支名>	#将当前所在分支合并到目标分支

        图示rabase的效果：

如图所示，对比了merge与rebase之间的区别，其中main是主分支，b1是分支。merge后，b1分支的记录依旧单独存在，而rebase后b1分支不再有单独存在的记录。另外还要注意在合并两个分支时，git rebase在不同分支上执行，最终得到的分支图是不同的，从上图中也可以看出区别。

14.2 优缺点（merge与rebase）

merge

• 优点：不会破坏原分支的提交记录，拥有完整的分支图，方便回溯与查看历史。
• 缺点：会产生额外的提交节点，分支图比较复杂。

rebase

• 优点：不需要新增额外的“边路”提交节点，形成线性历史，比较直观。
• 缺点：会改变提交历史，有些提交无法再回溯，因此避免在共享分支上进行Rebase操作。

PS：个人感觉还是merge比较舒服。

15 tag

        git tag命令可以给提交版本打上tag记录，通常用于版本管理。

15.1 查看标签

git tag	#查看tag标签
#or
git tag -l 'v*'	#搜索特定标签，模糊搜索

15.2 新建标签

        新建标签有两种类型：

1. 轻量级的（可理解为某次提交的引用，某次提交的别名）
2. 带备注的（会在仓库中创建一个完成的对象）

git tag <tag名>	#创建轻量级的tag

git tag -a <tag名> -m <备注内容>	#创建带备注的tag。若没有-m及其之后的内容，则会自动打开编辑器让我们填写备注

        对历史提交版本添加标签：

git tag <tag名> <提交id>	#轻量级的

git tag -a <tag名> -m <备注内容> <提交id>	#带备注的

15.3 查看标签信息

git show <tag名>	#查看某标签信息

PS：可从结构图中查看所有标签的分布。

15.4 推送标签到远程

        默认情况下，git push无法推送标签到服务器，所以需要特别推送标签。

git push <远程仓库名> <tag名>	#将本地某一tag推送到远程仓库
#or
git push <远程仓库名> --tags	#将本地所有新增tag推送到远程仓库

15.5 删除本地与远程标签

#本地
git tag -d <tag名>	#本地删除标签

#远程
#1、
git tag -d <tag名>	#本地删除标签
#2、
git push <远程仓库名> :refs/tags/<tag名>	#再推送到远程仓库
#or
git push <远程仓库名> --delete <tag名>	#再推送到远程仓库

16 cherry-pick

        cherry-pick的作用是将制定的提交（commit）应用于其他分支。有别于合并是将整个分支进行合并，这里仅仅是选择某次提交进行合并，更加轻量化。适合修改BUG、提取特定功能之类的操作。

16.1 基本使用

git cherry-pick <提交id>	#将提交id对应的提交应用到当前所处分支，这会在当前分支中产生一个新的提交
#or
git cherray-pic <目标分支名>	#将目标分支的最新提交，应用到当前所处分支

16.2 多个提交

git cherry-pick <提交id-1> <提交id-2>	#将在当前分支产生两次提交，1、2
#or
git cherry-pick <提交id-1>..<提交id-2>	#将(1,2]范围的所有提交应用到当前分支，产生多个提交，1和2应是先后顺序，否则执行失败
#or
git cherry-pick <提交id-1>^..<提交id-2>	#这样范围就修改为了[1,2]

16.3 可用参数

#打开编辑器，编辑提交信息
-e 
--edit

#不进行提交，只更新工作区与暂存区
-n
--no-commit

#在提交信息末尾增加说明，表示此次pick来自哪个commit
-x

#在提交信息末尾，增加操作者签名，表明操作者
-s
--signoff

#当pick的节点是一个合并节点时，就会产生歧义，不知道应该采用合并前两个分支的哪一个分支的变动，通过-m可以指定某一分支。1是被合并的分支，2是来合并的分支，例如将b1合并到main，那么1就指main，2就指b1。
-m parentNumber
--mainline parentNumber

16.4 冲突解决

        若pick时发生冲突，则pick会暂停，让我们去解决冲突。等冲突解决后，我们可以使用相关命令来继续操作。

16.4.1 继续进行

#1、首先添加到暂存区
git add .
#2、继续pick
git cherry-pick --continue	#继续

16.4.2 放弃pick

git cherry-pick --abort	#回到没有pick前的状态

16.4.3 退出pick

git cherry-pick --quit	#退出pick，但不回到操作前的状态，没有冲突的内容部分将会变为modified

16.4.4 跳过pick

git cherry-pick --skip	#将引起冲突的提交丢弃

17 结束语

        本文的主题是对Git常见命令的介绍，方便用于后续的复习。目前所记录的git命令基本是够用的，对于日常所要使用到的命令还是要确保有一定程度的了解的，毕竟是协同开发，要负起自己的责任。实际对于文中有些命令，我的了解还是不够的，后续如果使用到了再去研究补充吧。

---

参考资料

【GeekHour】一小时Git教程