?
This document uses PHP Chinese website manual Release
git-commit - 記錄對存儲庫的更改
git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C | --fixup | --squash) <commit>] [-F <file> | -m <msg>] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=<author>] [--date=<date>] [--cleanup=<mode>] [--[no-]status] [-i | -o] [-S[<keyid>]] [--] [<file>…]
在新提交中存儲索引的當前內(nèi)容以及來自描述更改的用戶的日志消息。
要添加的內(nèi)容可以通過幾種方式指定:
通過git add
在使用commit
命令之前使用增量“增加”索引更改(注意:即使修改過的文件也必須“添加”);
2. 通過git rm
刪除從工作樹和索引文件,再次使用前commit
命令;
3 . 通過將文件列為參數(shù)commit
(不帶--interactive或--patch開關(guān)),在這種情況下,提交將忽略在索引中執(zhí)行的更改,而是記錄列出的文件的當前內(nèi)容(必須已知GIT);
4 . 通過使用帶commit
命令的-a開關(guān)自動從所有已知文件(即索引中已列出的所有文件)中“添加”更改,并自動從索引中刪除工作樹中的“rm”文件,然后執(zhí)行實際提交;
5. 通過使用--interactive或--patch開關(guān)和commit
命令,在完成操作之前,除索引中的內(nèi)容之外,逐個決定哪些文件或塊應(yīng)該是提交的一部分。請參閱git-add [1]的“交互模式”部分了解如何操作這些模式。該--dry-run
選項可用于通過給出相同的一組參數(shù)(選項和路徑)。如果你提交了一個提交,然后在那之后立即發(fā)現(xiàn)一個錯誤,你可以用它來恢復(fù)git reset
.Options -a --all告訴命令自動對已被修改和刪除的文件進行分段,但沒有告知Git的新文件不受影響。-p --patch使用交互式補丁選擇界面來選擇要提交的更改。有關(guān)詳細信息,請參閱git-add [1]。-C <commit> --reuse-message = <commit>取一個現(xiàn)有的提交對象,并在創(chuàng)建提交時重用日志消息和作者信息(包括時間戳)。-c <commit> --reedit-message = <commit>好像-C
,但是-c
調(diào)用了編輯器,以便用戶可以進一步編輯提交消息。--fixup = <commit>構(gòu)造一個提交消息以供使用rebase --autosquash
。提交消息將成為指定提交的主題行,其前綴為“fixup!”。有關(guān)詳細信息,請參閱git-rebase [1]。--squash = <commit>構(gòu)造一個提交消息以供使用rebase --autosquash
。提交消息主題行取自指定的提交,前綴為“squash!”??梢耘c其他提交消息選項(-m
/ -c
/ -C
/ -F
)一起使用。有關(guān)詳細信息,請參閱git-rebase [1]。--reset-author當與-C / -c / - 修改選項一起使用時,或者在沖突櫻桃挑選后提交時,聲明結(jié)果提交的作者現(xiàn)在屬于提交者。這也會更新作者的時間戳。 - short當進行干運行時,以短格式輸出輸出。有關(guān)詳細信息,請參閱git-status [1]。暗示--dry-run
。--branch甚至以短格式顯示分支和跟蹤信息。 - 陶瓷當進行干式運行時,請以陶瓷準備好的格式輸出。有關(guān)詳細信息,請參閱git-status [1]。意味著--dry-run
。 - 長時間運行時,以長格式輸出。意味著--dry-run
。-z --null當顯示short
或porcelain
狀態(tài)輸出時,逐字打印文件名并用NUL而不是LF結(jié)束輸入。如果沒有給出格式,則表示--porcelain
輸出格式。如果沒有這個-z
選項,帶有“不尋?!弊址奈募麑凑张渲米兞康恼f明引用core.quotePath
(請參閱git-config [1])。-F <file> --file = <file>從給定文件中獲取提交消息。使用-
從標準輸入讀取消息。--author = <author>覆蓋提交作者。使用標準A U Thor <author@example.com>
格式指定明確的作者。否則<author>被認為是一個模式,用于搜索該作者現(xiàn)有的提交(即rev-list --all -i --author = <author>); 然后從第一個找到的提交中復(fù)制提交作者。--date = <date>覆蓋提交中使用的作者日期。-m <msg> --message = <msg>使用給定的<msg>作為提交消息。如果-m
給出了多個選項,則它們的值被連接為單獨的段落。-t <file> --template = <file>編輯提交信息時,用給定文件中的內(nèi)容啟動編輯器。該commit.template
配置變量通常用于隱式地將該選項賦予命令。這種機制可以被那些想要引導(dǎo)參與者提供什么信息以什么順序?qū)懺谙⒅械陌凳镜捻椖渴褂?。如果用戶退出編輯器而不編輯消息,則提交將中止。當通過其他方式給出消息時,例如使用-m
或-F
選項,這不起作用。-s --signoff在提交日志消息結(jié)尾添加Sign-off-by行。簽名的含義取決于項目,但它通常證明提交者有權(quán)根據(jù)相同的許可證提交此項工作,并同意開發(fā)者原始證書(參見http://developercertificate.org/)。了解更多信息)。-n --no-verify這個選項繞過預(yù)先提交和提交msg鉤子。另見githooks [5]。--allow-empty通常記錄與其唯一父提交完全相同的提交是一個錯誤,并且該命令阻止您進行此類提交。此選項繞過安全性,主要供外國SCM接口腳本使用。--allow-empty-message與--allow-empty一樣,此命令主要供外部SCM接口腳本使用。它允許你使用空的提交消息創(chuàng)建一個提交,而不使用像git-commit-tree [1]這樣的管道命令。--cleanup = <mode>該選項確定在提交之前應(yīng)如何清理提供的提交消息。該<mode>
可strip
,whitespace
,verbatim
,scissors
或者default
。帶剝離前導(dǎo)和尾隨空行,尾隨空白,評論和折疊連續(xù)的空行??崭衽c#strip
注釋相同,不會被刪除。逐字不要改變信息。剪刀whitespace
除了從下面找到的行(包括下面的行)中的所有內(nèi)容被截斷之后,如果要編輯的消息都一樣。“ #
”可以用core.commentChar自定義。#------------------------> 8 ------------- ----------- default與strip
消息編輯相同。否則whitespace
。默認值可以通過commit.cleanup
配置變量進行更改(請參閱git-config [1])。-e --edit從文件中提取的消息-F
,命令行-m
和從提交對象中提取的消息-C
通常用作未修改的提交日志消息。該選項可讓您進一步編輯從這些源獲取的消息。--no-edit在不啟動編輯器的情況下使用選定的提交消息。例如,git commit --amend --no-edit
修改提交而不更改其提交消息。--amend通過創(chuàng)建一個新的提交來替換當前分支的提示。記錄的樹像往常一樣準備(包括-i
和-o
選項和顯式pathspec的效果),并且當從命令行中未指定其他消息時,將使用原始提交的消息作為起點,而不是空消息通過選項,如-m
,-F
,-c
,等新犯有相同的父母和作者作為當前一個(在--reset-author
選項可以反制這個)。它是一個粗略的等價物:$ git reset --soft HEAD ^ $ ...做一些其他的事情來得到正確的樹... $ git commit -c ORIG_HEADbut可以用來修改一個合并提交。如果您修改已發(fā)布的提交,您應(yīng)該了解重寫歷史記錄的含義。(請參閱git-rebase [1]中的“從上行鏈路重新啟動”部分)。--no-post-rewrite繞過重寫后掛鉤。-i --include在到目前為止的階段性內(nèi)容提交之前,還要在命令行上給出路徑的內(nèi)容。這通常不是你想要的,除非你正在完成一個沖突的合并。-o - 僅通過獲取命令行中指定路徑的更新工作樹內(nèi)容來進行提交,無視任何已經(jīng)為其他路徑上演的內(nèi)容。這是默認的操作模式git commit
如果在命令行上給出了任何路徑,在這種情況下,該選項可以省略。如果此選項與“一起指定” --amend
,則不需要指定任何路徑,可以使用這些路徑修改上次提交而不提交已經(jīng)執(zhí)行的更改。如果與--allow-empty
路徑一起使用也不是必需的,并且將創(chuàng)建一個空的提交。-u <mode> --untracked-files = <mode>顯示未跟蹤的文件。模式參數(shù)是可選的(默認為all
),用于指定處理未跟蹤的文件; 當-u未使用時,默認值是normal
,即顯示未跟蹤的文件和目錄??赡艿倪x項是:
no
- 不顯示未跟蹤的文件
normal
- 顯示未跟蹤的文件和目錄
all
- 還顯示未跟蹤目錄中的單個文件。
可以使用git-config [1]中記錄的status.showUntrackedFiles配置變量來更改默認值。
-v --verbose
顯示HEAD提交與提交消息模板底部提交的內(nèi)容之間的統(tǒng)一差異,以幫助用戶通過提醒提交具有哪些更改來描述提交。請注意,此差異輸出的前面沒有前綴#
。這個差異不會是提交消息的一部分。請參閱commit.verbose
git-config [1]中的配置變量。
如果指定了兩次,則另外顯示將提交的內(nèi)容和工作文件之間的統(tǒng)一差異,即對被跟蹤文件的未分離更改。
-q --quiet
Suppress commit summary message.
--dry-run
不要創(chuàng)建提交,而是顯示要提交的路徑列表,包含未提交的本地更改的路徑以及未跟蹤的路徑。
--status
使用編輯器準備提交消息時,在提交消息模板中包含git-status [1]的輸出。默認為打開,但可用于覆蓋配置變量commit.status。
--no-status
使用編輯器準備默認提交消息時,不要在提交消息模板中包含git-status [1]的輸出。
-S<keyid> --gpg-sign=<keyid>
GPG標志提交keyid
參數(shù)是可選的,并且默認為提交者身份; 如果指定,它必須粘貼到選項沒有空格。
--no-gpg-sign
commit.gpgSign
設(shè)置為強制每個提交進行簽名的計數(shù)器配置變量。
--
不要將更多的參數(shù)解釋為選項。
<file>…
當在命令行上給出文件時,命令將提交指定文件的內(nèi)容,而不記錄已經(jīng)執(zhí)行的更改。這些文件的內(nèi)容也將在下一次提交之前進行演示。
GIT_AUTHOR_DATE
,GIT_COMMITTER_DATE
環(huán)境變量和--date
選項支持以下日期格式:
Git內(nèi)部格式
這是<unix timestamp> <time zone offset>
,在這里<unix timestamp>
是從unix新紀元的秒數(shù)。<time zone offset>
是UTC的正數(shù)或負數(shù)偏移量。例如CET(比UTC早1小時)是+0100
。
RFC 2822
例如,RFC 2822所描述的標準電子郵件格式Thu, 07 Apr 2005 22:13:13 +0200
。
ISO 8601
例如,ISO 8601標準規(guī)定的時間和日期2005-04-07T22:13:13
。解析器也接受一個空格而不是T
字符。
Note | In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY. |
---|
在錄制自己的作品時,工作樹中修改文件的內(nèi)容將臨時存儲到一個名為“index”的臨時區(qū)域中git add
。一個文件只能在索引中恢復(fù),但不能在工作樹中git reset HEAD -- <file>
恢復(fù)為最后一次提交的文件,這會有效地恢復(fù)git add
并阻止對該文件的更改參與下一次提交。在使用這些命令構(gòu)建要逐步提交的狀態(tài)之后,git commit
(不帶任何路徑名參數(shù))用于記錄迄今為止已執(zhí)行的操作。這是命令的最基本形式。一個例子:
$ edit hello.c $ git rm goodbye.c $ git add hello.c $ git commit
不要在每個單獨更改之后登臺文件,而是git commit
要注意對在工作樹中跟蹤內(nèi)容的文件進行更改,git add
并git rm
為您做相應(yīng)的工作。也就是說,如果工作樹中沒有其他更改,則此示例與前面的示例執(zhí)行的操作相同:
$ edit hello.c $ rm goodbye.c $ git commit -a
命令git commit -a
首先查看您的工作樹,注意到您修改了hello.c并刪除了goodbye.c,并執(zhí)行了必要的操作git add
并git rm
為您執(zhí)行。
在更改許多文件之后,您可以通過提供路徑名來更改記錄更改的順序git commit
。當給出路徑名時,命令進行提交,只記錄對指定路徑所做的更改:
$ edit hello.c hello.h $ git add hello.c hello.h $ edit Makefile $ git commit Makefile
這使得提交記錄修改Makefile
。所做的更改已進行hello.c
并且hello.h
未包含在結(jié)果提交中。然而,他們的變化并沒有失去 - 他們?nèi)匀簧涎?,只是被阻止。在上述順序之后,如果你這樣做:
$ git commit
第二次提交會記錄更改hello.c
并按hello.h
預(yù)期進行。
合并后(由git merge
or 發(fā)起git pull
)由于沖突而停止,干凈合并的路徑已經(jīng)分階段為您提交,并且發(fā)生沖突的路徑處于未合并狀態(tài)。您必須首先檢查哪些路徑與git status
您的工作樹中的手動修復(fù)沖突,然后像往常一樣分階段執(zhí)行結(jié)果git add
:
$ git status | grep unmerged unmerged: hello.c $ edit hello.c $ git add hello.c
解決沖突并分級后,git ls-files -u
會停止提及沖突的路徑。完成后,運行git commit
以最終記錄合并:
$ git commit
與記錄您自己的更改的情況一樣,您可以使用-a
選項來保存輸入。一個區(qū)別是,在合并解析期間,不能使用git commit
路徑名來更改提交更改的順序,因為合并應(yīng)該記錄為單個提交。事實上,命令在給定路徑名時拒絕運行(但請參閱-i
選項)。
雖然不是必需的,但最好先用一個簡短的(少于50個字符)行來概述變化,然后再用空行和更徹底的描述來開始提交消息。直到提交消息中的第一個空行的文本被視為提交標題,并且該標題在整個Git中使用。例如,git-format-patch [1]將提交轉(zhuǎn)換為電子郵件,并使用主題行上的標題和正文中的其余提交。
Git在某種程度上是字符編碼不可知的。
blob對象的內(nèi)容是未解釋的字節(jié)序列。在核心層面沒有編碼翻譯。
路徑名以UTF-8標準化形式C編碼。這適用于樹對象,索引文件,ref名稱,以及命令行參數(shù),環(huán)境變量和配置文件中的路徑名.git/config
(請參閱git-config [1]) ,gitignore [5],gitattributes [5]和gitmodules [5])。
請注意,核心級Git將路徑名視為非NUL字節(jié)序列,不存在路徑名編碼轉(zhuǎn)換(Mac和Windows除外)。因此,即使在使用傳統(tǒng)擴展ASCII編碼的平臺和文件系統(tǒng)上,使用非ASCII路徑名也可以工作。但是,在這些系統(tǒng)上創(chuàng)建的存儲庫在基于UTF-8的系統(tǒng)(例如Linux,Mac,Windows)上無法正常工作,反之亦然。此外,許多基于Git的工具只是假設(shè)路徑名稱為UTF-8,并且無法正確顯示其他編碼。
提交日志消息通常以UTF-8編碼,但也支持其他擴展ASCII編碼。這包括ISO-8859-x,CP125x等等,但是not
UTF-16/32,EBCDIC和CJK多字節(jié)編碼(GBK,Shift-JIS,Big5,EUC-x,CP9xx等等)雖然我們鼓勵提交日志消息以UTF-8編碼,核心和Git瓷器都不會強制項目上使用UTF-8。如果特定項目的所有參與者發(fā)現(xiàn)使用遺留編碼更方便,Git不會禁止它。但是,有幾件事要牢記。
git commit
并且git commit-tree
如果提交給它的提交日志消息看起來不像一個有效的UTF-8字符串,則會發(fā)出警告,除非您明確聲明您的項目使用了舊版編碼。說這個的方法是在.git/config
文件中使用i18n.commitencoding ,如下所示:
i18n commitEncoding = ISO-8859-1
使用上述設(shè)置創(chuàng)建的提交對象記錄i18n.commitEncoding
其encoding
標題中的值。這是為了幫助稍后看到他們的其他人。缺少這個頭部意味著提交日志消息以UTF-8編碼。
git log
,git show
,git blame
看encoding
一個提交對象的報頭,并且嘗試除非另有規(guī)定重新代碼日志消息轉(zhuǎn)換成UTF-8。您可以i18n.logOutputEncoding
在.git/config
文件中指定所需的輸出編碼,如下所示:
i18n logOutputEncoding = ISO-8859-1
如果您沒有此配置變量,i18n.commitEncoding
則會使用該值。
請注意,在提交對象級別強制使用UTF-8時,我們故意選擇不重新編寫提交日志消息,因為重新編碼為UTF-8不一定是可逆操作。
用于編輯提交日志消息的編輯器將從GIT_EDITOR
環(huán)境變量,core.editor配置變量,VISUAL
環(huán)境變量或EDITOR
環(huán)境變量(按此順序)中進行選擇。有關(guān)詳細信息,請參閱git-var [1]。
這個命令可以運行commit-msg
,prepare-commit-msg
,pre-commit
,post-commit
和post-rewrite
hooks。有關(guān)更多信息,請參閱githooks [5]。
$GIT_DIR/COMMIT_EDITMSG
文件包含正在進行的提交的提交消息。如果git commit
在創(chuàng)建提交之前由于錯誤而退出,則用戶提供的任何提交消息(例如,在編輯器會話中)將在此文件中可用,但將在下一次調(diào)用時被覆蓋git commit
。