标签： 版本管理

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

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

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

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;
}

git_push_options opts = GIT_PUSH_OPTIONS_INIT;
opts.callbacks.credentials = cred_acquire_cb;

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

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

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

git_remote *remote = nullptr;
git_remote_lookup(&remote, rep, "origin");

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

const char *refs[] = {"refs/heads/master:refs/heads/master"};
git_strarray strarr = {(char **) refs, 1};
opts.callbacks.credentials = cred_acquire_cb;
git_remote_push(remote, &strarr, &opts);

示例代码：sample11

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

直接上代码

git_repository *rep = nullptr;
git_clone_options opt = GIT_CLONE_OPTIONS_INIT;

opt.fetch_opts.callbacks.credentials = cred_acquire_cb;
git_clone(&rep, "git@github.com:XiaochenFTX/libgit2_samples.git", path, &opt);

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;
}

需要注意的就是不要忘记身份验证，然后就开始 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 *remote = nullptr;
git_fetch_options fetch_opts = GIT_FETCH_OPTIONS_INIT;

// get a remote
git_remote_lookup(&remote, rep, "origin");
// git fetch
fetch_opts.callbacks.credentials = cred_acquire_cb;
git_remote_fetch(remote, nullptr, &fetch_opts, nullptr);

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

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 参数里做一个设置：

fetch_opts.prune = GIT_FETCH_PRUNE;

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

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

git_reference *local_master = nullptr;
git_branch_lookup(&local_master, rep, "master", GIT_BRANCH_LOCAL);
git_repository_set_head(rep, git_reference_name(local_master));

然后去拿 origin master 的 commit

git_reference *origin_master = nullptr;
git_branch_lookup(&origin_master, rep, "origin/master", GIT_BRANCH_REMOTE);

合并

git_merge_options merge_opt = GIT_MERGE_OPTIONS_INIT;
git_checkout_options checkout_opt = GIT_CHECKOUT_OPTIONS_INIT;
const git_annotated_commit *their_head[10];
git_annotated_commit_from_ref((git_annotated_commit **) &their_head[0], rep, origin_master);
git_merge(rep, their_head, 1, &merge_opt, &checkout_opt);

解决冲突

git_index *index = nullptr;
git_index_conflict_iterator *conflict_iterator = nullptr;
git_repository_index(&index, rep);
if (git_index_has_conflicts(index))
{
    const git_index_entry *ancestor_out = nullptr;
    const git_index_entry *our_out = nullptr;
    const git_index_entry *their_out = nullptr;
    git_index_conflict_iterator_new(&conflict_iterator, index);
    while (git_index_conflict_next(&ancestor_out, &our_out, &their_out, conflict_iterator) != GIT_ITEROVER)
    {
        if (ancestor_out) std::cout << "ancestor: " << ancestor_out->path << std::endl;
        if (our_out) std::cout << "our: " << our_out->path << std::endl;
        if (their_out) std::cout << "their: " << their_out->path << std::endl;
    }
    // git checkout --theirs <file>
    git_checkout_options opt = GIT_CHECKOUT_OPTIONS_INIT;
    opt.checkout_strategy |= GIT_CHECKOUT_USE_THEIRS;
    git_checkout_index(rep, index, &opt);
    git_index_conflict_iterator_free(conflict_iterator);
}

add 和 commit

git_commit_lookup(&their_commit, rep, git_reference_target(origin_master));
git_commit_lookup(&our_commit, rep, git_reference_target(local_master));
git_index_update_all(index, nullptr, nullptr, nullptr);
git_index_write(index);
git_index_write_tree(&new_tree_id, index);
git_tree_lookup(&new_tree, rep, &new_tree_id);
git_signature_now(&me, "XiaochenFTX", "xiaochenftx@gmail.com");
git_commit_create_v(&commit_id, rep, git_reference_name(local_master), me, me, "UTF-8", "pull commit", new_tree, 2,
                    our_commit, their_commit);

清空状态

git_repository_state_cleanup(rep);

打完收工。

示例代码：sample9

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

const git_annotated_commit *their_head[10];
git_reference *branch = nullptr;

git_reference_dwim(&branch, rep, "new");
git_annotated_commit_from_ref((git_annotated_commit **) &their_head[0], rep, branch);

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

然后调接口实现 merge ：

git_merge_options merge_opt = GIT_MERGE_OPTIONS_INIT;
git_checkout_options checkout_opt = GIT_CHECKOUT_OPTIONS_INIT;
git_merge(rep, their_head, 1, &merge_opt, &checkout_opt);

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

git_repository_state_cleanup(rep);

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

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

