分类：libgit2

将本地分支上传到远端，如果前面的各个功能都掌握了的话，这个接口可以算是非常简单的了。

需要注意的细节就是 1. 身份验证；2. refspecs

验证证书的回调，是通过 git_push_options 这个结构传递的，与之前一样的 callbacks 参数。详情可以参考前面的 九 和 十

refspecs 是用来指定这个 push 操作的本地分支和远端分支。它的格式是本地分支远端目标分支中间以冒号隔开。

比如我要把本地的 master 推到远端，碰巧远端对应的分支也叫 master，那好，它就是这个样子的：
refs/heads/master:refs/heads/master

当然，我们必须制定远端目标，因为它不一定仅仅是 origin：

那么最终，push 操作的代码就是：

示例代码：sample11

这是一个非常重要的操作。
这是一个非常简单的接口。
这是一个没多少内容又不得不提的主题。

直接上代码

需要注意的就是不要忘记身份验证，然后就开始 clone 操作了。

最后就简单介绍一下 git_clone_options 的主要参数：

checkout_opts
checkout 的配置，如果需要的话

fetch_opts
fetch 的配置，如果需要的话

bare
0 表示标准仓库，1 表示 bare 仓库

local
决定是否拷贝目标数据库而不是 fetch 。（如果目标是在本地，直接拷贝会更快一些）

checkout_branch
切到哪个分支，如果是空使用远端默认的分支

repository_cb
在这个回调里可以自己创建一个 repository

remote_cb
在这个回调里可以自己创建一个 remote

关于 bare 这个参数，不仅仅在 clone 这个操作用到。在 init 或 open 也是同样的意思。
表示只有版本记录，没有实际的工程里的代码和文件那些东西。更具体一点就是除了 .git 这个文件夹以外啥都没有。

示例代码：sample10

目前 libgit2 对 pull 操作的支持还不是太好，所以目前能找到的资料都指出 pull 操作就是先 fetch 然后再 merge 目标分支。比如要实现 git pull origin master ，就先 fetch 然后将 master 切换到 head 再将 origin master 合并到 head。

那么就先 fetch

git_remote_fetch 这个接口的后三个参数都是可以传 null 的，但是如果报了下面这个错：
authentication required but no callback set
说明远端地址需要验证身份，所以我们要设置 ssh 证书的回调。

C++

int cred_acquire_cb(git_cred **cred, const char *url, const char *username_from_url, unsigned int allowed_types, void *payload) { git_cred_ssh_key_new(cred, username_from_url, nullptr, "/Users/xiaochen/.ssh/id_rsa", nullptr); return 0; }

1 2 3 4 5

int cred_acquire_cb(git_cred **cred, const char *url, const char *username_from_url, unsigned int allowed_types, void *payload) {     git_cred_ssh_key_new(cred, username_from_url, nullptr, "/Users/xiaochen/.ssh/id_rsa", nullptr);     return 0; }

这样就完成了 fetch 操作。so easy

prune 也是 fetch 操作的一个重要参数。表示：清理掉远端已经删除的分支对应的本地分支，有点绕，不过应该还好理解吧。具体信息可以查一下下面这个命令。
git fetch -p （或 git fetch –prune）
在代码里实现只需要在 option 参数里做一个设置：

C++

fetch_opts.prune = GIT_FETCH_PRUNE;

1	fetch_opts.prune = GIT_FETCH_PRUNE;

这样就强制使用 prune 参数了。另外几个可选枚举值可以去读注释。

接下来为了实现类似 pull 的效果，就是蛋疼的合并操作了，顺便可以复习一下之前的内容。
首先将本地 master 设为 head

然后去拿 origin master 的 commit

合并

解决冲突

add 和 commit

清空状态

打完收工。

示例代码：sample9

这篇的主要内容是合并操作，是 git 中非常重要的操作。合并就有可能出现冲突，所以同时会简单介绍一下解决冲突。
合并操作主要针对的对象实际上并不是分支，只不过 commit 组成了一条分支，所以可以用分支来作为 commit 的索引。我们首先需要找到需要合并过来的那个 commit （或者多个 commit）。示例只简单的将一个分支最新的 commit 合并到 HEAD ，更多拓展的操作您可以自己发挥。
首先获得分支最新的 commit ：

DWIM 的意思貌似是：Do What I Mean

然后调接口实现 merge ：

