Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.49.1 → 2.51.1 no changes
- 2.49.0 2025年03月14日
- 2.45.1 → 2.48.2 no changes
- 2.45.0 2024年04月29日
- 2.43.1 → 2.44.4 no changes
- 2.43.0 2023年11月20日
- 2.35.1 → 2.42.4 no changes
- 2.35.0 2022年01月24日
- 2.31.1 → 2.34.8 no changes
- 2.31.0 2021年03月15日
- 2.27.1 → 2.30.9 no changes
- 2.27.0 2020年06月01日
- 2.25.2 → 2.26.3 no changes
- 2.25.1 no changes
- 2.22.1 → 2.25.0 no changes
- 2.22.0 2019年06月07日
- 2.14.6 → 2.21.4 no changes
- 2.13.7 2018年05月22日
- 2.12.5 no changes
- 2.11.4 2017年09月22日
- 2.10.5 no changes
- 2.9.5 2017年07月30日
- 2.7.6 → 2.8.6 no changes
- 2.6.7 2017年05月05日
- 2.5.6 no changes
- 2.4.12 2017年05月05日
- 2.1.4 → 2.3.10 no changes
- 2.0.5 2014年12月17日
名称
git-commit-tree -创建一个新的提交对象
概述
git commit-tree <目录树> [(-p <父对象>)…] git commit-tree [(-p <父对象>)…] [-S[<keyid>]] [(-m <消息>)…] [(-F <文件>)…] <目录树>
描述
这通常不是最终用户想要直接运行的。 请参见 git-commit[1]。
根据提供的树对象创建新的提交对象,并将新的提交对象 id 发送到 stdout。除非给出 -m
或 `-F`选项,否则日志信息将从标准输入读取。
-m
和 -F
选项可以以任意顺序给出任意次数。提交日志信息将按照选项的顺序排列。
一个提交对象可以有任意数量的父对象。如果只有一个父对象,它就是一个普通的提交。如果有一个以上的父提交对象,提交就会在多行历史记录之间进行合并。初始(根)提交没有父对象。
树表示工作目录的特定目录状态,而提交则表示 "时间" 上的状态,并说明如何到达该状态。
通常情况下,一次提交会确定一个新的 "HEAD" 状态,虽然 Git 并不关心你把关于该状态的注释保存在哪里,但在实践中,我们倾向于把结果写入 .git/HEAD
指向的文件,这样我们就能随时看到上次提交的状态。
选项
- <目录树>
-
一个现有的目录树对象。
- -p <父提交>
-
每个
-p
表示父提交对象的 id。 - -m <信息>
-
提交日志信息中的一个段落。可以给出多个段落,每个 <信息> 都将成为自己的段落。
- -F <文件>
-
从给定文件中读取提交日志信息。使用
-
从标准输入读取。可以多次给定该文件,每个文件的内容都会成为自己的段落。 - -S[<keyid>]
- --gpg-sign[=<键 ID>]
- --no-gpg-sign
-
GPG 签名提交。
keyid
参数是可选的,默认为提交者身份;如果指定,必须与选项粘连,不能有空格。--no-gpg-sign
用于抵消命令行中先前给出的 `--gpg-sign`选项。
提交信息
一个提交封装了:
-
所有父对象 ID
-
作者姓名、电子邮件和日期
-
提交者姓名、电子邮件和提交时间。
提交注释从标准输入流读取。如果没有通过 "<" 重定向提供更新日志条目,git commit-tree 就会等待输入条目,并以 ^D 结束。
日期格式
GIT_AUTHOR_DATE
, GIT_COMMITTER_DATE
环境变量:
- Git 内部格式
-
<unix 时间戳> <时区偏移量>,其中 <unix 时间戳> 是自 UNIX epoch 以来的秒数。 <时区偏移量> 是相对于 UTC 的正或负偏移量。例如,CET(比 UTC 提前1小时)为
+0100
。 - RFC 2822
-
The standard date format as described by RFC 2822, for example
Thu,
07
Apr
2005
22:13:13
+0200
. - ISO 8601
-
按 ISO 8601 标准指定的时间和日期,例如
2005年04月07日T22:13:13
。解析器也接受空格代替T
字符。秒的小数部分将被忽略,例如2005年04月07日T22:13:13.019
将被视为2005年04月07日T22:13:13
。Note此外,日期部分还接受以下格式:YYYY.MM.DD
,MM/DD/YYYY
和DD.MM.YYYY
。
讨论
Git在某种程度上是与字符编码无关的。
-
blob对象的内容是未经解释的字节序列。 在核心层没有编码转换。
-
路径名以UTF-8规范化形式C编码,这适用于树对象、索引文件、参考名称,以及命令行参数、环境变量和配置文件(
.git/config
(见git-config[1]),gitignore[5],gitattributes[5] 和gitmodules[5])中的路径名。请注意,Git 在核心层将路径名简单地视为非 NUL 字节的序列,没有路径名编码的转换(除了 Mac 和 Windows)。因此,即使在使用传统的扩展ASCII编码的平台和文件系统上,使用非ASCII的路径名大多也能工作。然而,在这种系统上创建的仓库在基于UTF-8的系统(如Linux、Mac、Windows)上将无法正常工作,反之亦然。 此外,许多基于Git的工具简单地认为路径名称是UTF-8,而不能正确显示其他编码。
-
提交日志信息通常以UTF-8编码,但也支持其他扩展ASCII编码。这包括ISO-8859-x、CP125x和其他许多编码,但不包括UTF-16/32、EBCDIC和CJK多字节编码(GBK、Shift-JIS、Big5、EUC-x、CP9xx等)。
尽管我们鼓励提交日志信息使用UTF-8编码,但核心系统和Git Porcelain的设计并不强制要求项目使用UTF-8。 如果某个项目的所有参与者都认为使用传统编码更方便,Git也不会禁止。 然而,有几件事需要注意。
-
git
commit
andgit
commit-tree
issue a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to havei18n.commitEncoding
in.git/config
file, like this:[i18n] commitEncoding = ISO-8859-1
用上述设置创建的提交对象在它的
encoding
头中记录了i18n.commitEncoding
的值。 这是为了帮助以后看这些对象的人。 缺少这个头意味着提交日志信息是以 UTF-8 编码的。 -
git
log
,git
show
,git
blame
and friends look at theencoding
header of a commit object, and try to re-code the log message into UTF-8 unless otherwise specified. You can specify the desired output encoding withi18n.logOutputEncoding
in.git/config
file, like this:[i18n] logOutputEncoding = ISO-8859-1
如果你没有这个配置变量,则使用`i18n.commitEncoding`的值来代替。
请注意,我们特意选择在提交对象层面上,不对提交日志信息进行重新编码,因为重新编码为UTF-8不一定是一个可逆的操作。
文件
/etc/mailname
GIT
属于 git[1] 文档