git_index *index = nullptr;
git_repository_index(&index, rep);
if (git_index_has_conflicts(index)) { /* reslove code ... */ }

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

git_index_conflict_iterator *conflict_iterator = nullptr;
const git_index_entry *ancestor_out = nullptr;
const git_index_entry *our_out = nullptr;
const git_index_entry *their_out = nullptr;

git_index_conflict_iterator_new(&conflict_iterator, index);

while (git_index_conflict_next(&ancestor_out, &our_out, &their_out, conflict_iterator) != GIT_ITEROVER)
{
    if (ancestor_out) std::cout << "ancestor: " << ancestor_out->path << std::endl;
    if (our_out) std::cout << "our: " << our_out->path << std::endl;
    if (their_out) std::cout << "their: " << their_out->path << std::endl;
    /* your code ... */
}

git_index_conflict_iterator_free(conflict_iterator);

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

git_checkout_options opt = GIT_CHECKOUT_OPTIONS_INIT;
opt.checkout_strategy |= GIT_CHECKOUT_USE_THEIRS;
git_checkout_index(rep, index, &opt);

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

const char *p = "file";
opt.paths.strings = (char **) &p;
opt.paths.count = 1;

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

git_index_conflict_remove(index, "file");

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

git_oid new_tree_id;
git_tree *new_tree = nullptr;
git_signature *me = nullptr;
git_reference *head = nullptr;
git_commit *parent_our = nullptr;
git_commit *parent_their = nullptr;
git_oid commit_id;

git_index_update_all(index, nullptr, nullptr, nullptr);
git_index_write(index);
git_index_write_tree(&new_tree_id, index);
git_tree_lookup(&new_tree, rep, &new_tree_id);

git_signature_now(&me, "XiaochenFTX", "xiaochenftx@gmail.com");

git_repository_head(&head, rep);
git_commit_lookup(&parent_our, rep, git_reference_target(head));
git_commit_lookup(&parent_their, rep, git_reference_target(branch));

git_commit_create_v(&commit_id, rep, "HEAD", me, me, "UTF-8",
    "merge commit", new_tree, 2, parent_our, parent_their);

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

git_repository_state_cleanup(rep);

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

if ((error =
    merge_annotated_commits(&index, &base, repo, our_head, (git_annotated_commit *) their_heads[0], 0, merge_opts)) < 0
     || (error = git_merge__check_result(repo, index)) < 0
     || (error = git_merge__append_conflicts_to_merge_msg(repo, index)) < 0)
    goto done;

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

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

git_diff *diff_index_to_workdir = nullptr;
git_diff_index_to_workdir(&diff_index_to_workdir, rep, nullptr, nullptr);

这是生成一个 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 函数，这些数据通过传入的回调函数拿到。

int file_cb(const git_diff_delta *delta, float progress, void *payload)
{
    std::cout << "old file path: " << delta->old_file.path << "\n";
    std::cout << "new file path: " << delta->new_file.path << "\n";
    std::cout << "file number: " << delta->nfiles << "\n";
    std::cout << "status: " << delta->status << "\n";
    std::cout << "flags: " << delta->flags << "\n";
    std::cout << "progress: " << progress << "\n";
    std::cout << "==================" << std::endl;
    return 0;
}

int binary_cb(const git_diff_delta *delta, const git_diff_binary *binary, void *payload)
{
    std::cout << "old file path: " << delta->old_file.path << "\n";
    std::cout << "new file path: " << delta->old_file.path << "\n";
    std::cout << "=================" << std::endl;
    return 0;
}

int hunk_cb(const git_diff_delta *delta, const git_diff_hunk *hunk, void *payload)
{
    std::cout << "old start: " << hunk->old_start << "\n";
    std::cout << "old lines: " << hunk->old_lines << "\n";
    std::cout << "new start: " << hunk->new_start << "\n";
    std::cout << "new lines: " << hunk->new_lines << "\n";
    std::cout << "header: " << hunk->header << "\n";
    std::cout << "=================" << std::endl;
    return 0;
}

int line_cb(const git_diff_delta *delta, const git_diff_hunk *hunk, const git_diff_line *line, void *payload)
{
    std::cout << "origin: " << line->origin << "\n";
    std::cout << "old line number: " << line->old_lineno << "\n";
    std::cout << "new line number: " << line->new_lineno << "\n";
    std::cout << "num lines: " << line->num_lines << "\n";
    std::cout << "content offset: " << line->content_offset << "\n";
    std::cout << "=================" << std::endl;
    return 0;
}

git_diff_foreach(diff_index_to_workdir, file_cb, binary_cb, hunk_cb, line_cb, nullptr);

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

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

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

