Git 底层架构完整解析一条 commit 命令的生命周期追踪【免费下载链接】gitGit Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.项目地址: https://gitcode.com/GitHub_Trending/gi/git按下 git commit 回车的那一刻进程里到底发生了什么在终端敲下git commit -m fix: init回车几十毫秒后一个新的提交哈希就打印出来了。但这期间Git 版本控制系统这个进程走的路并不短你的命令要先被认出名字、过一道环境契约检查最后才交给builtin/目录下同名函数执行。绝大多数情况下整个过程只跑一个进程、不 fork 任何子进程。下面我们就沿一次真实的git commit -m fix: init调用从进程启动走到返回结果看清每一棒是谁、传了什么参数、在哪里做了判断。 追踪一次调用从 argv 到 cmd_commitcmd_main先剥掉全局标志让 argv 只剩命令名真正的入口是 common-main.c 里的main它先调init_git(argv)完成全局初始化再把控制权交给 git.c 的cmd_main。cmd_main做的第一件事是归一化 argv。因为 git 这个二进制既能以git启动、也能以git-commit形式被直接执行所以如果 argv[0] 带git-前缀它会直接剥掉前缀、把剩余参数丢给内置命令处理器跳过后面所有查找逻辑。若是git command形式cmd_main接着调handle_options扫描参数。这个函数只认领--exec-path、--paginate这类全局标志并把它们从 argv 里摘走——目的是让后面的命令函数看到的 argv 只剩纯命令参数。--version和-v也在这里被归一化成version这个名字。get_builtin对静态命令表做线性扫描标志剥离完毕控制流进入run_argv的循环它先尝试handle_builtin。核心是get_builtin这个函数static struct cmd_struct *get_builtin(const char *s) { for (size_t i 0; i ARRAY_SIZE(commands); i) { if (!strcmp(s, (commands i)-cmd)) return commands i; } return NULL; }因为分发表是编译期就定死的静态数组commands[]查找就是一次线性 strcmp。找到commit后返回的结构体里装着函数指针cmd_commit和一串位标志option。若扫描落空run_argv并不立刻放弃它接着走execv_dashed_external尝试在 PATH 里执行一个叫git-%s的外部可执行文件。这就是 Git「内置命令优先、找不到再查 PATH」这条规则的代码出处。run_builtin位标志声明的环境契约命中之后、调用之前handle_builtin先用DUP_ARRAY复制了一份 argv——因为run_builtin允许原地修改 argv别名展开就可能发生在这一环原始数组必须还能自由释放。真正的关卡在run_builtin。它存在的理由是一百多个内置命令对环境的要求各不相同与其让每个命令各自重复检查「我在不在仓库里」不如在命令表里用位标志一次性声明。RUN_SETUP置位就调setup_git_directory定位.gitNEED_WORK_TREE再置位则补一次setup_work_tree检查。commit 注册的是RUN_SETUP | NEED_WORK_TREE所以在空目录里跑它会在这一步就报「not a git repository」。但这里有个细节在仓库外执行git commit -h时run_builtin检测到 -h 参数会把RUN_SETUP降级为RUN_SETUP_GENTLY——因此帮助页在非仓库目录也能正常显示。检查全部通过后它执行一句p-fn(argc, argv, prefix, repo)。注意prefix这个参数它是setup阶段返回的当前子目录相对路径稍后会被cmd_commit里的parse_options接收用来正确处理「在子目录里提交」的情况。关键代码剖析git.c 里的 cmd_struct 与 commands 数组整套分发机制浓缩在 git.c 的这两块里struct cmd_struct { const char *cmd; int (*fn)(int, const char **, const char *, struct repository *); unsigned int option; }; static struct cmd_struct commands[] { { add, cmd_add, RUN_SETUP | NEED_WORK_TREE }, { commit, cmd_commit, RUN_SETUP | NEED_WORK_TREE }, { clone, cmd_clone }, ... };cmd字段是拿来匹配的字符串所以git stage也能找到条目——它和add指向同一个cmd_add。fn字段固定了所有命令的统一签名剩余 argc/argv、工作树前缀 prefix、仓库结构体四个参数一个不多。option字段则是环境契约的声明处RUN_SETUP (10)、NEED_WORK_TREE (13)这些位常量定义在文件头部。clone一行没有任何标志这本身就在表达设计意图克隆仓库既不需要已存在的仓库也不需要工作树。表即 API。为什么这么设计静态表 vs 动态注册的取舍更「教科书」的做法是动态注册每个命令在初始化时把自己挂进哈希表查找 O(1)。Git 没选这条路因为内置命令数量是封闭的一百五十来个线性 strcmp 的开销相对毫秒级的启动时间可以忽略换来的好处是编译期链接——谁在builtin/里写了新命令却忘了在表里加一行这条命令就根本不可达编译不报错但行为清晰不存在「运行时注册失败」这种需要调试的中间态。整张表放在一个文件里也让审查者能一眼看全命令面。更大的取舍是「直接调用 vs 子进程」。默认路径下 Git 就在本进程直接调cmd_commit不 fork这正是git commit比 shell 脚本工具快的原因。但反例恰恰说明了规则一旦别名展开动过环境变量run_argv就拒绝直接调用内置函数改为 spawn 一个子进程git重跑整条命令。原因是当前进程已被别名的环境修改「污染」继续在本进程执行后续行为都可能受影响——源码注释坦然承认这是已知的妥协。可见「进程内还是跨进程」的边界是按环境状态的安全性划的不是按方便划的。⚡ 用 trace 机制亲手验证这条链路Git 在每次接力处都埋了 trace 点最直接的验证方式GIT_TRACE1 git commit -m test 21 | grep built-in你会看到一行trace: built-in: git——它由run_builtin在调p-fn前打印证明命令走的是内置路径而非 PATH 查找。想确认 dashed 回退目录再跑git --exec-path。若要对某个命令的环境契约做判断直接 grep git.c 里的命令名那一行的option字段就是它的全部声明。资源导航common-main.c真正的 main 与 init_git 初始化git.ccommands 命令表、get_builtin、run_builtinbuiltin/全部内置命令的实现文件Documentation/git.adocgit 顶层命令参考【免费下载链接】gitGit Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.项目地址: https://gitcode.com/GitHub_Trending/gi/git创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Git 底层架构完整解析：一条 commit 命令的生命周期追踪
Git 底层架构完整解析一条 commit 命令的生命周期追踪【免费下载链接】gitGit Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.项目地址: https://gitcode.com/GitHub_Trending/gi/git按下 git commit 回车的那一刻进程里到底发生了什么在终端敲下git commit -m fix: init回车几十毫秒后一个新的提交哈希就打印出来了。但这期间Git 版本控制系统这个进程走的路并不短你的命令要先被认出名字、过一道环境契约检查最后才交给builtin/目录下同名函数执行。绝大多数情况下整个过程只跑一个进程、不 fork 任何子进程。下面我们就沿一次真实的git commit -m fix: init调用从进程启动走到返回结果看清每一棒是谁、传了什么参数、在哪里做了判断。 追踪一次调用从 argv 到 cmd_commitcmd_main先剥掉全局标志让 argv 只剩命令名真正的入口是 common-main.c 里的main它先调init_git(argv)完成全局初始化再把控制权交给 git.c 的cmd_main。cmd_main做的第一件事是归一化 argv。因为 git 这个二进制既能以git启动、也能以git-commit形式被直接执行所以如果 argv[0] 带git-前缀它会直接剥掉前缀、把剩余参数丢给内置命令处理器跳过后面所有查找逻辑。若是git command形式cmd_main接着调handle_options扫描参数。这个函数只认领--exec-path、--paginate这类全局标志并把它们从 argv 里摘走——目的是让后面的命令函数看到的 argv 只剩纯命令参数。--version和-v也在这里被归一化成version这个名字。get_builtin对静态命令表做线性扫描标志剥离完毕控制流进入run_argv的循环它先尝试handle_builtin。核心是get_builtin这个函数static struct cmd_struct *get_builtin(const char *s) { for (size_t i 0; i ARRAY_SIZE(commands); i) { if (!strcmp(s, (commands i)-cmd)) return commands i; } return NULL; }因为分发表是编译期就定死的静态数组commands[]查找就是一次线性 strcmp。找到commit后返回的结构体里装着函数指针cmd_commit和一串位标志option。若扫描落空run_argv并不立刻放弃它接着走execv_dashed_external尝试在 PATH 里执行一个叫git-%s的外部可执行文件。这就是 Git「内置命令优先、找不到再查 PATH」这条规则的代码出处。run_builtin位标志声明的环境契约命中之后、调用之前handle_builtin先用DUP_ARRAY复制了一份 argv——因为run_builtin允许原地修改 argv别名展开就可能发生在这一环原始数组必须还能自由释放。真正的关卡在run_builtin。它存在的理由是一百多个内置命令对环境的要求各不相同与其让每个命令各自重复检查「我在不在仓库里」不如在命令表里用位标志一次性声明。RUN_SETUP置位就调setup_git_directory定位.gitNEED_WORK_TREE再置位则补一次setup_work_tree检查。commit 注册的是RUN_SETUP | NEED_WORK_TREE所以在空目录里跑它会在这一步就报「not a git repository」。但这里有个细节在仓库外执行git commit -h时run_builtin检测到 -h 参数会把RUN_SETUP降级为RUN_SETUP_GENTLY——因此帮助页在非仓库目录也能正常显示。检查全部通过后它执行一句p-fn(argc, argv, prefix, repo)。注意prefix这个参数它是setup阶段返回的当前子目录相对路径稍后会被cmd_commit里的parse_options接收用来正确处理「在子目录里提交」的情况。关键代码剖析git.c 里的 cmd_struct 与 commands 数组整套分发机制浓缩在 git.c 的这两块里struct cmd_struct { const char *cmd; int (*fn)(int, const char **, const char *, struct repository *); unsigned int option; }; static struct cmd_struct commands[] { { add, cmd_add, RUN_SETUP | NEED_WORK_TREE }, { commit, cmd_commit, RUN_SETUP | NEED_WORK_TREE }, { clone, cmd_clone }, ... };cmd字段是拿来匹配的字符串所以git stage也能找到条目——它和add指向同一个cmd_add。fn字段固定了所有命令的统一签名剩余 argc/argv、工作树前缀 prefix、仓库结构体四个参数一个不多。option字段则是环境契约的声明处RUN_SETUP (10)、NEED_WORK_TREE (13)这些位常量定义在文件头部。clone一行没有任何标志这本身就在表达设计意图克隆仓库既不需要已存在的仓库也不需要工作树。表即 API。为什么这么设计静态表 vs 动态注册的取舍更「教科书」的做法是动态注册每个命令在初始化时把自己挂进哈希表查找 O(1)。Git 没选这条路因为内置命令数量是封闭的一百五十来个线性 strcmp 的开销相对毫秒级的启动时间可以忽略换来的好处是编译期链接——谁在builtin/里写了新命令却忘了在表里加一行这条命令就根本不可达编译不报错但行为清晰不存在「运行时注册失败」这种需要调试的中间态。整张表放在一个文件里也让审查者能一眼看全命令面。更大的取舍是「直接调用 vs 子进程」。默认路径下 Git 就在本进程直接调cmd_commit不 fork这正是git commit比 shell 脚本工具快的原因。但反例恰恰说明了规则一旦别名展开动过环境变量run_argv就拒绝直接调用内置函数改为 spawn 一个子进程git重跑整条命令。原因是当前进程已被别名的环境修改「污染」继续在本进程执行后续行为都可能受影响——源码注释坦然承认这是已知的妥协。可见「进程内还是跨进程」的边界是按环境状态的安全性划的不是按方便划的。⚡ 用 trace 机制亲手验证这条链路Git 在每次接力处都埋了 trace 点最直接的验证方式GIT_TRACE1 git commit -m test 21 | grep built-in你会看到一行trace: built-in: git——它由run_builtin在调p-fn前打印证明命令走的是内置路径而非 PATH 查找。想确认 dashed 回退目录再跑git --exec-path。若要对某个命令的环境契约做判断直接 grep git.c 里的命令名那一行的option字段就是它的全部声明。资源导航common-main.c真正的 main 与 init_git 初始化git.ccommands 命令表、get_builtin、run_builtinbuiltin/全部内置命令的实现文件Documentation/git.adocgit 顶层命令参考【免费下载链接】gitGit Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.项目地址: https://gitcode.com/GitHub_Trending/gi/git创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考