企业官网建设流程全解析

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一、现象：同一条提交记录，作者和提交者不是同一个人

1.1 一条记录里挤着两个名字

把一个仓库 clone 下来，敲git log，很容易看到这样一行：

⚠️代码待验证

gitlog--format='A:%an <%ae> | C:%cn <%ce>'

输出长这样：A:Someone Else <fake@example.org> | C:Another Body <committer@example.org>。

第一次看到这种输出，多数人的第一反应是“我是不是看错了”，第二反应是“这两个人是不是同一个人被打印了两遍”。

都不是。这一行里出现的是两个不同的字段，碰巧被排在了同一行：前面是作者（author），后面是提交者（committer）。Git 给每一个都配了名字和邮箱，所以一条提交记录里一共有四个和身份有关的文本值。

日常提交时这四个值通常来自同一份配置，看起来完全一样，于是没人注意它们其实是分开的。直到某一天，你在别人的仓库里看到作者是张三、提交者是李四，才开始怀疑这中间是不是出了什么问题。

1.2 四个占位符，四个字段

这四个值都是普通字符串，写在提交对象里，跟着提交一起走。它们不加密、不校验、不和任何账号绑定。

顺带把一个容易混的地方先划清：本文讲的是提交身份，也就是“这条提交上写的名字是谁”。下载一个文件之后去核对校验和、核对发布签名，那是文件完整性，是另一条线上的事，本文不涉及。凭据被写进代码再提交上去，那是凭据管理，又是另一篇的事，本文也不涉及。

1.3 先给结论

**这两个字段都只是文本，不是凭证。**它们能被配置文件决定，也能被几条环境变量当场覆盖，甚至可以只改其中一个而不动另一个。

更直接的一句话，Git 自己的手册里就写着：This name has no effect on authentication。这句话在第五章会逐字展开。现在只需要先接受一个前提——提交记录里那个名字，证明不了“是谁写的”这件事。

那什么能证明？能证明的是签名，而签名默认没有人开。这是后面五章要走的路。

**本章可以带走的一句：**一条提交里有四个身份文本值，两个归作者、两个归提交者；它们都是字符串，不是身份证。

二、名字是从哪来的：四层优先级

2.1 手册把取值的顺序写死了

git-commit文档里有一节叫 COMMIT INFORMATION，开头第一句就把来源点了出来：

Author and committer information is taken from the following environment variables, if set:

后面列了六个变量：GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_AUTHOR_DATE、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL、GIT_COMMITTER_DATE，并且带了一句括注——(nb "<", ">" and "\n"s are stripped)。

这句括注值得停一下。它说的是：从这些变量里取到的值，会把尖括号和换行符剥掉。也就是说，Git 在这里做的是字符串清洗，不是身份核对。它关心的是“这个名字写进提交对象后，会不会把A U Thor <author@example.com>这个格式撑坏”，而不是“这个名字对应的是不是真人”。

六个变量分成两组，正好对上第一章的两组字段：AUTHOR那三个进作者，COMMITTER那三个进提交者。日期也是同理，作者日期和提交者日期是两个独立的值，这也解释了为什么一次 rebase 之后，两条时间线会不一致。

2.2 四层，一层比一层弱

环境变量不是唯一来源。手册紧接着给了完整的回落顺序：

In case (some of) these environment variables are not set, the information is taken from the configuration itemsuser.nameanduser.email, or, if not present, the environment variableEMAIL, or, if that is not set, system user name and the hostname used for outgoing mail

把这句话拆成表，就是四层：

这张表最要紧的不是“有四层”，而是每一层都没有验证动作。前两层是纯赋值，第三层是读一个环境变量，第四层更彻底——它压根不需要你参与，机器自己的用户名和主机名就能凑出一个身份。

第四层这一条经常被忽略。它意味着：在一个没有配过user.name的环境里提交，记录上出现的名字是系统用户名，邮箱是主机名拼出来的。这类提交在共享构建机、临时容器里特别常见。看到这种名字，不要理解成“有人用了这个化名”，要理解成“这里根本没人配过”。