上面这几行代码就实现了 merge 操作，然而，不要以为就这样就结束了，调用完 merge 接口才是刚刚开始。这个时候合并操作会被更新到 index，但是并不会写到 tree 里 ，所以后边的 add 和 commit 操作还是需要写的。到目前为止这个操作可能叫 try merge 更合理一些。
需要补充一点，如果 merge 没有成功，有可能存在有没处理完的合并，因为有可能在之前的合并操并没有走完全部流程就被强制终止了。这个时候 git_merge 是会报错的，所以如果报错了需要做一下判断，是继续上次未完成的合并，或是做一下清理：

这个状态清理，是合并操作流程完成后一定要调用的，否则磁盘上的标志文件会一直存在，会影响下一次合并操作。

git_merge 操作完成后，就要检查一下是否有冲突：

需要通过 index 来检查。
如果是有冲突的情况，可以通过 conflict_iterator 对冲突进行遍历：

解决冲突有几种方式：
1. 直接 checkout –ours(theirs) 快速选择一个版本作为最终合并后的版本：

也可以选择对指定文件 checkout ，只要设置一下 options 的参数：

2. 手动改写工作目录下的文件，通过取出的 git_index_entry 的 oid 可以获得对应版本文件的 blob ，这样可以把对应文件的内容取出。根据需要，将工作目录下的文件改写，这个就完全看自己的业务逻辑需要了，所以就不提供参考代码了。
之后要将这个解决完的冲突 remove 掉：

现在解决完冲突的文件状态已经在硬盘上体现出来了，但是实际上并没有完全更新到 index ，接下来就依照文件更新后 add 和 commit 的操作：更新 index→生成 tree → commit 来完成整个合并操作。
需要注意的一点是，因为是两个 commit 合并成新的 commit 所以这个新的 commit 的 parent 应该有两个：

这些细节在之前写过了，所以就不细说了。最后将合并状态清理一下就可以结束了：

补充说明
虽然 git_merge 传入了 annotated_commit 的数组，但是从实现代码上来看，合并操作只取了数组的第0个元素，所以实际上并不能实现同时将好多个 commit 合并的 HEAD。

首先介绍一些重要的术语：
diff —— 两个仓库快照的差异列表，以 git_diff 对象来管理。
delta —— 文件的新版本和旧版本组成一个一对儿，如果没有旧版本，说明文件是新加入的；如果没有新版本，说明这个文件在这个版本被删除了。diff 就是一列 delta。
binary —— 非文本文件的差异。二进制差异并没有细节的每行的内容等详细数据，主要是给出了文件路径。
hunk —— 是一个 delta 中连续有改动的行以及相关上下文组成的块。会告诉我们这块从哪行到哪行，以及其中有哪些改动。
line —— 是在一个 hunk 中的一个行的信息，包含其在新版本和旧版本的行号，变化信息以及新行的具体内容等。

生成一个 diff 的代码实际上很简单，重点在于如何从生成的 diff 中取出自己想要的数据。

这是生成一个 index 相对于 workdir 的 diff ，相当于命令行：git diff 。
其他的就不具体贴细节代码了，就做一些简单的介绍，从函数名就可以看出具体行为了，对于 index 、HEAD 、tree 等这些名词的概念不太了解的话，可以转到我的另一篇文章先熟悉一下。《libgit2使用教程（特别篇）几个基本概念说明》
实现 git diff --cached :
相当于 HEAD 相对于 index 的差异。可以取出 HEAD 的 tree 然后使用 git_diff_tree_to_index 来比对。
实现 git diff HEAD :
相当于 HEAD 相对于 workdir 的差异。可以取出 HEAD 的 tree 然后使用 git_diff_tree_to_workdir_with_index 来比对。
以及 commit 之间的差异，可以使用 git_diff_tree_to_tree 函数。
这些细节在官方的 101-samples 的 diff 部分有很多介绍，虽然代码给的并不够细，自己稍微鼓捣鼓捣也够用了。

我们有了一个 diff 之后，要做的就是从 diff 中获取数据了。就是通过 git_diff 指针取出 delta 、binary 、 hunk 、line 等信息。libgit2 只提供了一个 foreach 函数，这些数据通过传入的回调函数拿到。

这里边的回调并不一定都要传入，可以根据自己的需求选择传哪个，其他的可以为空指针。下面简单介绍一下回调回来的参数：
git_diff_delta :
主要带着新旧版本的文件信息(文件路径)；其他主要参数：
status 这个文件的状态，新增还是修改还是删除什么的。
flags 主要标记是否是二进制。
nfiles 这个差异有几个文件，比如如果是新增或删除，没有 old 或 new 就是1，如果是修改 old 和 new 都有就是2。

