| Jul | AUG | Sep |
| 26 | ||
| 2020 | 2021 | 2022 |
COLLECTED BY
Collection: Wikipedia Eventstream
●
About
●
Branching and Merging
●
Small and Fast
●
Distributed
●
Data Assurance
●
Staging Area
●
Free and Open Source
●
Trademark
●
Documentation
●
Reference
●
Book
●
Videos
●
External Links
●
Downloads
●
GUI Clients
●
Logos
●
Community
English ▾
03/15/21
(三)2.27.1 → 2.30.2 no changes
(四)
2.27.0
06/01/20
(五)2.25.2 → 2.26.3 no changes
(六)
2.25.1
02/17/20
(七)2.22.1 → 2.25.0 no changes
(八)
2.22.0
06/07/19
(九)2.14.6 → 2.21.4 no changes
(十)
2.13.7
05/22/18
(11)2.12.5 no changes
(12)
2.11.4
09/22/17
(13)2.10.5 no changes
(14)
2.9.5
07/30/17
(15)2.7.6 → 2.8.6 no changes
(16)
2.6.7
05/05/17
(17)2.5.6 no changes
(18)
2.4.12
05/05/17
(19)
Check your version of git by running
git --version
git commit-tree <tree> [(-p <parent>)…]
git commit-tree [(-p <parent>)…] [-S[<keyid>]] [(-m <message>)…]
[(-F <file>)…] <tree>
-mor-F options are given.
The -m and -F options can be given any number of times, in any
order. The commit log message will be composed in the order in which
the options are given.
A commit object may have any number of parents. With exactly one
parent, it is an ordinary commit. Having more than one parent makes
the commit a merge between several lines of history. Initial (root)
commits have no parents.
While a tree represents a particular directory state of a working
directory, a commit represents that state in "time", and explains how
to get there.
Normally a commit would identify a new "HEAD" state, and while Git
doesn’t care where you save the note about that state, in practice we
tend to just write the result to the file that is pointed at by
.git/HEAD, so that we can always see what the last committed
state was.
-p indicates the id of a parent commit object.
-m <message>
A paragraph in the commit log message. This can be given more than
once and each <message> becomes its own paragraph.
-F <file>
Read the commit log message from the given file. Use - to read
from the standard input. This can be given more than once and the
content of each file becomes its own paragraph.
-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign
GPG-sign commits. The keyid argument is optional and
defaults to the committer identity; if specified, it must be
stuck to the option without a space. --no-gpg-sign is useful to
countermand a --gpg-sign option given earlier on the command line.
GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables
support the following date formats:
Git internal format
It is <unix timestamp> <time zone offset>, where <unix
timestamp> is the number of seconds since the UNIX epoch.
<time zone offset> is a positive or negative offset from UTC.
For example CET (which is 1 hour ahead of UTC) is +0100.
RFC 2822
The standard email format as described by RFC 2822, for example
Thu, 07 Apr 2005 22:13:13 +0200.
ISO 8601
Time and date specified by the ISO 8601 standard, for example
2005-04-07T22:13:13. The parser accepts a space instead of the
T character as well. Fractional parts of a second will be ignored,
for example 2005-04-07T22:13:13.019 will be treated as
2005-04-07T22:13:13.
|
Note
|
In addition, the date part is accepted in the following formats:
YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
|
.git/config (see git-config[1]),
gitignore[5], gitattributes[5] and
gitmodules[5]).
Note that Git at the core level treats path names simply as
sequences of non-NUL bytes, there are no path name encoding
conversions (except on Mac and Windows). Therefore, using
non-ASCII path names will mostly work even on platforms and file
systems that use legacy extended ASCII encodings. However,
repositories created on such systems will not work properly on
UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa.
Additionally, many Git-based tools simply assume path names to
be UTF-8 and will fail to display other encodings correctly.
Commit log messages are typically encoded in UTF-8, but other
extended ASCII encodings are also supported. This includes
ISO-8859-x, CP125x and many others, but not UTF-16/32,
EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5,
EUC-x, CP9xx etc.).
Although we encourage that the commit log messages are encoded
in UTF-8, both the core and Git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, Git
does not forbid it. However, there are a few things to keep in
mind.
git commit and git commit-tree issues
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
have i18n.commitEncodingin.git/config file, like this:
[i18n] commitEncoding = ISO-8859-1Commit objects created with the above setting record the value of
i18n.commitEncoding in its encoding header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
git log, git show, git blame and friends look at the
encoding 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 with
i18n.logOutputEncodingin.git/config file, like this:
[i18n] logOutputEncoding = ISO-8859-1If you do not have this configuration variable, the value of
i18n.commitEncoding is used instead.
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
reversible operation.