2.3 第二层里面还套着一层

四层之外还有一个细节，手册单独用一句话交代：

Theauthor.nameandcommitter.nameand their corresponding email options overrideuser.nameanduser.emailif set and are overridden themselves by the environment variables.

意思是：author.name、committer.name这几个配置项如果存在，会压过user.name/user.email；但它们自己又会被环境变量压过。所以严格排起来，第二层其实是“仓库里能配的一切”，里面还分两小格。

这条细节的实际意义在于：作者和提交者可以从配置层面就被拆成两个人。不需要任何特殊操作，只要在配置里分别写上author.name和committer.name，一条普通提交出来就是两个不同的名字。

**本章可以带走的一句：**名字的取值是一条固定的回落链，环境变量 > 仓库配置 >EMAIL> 系统用户名与主机名；四层里没有一层在问“你是不是这个人”。

三、实测：三层覆盖谁压谁

3.1 实验怎么做的

下面的对照实验全部在自建测试仓库里完成，仓库是新建的空仓库，没有任何真实项目内容。用的名字是明显虚构的占位符，比如Fake Author <fake@x.org>，只为看字段怎么流动，不指向任何真实的人。

环境是git version 2.54.0 (Apple Git-157)，实测日期 2026-11-02。

3.2 环境变量压过仓库配置

第一步，先把仓库配置写成一对正常的值：

gitconfig user.name"Real Person"gitconfig user.email"real@example.com"gitconfig--getuser.namegitconfig--getuser.email

配置里现在是Real Person和real@example.com。然后在提交时，用环境变量把四个身份值全部换掉：

GIT_AUTHOR_NAME="Someone Else"\GIT_AUTHOR_EMAIL=fake@example.org\GIT_COMMITTER_NAME="Another Body"\GIT_COMMITTER_EMAIL=committer@example.org\gitcommit-m"identity override test"gitlog-1--format='A:%an <%ae> | C:%cn <%ce>'

git log显示的结果是一行A:Someone Else <fake@example.org> | C:Another Body <committer@example.org>。

仓库配置里明明写着Real Person <real@example.com>，输出里一个字都没剩，与配置里的身份完全无关。四个环境变量各自找到了自己的位置，作者归作者、提交者归提交者，没有任何一个被“纠正”回配置里的值。

3.3--author只压作者

第二步换一种方式，不动环境变量，改用--author：

gitcommit--author="Fake Author <fake@x.org>"-m"author override test"gitlog-1--format='A:%an <%ae> | C:%cn <%ce>'

结果是A:Fake Author <fake@x.org> | C:Real Person <real@example.com>。

只有作者变了，提交者还是配置里的Real Person。这个行为和手册对--author的描述一致：

Override the commit author. Specify an explicit author using the standardA U Thor author@example.comformat.

注意原文只说 Override the commitauthor，没有一个字提到 committer。这个选项在设计上就只碰一半。

3.4 把两次实测并排放

四次对照下来，得到一个很朴素的观察：这四个值的位置是固定的，来源是可替换的，替换过程没有任何一道关卡。

值得说清楚的是这个实验的性质。它演示的是“取值链如何工作”，不是“如何冒充别人”。两者的区别很实在：前者关心的是字段从哪里来，后者关心的是让别人相信某个字段。本文只做前者，也只写前者。

还有一点，实验里之所以能这么写，是因为仓库是自己的、提交是自己的。换成任何一个不属于你的仓库，这段操作的性质立刻就变了，和本文讨论的技术问题无关。

**本章可以带走的一句：**环境变量压过配置，--author只压作者；三层覆盖关系里，没有一层在做校验。

四、作者与提交者是两件事

4.1 两个字段回答两个不同的问题

作者字段回答的是：这段改动的内容是谁写的。

提交者字段回答的是：这条提交是谁创建出来、放进历史的。

日常提交时这两个问题的答案是同一个人，所以字段一样。但这两个问题本来就可以有不同的答案，Git 从设计上就允许它们分开——否则没必要存两份。