@@ -633,7 +633,9 @@ class WP {
                                return;
                        }
                }
-
+//a
+//b
+//c            
                // We will 404 for paged queries, as no posts were found.
                if ( ! is_paged() ) {
 

一个文件差异可能会有多个 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 。

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

int notify_cb(const git_diff *diff_so_far, const git_diff_delta *delta_to_add, const char *matched_pathspec,
              void *payload)
{
    std::cout << "***notify cb***" << "\n";
    std::cout << "old file: " << delta_to_add->old_file.path << "\n";
    std::cout << "new file: " << delta_to_add->new_file.path << "\n";
    std::cout << "matched path spec: " << (matched_pathspec != nullptr ? matched_pathspec : "null") << "\n";
    std::cout << "*****************" << std::endl;
    return 0;
}

int progress_cb(const git_diff *diff_so_far, const char *old_path, const char *new_path, void *payload)
{
    std::cout << "****pro cb****" << "\n";
    std::cout << "old path: " << old_path << "\n";
    std::cout << "new path: " << new_path << "\n";
    std::cout << "*****************" << std::endl;
    return 0;
}

git_diff_options diff_opt = GIT_DIFF_OPTIONS_INIT;
diff_opt.flags |= GIT_DIFF_INCLUDE_UNTRACKED;
diff_opt.notify_cb = notify_cb;
diff_opt.progress_cb = progress_cb;

git_diff_index_to_workdir(&diff_index_to_workdir, rep, nullptr, &diff_opt);

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

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

git_diff_find_options diff_find_opt = GIT_DIFF_FIND_OPTIONS_INIT;
diff_find_opt.flags |= GIT_DIFF_FIND_RENAMES;
diff_find_opt.flags |= GIT_DIFF_FIND_COPIES;
diff_find_opt.flags |= GIT_DIFF_FIND_FOR_UNTRACKED;

git_diff_find_similar(diff_index_to_workdir, &diff_find_opt);

如果一个文件和另一个文件完全一样，或者文件改了名，普通的 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. 简单方案

int status_cb(const char *path, unsigned int status_flags, void *payload)
{
    std::cout << "path: " << path;
    std::cout << "\nflag: " << status_flags << std::endl;
    
    return 0;
}

error = git_status_foreach(rep, status_cb, nullptr);

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

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

/**
 * Status flags for a single file.
 *
 * A combination of these values will be returned to indicate the status of
 * a file. Status compares the working directory, the index, and the
 * current HEAD of the repository. The `GIT_STATUS_INDEX` set of flags
 * represents the status of file in the index relative to the HEAD, and the
 * `GIT_STATUS_WT` set of flags represent the status of the file in the
 * working directory relative to the index.
 */
typedef enum {
    GIT_STATUS_CURRENT = 0,
    GIT_STATUS_INDEX_NEW = (1u << 0),
    GIT_STATUS_INDEX_MODIFIED = (1u << 1),
    GIT_STATUS_INDEX_DELETED = (1u << 2),
    GIT_STATUS_INDEX_RENAMED = (1u << 3),
    GIT_STATUS_INDEX_TYPECHANGE = (1u << 4),

    GIT_STATUS_WT_NEW = (1u << 7),
    GIT_STATUS_WT_MODIFIED = (1u << 8),
    GIT_STATUS_WT_DELETED = (1u << 9),
    GIT_STATUS_WT_TYPECHANGE = (1u << 10),
    GIT_STATUS_WT_RENAMED = (1u << 11),
    GIT_STATUS_WT_UNREADABLE = (1u << 12),

    GIT_STATUS_IGNORED = (1u << 14),
    GIT_STATUS_CONFLICTED = (1u << 15),
} git_status_t;

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

2. 详细方案

git_status_options opt = GIT_STATUS_OPTIONS_INIT;
git_status_list *statuses = nullptr;
size_t count = 0;

opt.flags = GIT_STATUS_OPT_DEFAULTS;
error = git_status_list_new(&statuses, rep, &opt);

count = git_status_list_entrycount(statuses);
std::cout << "count: " << count << std::endl;
for (size_t i = 0; i < count; ++i)
{
    const git_status_entry *entry = git_status_byindex(statuses, i);
    std::cout << "status: " << entry->index_to_workdir->status
    << "\tpath: " << entry->index_to_workdir->new_file.path << std::endl;
}

git_status_list_free(statuses);

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

typedef struct {
    git_status_t status;
    git_diff_delta *head_to_index;
    git_diff_delta *index_to_workdir;
} git_status_entry;

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