git_diff_binary:
binary 就比较单纯了，并没有太多信息，主要就是新版本和旧版本的文件信息。二进制的比对细节应该确实也没啥必要。

git_diff_hunk:
hunk 就是 git diff 命令的输出数据的那个样子，

一个文件差异可能会有多个 hunk ，具体参数：
old_start 这个块在旧版本中的起始行
old_lines 旧版本中这个块的行数
new_start 这个块在新版本中的起始行
new_lines 新版本中这个块的行数
header_len header 的字节数
header 块描述文本，就是上边[ @@ -633,7 +633,9 @@ class WP { ]这行。
这个描述大概就是这样的结构：
@@ [1][2],[3] [4][5],[6] @@ [7]
[1] 据我观察只有加号和减号(+/-)，我猜加号后边就是新版本，减号后边就是旧版本，两个版本之间以空格隔开。
[2] 这个块起始的行号。
[3] 这个块旧版本的行数
[4] 同[1]
[5] 同[2]
[6] 这个块新版本的行数
[7] 这个块所在的类的类名

git_diff_line:
origin 表示这个行的状态
old_lineno 旧的行的行号，如果是-1表示这个行的增加的
new_lineno 新的行的行号，如果是-1表示这个行是删掉的
num_lines 当前行的行数
content_len 当前行的字节数
content_offset 这个行在文件中的偏移量，只有在变化的行才有数据
content 这个行的内容
会把 hunk 的行数逐行都走一遍。

一个 diff 包含所有有差异文件，一个文件对应一个 delta，如果是二进制文件，就对应一个 binary ；如果是文本文件，一个 delta 可能对应一个或多个 hunk ，一个 hunk 可能对应一个或多个 line 。

最后，介绍一些稍微高级一些的设定。

将 untracked 的文件加入比对就不细说了，是针对 workdir 的，因为在新加入文件的情况下都是 untracked 的。

下边的两个回调是在比对的过程中触发的，因为整个比对的过程会遍历所有的文件，所以遍历的过程中没走过一个文件就会触发一次 progress_cb ；如果有一个文件新旧版本有差异，则会触发 notify_cb 。这两个回调是随着文件遍历进行的，所以这两个函数的一个参数 diff 明明为 so far ，指的就是当前为止的情况。如果只是想知道有哪些文件有差异而不需要具体的细节，那么就可以不使用 foreach 去遍历，使用 notify_cb 就够了。

如果一个文件和另一个文件完全一样，或者文件改了名，普通的 diff 是不会在 status 标出 GIT_DELTA_RENAMED 或 GIT_DELTA_COPIED 这些状态的。如果想要可以识别这些情况，就需要使用上边的代码和配置，通过 git_diff_find_similar 函数使这个配置生效。这个函数只要在 foreach 之前调用就可以了。

代码示例 sample5

status 这个操作是干啥的就不细解释了，这个不知道的话是不太适合看这套教程的，先去补补 git 相关的知识。这集的代码写起来还比较简单，在开动之前先复习一下基础概念。
HEAD、index、workdir:
HEAD 是当前所在的分支的最后一次 commit ，重点是已经 commit 了的状态。
index 是 git_index_add 之后的状态。但是要注意一下，这指的并不一定是使用命令行的 git add 命令完成。仅仅是加到 index 中就算了，并不需要完成 git_index_write 把内存中的状态写入磁盘。
workdir 还没加到 index 之前的都算在 workdir 的状态。

libgit 实现 status 大体上有两个方案，一个是简单一些，可以得到的信息也相对比较少的；另一个可以获得更详细的信息。我们从简单的开始

1. 简单方案

通过 callback 获取状态信息，
path 文件的相对路径
status_flags 是状态的枚举值
payload 是一个透传参数，从 git_status_foreach 第三个参数原样传入

关于状态的枚举值，这个枚举的声明是这样的：

IGNORED 是被忽略的文件，表示这个文件满足 .gitignore 中的规则。
CONFLICTED 是合并之后有冲突的文件。
GIT_STATUS_INDEX 开头的是 index 相对于 HEAD 的状态。
GIT_STATUS_WT 开头的是 workdir 相对于 index 的状态。

2. 详细方案

1) 初始化选项
2) 获取 git_status_list
3) 遍历 list 取出 git_status_entry

git_status_entry 除了有文件状态的标示，还带有 diff 的详细信息，而且严格区分了 HEAD 相对 index ，和 index 相对 workdir。
关于 diff 有很多要详细解释的东西，就放到下回了，我得花点时间读注释去了……