这也是为什么第二章那句关于author.name/committer.name的覆盖规则会存在。有这条规则，说明“作者和提交者是两个人”在 Git 眼里是正常工况，不是异常。

4.2 什么时候会分开

分开的场合比想象中多，而且大多数是日常工作里主动做的：

**变基（rebase）。**把一条提交搬到新的基底上，Git 会重新创建这条提交。重放之后，作者保留原样，提交者变成执行变基的人。所以一次变基做下来，历史里会多出一批“作者是原来的作者、提交者是操作者”的提交。

**拣选（cherry-pick）。**把某个提交单独摘到当前分支，同样是重新创建。作者不变，提交者是你。

**应用补丁。**收到一个 patch 文件再应用，作者信息来自补丁里带的那个作者字段，提交者是你这台机器上配的身份。这也是为什么开源项目里经常能看到“作者是贡献者、提交者是维护者”的记录——维护者把补丁收进主干，提交者自然就换成了维护者。

**修补（amend）。**改提交信息或者补一个漏掉的文件，本质上是丢掉旧提交、造一个新提交。作者可以保持不变，提交者是重新执行的人。

这四种操作的共同点是：**内容的所有权和历史的写入权被分开了。**Git 用两个字段分别记录，而不是强行合成一个。

4.3 为什么“别人的提交挂在我名下”

理解了 4.2，那个让初学者困惑很久的现象就有解释了。

你 rebase 了一遍别人写的分支，跑完之后git log里全是你的名字——但那是提交者字段，作者字段还是原来的人。反过来，你写的提交被维护者 cherry-pick 进了主干，作者是你，提交者是维护者。

两种情形都不是“身份被篡改”，是“两个字段本来就记两件事”。真正需要警惕的不是字段不一致，而是有人把字段不一致当成异常，进而用作者字段去下“这段代码是谁写的”这种结论。

审计时这个区别很实用：作者字段说明内容来源，提交者字段说明历史是怎么形成的。两个都要看。

**本章可以带走的一句：**作者记内容归属，提交者记历史写入；rebase、cherry-pick、打补丁都会让这两件事分开，这是设计，不是事故。

五、名字不参与认证，那什么才参与

5.1 手册那句话

第二章引用过取值的回落链，这里要引的是同一节里更关键的一段：

The author and committer names are by convention some form of a personal name (that is, the name by which other humans refer to you), although Git does not enforce or require any particular form. Arbitrary Unicode may be used, subject to the constraints listed above. This name has no effect on authentication; for that, see thecredential.usernamevariable in git-config[1].

这段话有三个层次，值得一句一句拆。

第一层，by convention——按惯例，这里应该写一个别人认得出你的名字。惯例，不是规则。

第二层，Git does not enforce or require any particular form——Git 不强制、也不要求任何特定形式。紧接着一句Arbitrary Unicode may be used，任意 Unicode 都行，只要满足前面那几条字符清洗的约束。换句话说，这个字段对内容几乎不设限。

第三层，也是整段的核心：This name has no effect on authentication。这个名字对认证没有任何作用。没有“在某些情况下”这种前缀，就是一句直的否定。

最后半句给了一个指向：如果要做认证，去看credential.username。它管的是“连服务器时用哪个账号”，和提交对象里那两行文本不是一回事。手册把这两件事明确分开了。

5.2 参与认证的不是名字，是签名

名字不参与认证，那提交这一层还剩什么？剩签名。

git-commit文档里关于签名的选项写得很短：

GPG-sign commits. The is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.--no-gpg-signis useful to countermand bothcommit.gpgSignconfiguration variable, and earlier--gpg-sign.

这段里有三个信息点：

一是-S和--gpg-sign是同一个东西的两个写法，作用是给提交签名。

二是<key-id>是可选的，不写的时候默认用提交者身份去挑密钥。签名和身份之间靠的是本机的私钥，不是名字。

三是--no-gpg-sign能反向抵消commit.gpgSign配置和之前写的--gpg-sign。签名可以逐条覆盖。

还有一个配置项管默认值：

A boolean to specify whether all commits should be GPG signed.

commit.gpgSign是个布尔值，管的是“是不是所有提交都签”。

5.3 默认状态是“没开”

理论说完，看这台机器的实际状态：

gitconfig--global--getgpg.formatgitconfig--global--getcommit.gpgsign

两条命令都没有输出。也就是说，截至 2026-11-02，这台机器上gpg.format和commit.gpgsign都是未设置状态，它默认不做任何提交签名。

这个结果不特殊，反而很典型。签名是一个需要主动打开的开关，而且要打开它，前提是本地先有可用的密钥材料。在没配过的机器上，一条提交从生成到推送，全程只有文本，没有任何密码学意义上的凭证跟着走。

所以第五章的结论可以压成一句：名字不参与认证，签名参与认证，而签名默认关闭。

这个顺序很重要。很多人对提交记录的信任来自“我看到上面有名字”，而名字恰好是四层回落链自动填进去的、最不需要本人参与的那一部分。

配套资料：Git 身份与签名对照卡：把四层取值优先级、作者与提交者的分离场景、签名相关配置项整理成一页对照表，配着本文第二章到第五章看，遇到“这个名字哪来的”能直接对上号。放在资料包里，扫码即可获取：

六、怎么核一条提交到底是谁的

6.1 路一：把两组字段对着看

第一条路最便宜，不需要任何额外工具：同时取四个字段，看作者和提交者是不是同一个身份。用的还是第一章那条格式串，前面加一个%h取短哈希，方便和远端记录对上。

看的时候有三个关注点。

一看两组是否一致。一致说明这条提交从写到入库是同一个人在同一台机器上完成的，这是最常见的形态，也是“看起来最正常”的形态。不一致不代表有问题，第四章列的那四种操作都会造成不一致。

二看是否与预期的人对得上。比如你在核一个依赖仓库，维护者说这条修复是某人提交的，那作者字段应该指向那个人；如果作者字段是一个第一次出现的陌生名字，就值得再问一句这条提交是怎么进来的。

三看提交者是不是维护者。在正常的协作流里，外部贡献者的提交被合入时，提交者往往是维护者。这个规律反过来用也成立：如果一条提交的作者是维护者、提交者是一个从没出现过的身份，那这条提交进入历史的方式就值得追一下。

需要提醒的是，git log --author=这类过滤只按文本匹配，它能筛出“作者字段写了某个名字”的提交，不能筛出“某个人做的”提交。这两句话差得很远。

6.2 路二：看有没有签名

第二条路是看签名。git log可以带上签名展示，git verify-commit可以单独判定一条提交的签名。

⚠️代码待验证

gitlog --show-signature-1gitverify-commit HEAD

这两条命令本文没有在本机实际跑过（这台机器没有配置签名环境），命令形态按 Git 的常规用法给出，具体输出以你的环境为准。

两者的分工要说清楚：git log --show-signature是展示，把签名状态打印在日志旁边；git verify-commit是判定，它的返回值直接说明这条提交的签名是否有效。做核查的时候，前者适合快速扫一遍历史，后者适合对单条提交下结论。

还有一个前提：没有签名也是一种结果。一条提交没有签名，不等于它有问题，只等于“这一层没有信息可用”。真正需要区分的是三种状态——签名有效、签名存在但校验不过、根本没有签名。第三种最常见，因为默认就是没开。

6.3 路三：看远端和平台侧的记录

第三条路在本地之外。一条提交是怎么进入远端的，远端那边有记录：推送记录、合并记录、受保护分支上的操作记录。这些记录不依赖提交对象里的文本，而是平台侧对“谁做了什么”的记账。

这条路的价值在于它是另一个来源。前两条路读的都是提交对象自身携带的内容，而提交对象是可以被重新创建、重新写入的；平台侧的记录是另一套数据，两边对不上，就是需要解释的地方。

托管平台对“未签名提交”的展示方式各家不同，截至 2026-11-02 这一点标待验证，本文不写具体界面。

三行合起来看，会发现一个共同的边界：**没有一条路能单独回答“这是谁写的”。**能回答的是“这条提交是怎么形成的、有没有凭证、从哪进来的”。审计要的是后者，不是前者。

6.4 关于 SSH 签名

除了 GPG 签名，还有一条用 SSH 密钥签名的路。走gpg.format=ssh这条路时对应的开关名与用法，本文没有实测（本机未配置），标待验证，这里不给步骤。

只提醒一点：不管用哪种密钥，签名的语义是一样的——签的是“持有这把私钥的一方创建了这条提交”，不是“这条提交的作者字段是真实的”。名字和签名解决的是两个不同的问题。

**本章可以带走的一句：**字段看路径、签名看凭证、远端看来源；三条路都走一遍，才能说清一条提交是怎么来的。

七、把它放回安全语境

7.1 一条提交记录能证明什么

把前面六章的话放到依赖场景里，结论会变得很具体。

你引入一个第三方仓库，翻它的提交历史，看到一堆名字。这些名字能证明的事情只有一件：这条提交对象里，作者字段和提交者字段写的是这两串字符，并且这条提交参与了当前这段历史的构造。

它们不能证明的事情有一串：不能证明写代码的人真的是那个名字，不能证明这条提交没有被重新创建过，不能证明仓库里的源码和发布出来的产物是同一份，也不能证明这段代码在被你 clone 之前没被动过。

这个落差是很多供应链问题的起点。信任往往建立在“历史看起来很正规”这个观感上——提交多、作者眼熟、时间线连贯——而这些观感全部由可以自由写入的文本构成。真正有密码学意义的只有签名那一层，而它默认是关的。

顺带把边界再说一次：本文讲的是提交身份，不是文件完整性。下载一个发布包之后核对校验和与签名，回答的是“这个文件有没有被换过”，和“这条提交是谁写的”是两个问题，用的也是两套材料。

7.2 自查清单

拿到一个仓库、或者要给一段历史下结论之前，按这七条过一遍：

1. **看两组字段是否齐全。**作者和提交者都要取，只取一组等于只看了一半。
2. **看提交者是不是“预期的那个人”。**协作流里提交者通常是合入方，如果长期是陌生身份，需要解释。
3. **看有没有签名，而不是看有没有名字。**名字默认就有，签名默认没有。
4. **区分“没签名”和“签名无效”。**前者是缺信息，后者是信息对不上，处理方式完全不同。
5. **核对远端记录。**本地git log只是一份副本，推送和合并的记录在平台侧。
6. **不要用作者字段推断代码归属。**rebase、cherry-pick、打补丁都会让两个字段分开，这是正常工况。
7. **把“名字”和“账号”分开看。**提交里的名字是文本，登录用的账号是另一套机制，手册指向的是credential.username。

七条里最容易跳过的是第三条和第六条：名字太显眼，显眼到让人以为它就是凭证；字段不一致看着像异常，可它多数时候只是操作留下的痕迹。

7.3 三条边界

第一，本文只讲机制和核查，不涉及任何让身份字段指向他人的做法。前面第三章的实测全部在自己的测试仓库里完成，用的是明显虚构的占位名，目的是看字段怎么流动。

第二，本文不涉及工作区状态管理、子模块与 LFS 那几块内容，也不涉及凭据写进代码之后的处置流程，那些是另外的题目。

第三，结论只管测过的环境。实测环境是 macOS 本机、git version 2.54.0 (Apple Git-157)、2026-11-02；平台侧的展示方式、SSH 签名的开关名，本文都标了待验证。能跨环境复用的只有那条判断顺序：先看字段，再看签名，最后看远端。

配套资料：提交核查七步清单：把本章的七条自查项做成一张可以打印的清单，每条后面附上对应的命令或观察点，排查依赖仓库时照着走。放在资料包里，扫码即可获取：

附表 A：本文引用事实与官方出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把本机的 Git 身份取值链一层层试了一遍，顺手也整理了几份配套的东西：

• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看环境对照表那一份，先把本机的取值链和签名状态量清楚，再谈信任。