# gitrevisions
> 原文: [https://git-scm.com/docs/gitrevisions](https://git-scm.com/docs/gitrevisions)
## 名稱
gitrevisions - 為Git指定修訂版和范圍
## 概要
gitrevisions
## 描述
許多Git命令將修訂參數作為參數。根據命令,它們表示特定的提交,或者對于遍歷修訂圖的命令(例如 [git-log [1]](https://git-scm.com/docs/git-log) ),表示可以從該提交到達的所有提交。對于遍歷修訂圖的命令,還可以明確指定一系列修訂。
另外,一些Git命令(例如 [git-show [1]](https://git-scm.com/docs/git-show) 和 [git-push [1]](https://git-scm.com/docs/git-push) )也可以采用表示除提交之外的其他對象的修訂參數,例如: blob(“文件”)或樹(“文件目錄”)。
## 指定修訂
修訂參數_< rev>_ 通常(但不一定)命名提交對象。它使用所謂的_擴展SHA-1_ 語法。以下是拼寫對象名稱的各種方法。列表末尾附近列出的名稱包含提交中包含的樹和blob。
| 注意 | 本文檔顯示了git看到的“原始”語法。 shell和其他UI可能需要額外的引用來保護特殊字符并避免單詞拆分。 |
```
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
```
完整的SHA-1對象名稱(40字節十六進制字符串),或存儲庫中唯一的前導子字符串。例如。如果存儲庫中沒有其他對象以dae86e開頭的對象,則dae86e1950b1277e545cee180551750029cfe735和dae86e都命名相同的提交對象。
```
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
```
`git describe`的輸出;即,最接近的標簽,可選地后跟破折號和多次提交,然后是破折號, _g_ 和縮寫的對象名稱。
```
<refname>, e.g. master, heads/master, refs/heads/master
```
一個象征性的引用名稱。例如。 _master_ 通常表示 _refs / heads / master_ 引用的提交對象。如果您碰巧同時擁有_磁頭/主控_和_標簽/主控_,您可以明確地說_磁頭/主控_告訴Git您的意思。當含糊不清時,_< refname>_ 通過以下規則中的第一場比賽消除歧義:
1. 如果 _$ GIT_DIR /< refname>_ 存在,這就是你的意思(這通常只適用于`HEAD`,`FETCH_HEAD`,`ORIG_HEAD`,`MERGE_HEAD`和`CHERRY_PICK_HEAD`);
2. 否則, _refs /< refname>_ 如果存在;
3. 否則, _refs / tags /< refname>_ 如果存在;
4. 否則, _refs / heads /< refname>_ 如果存在;
5. 否則, _refs / remotes /< refname>_ 如果存在;
6. 否則, _refs / remotes /< refname> / HEAD_ (如果存在)。
`HEAD`命名您基于工作樹中的更改的提交。 `FETCH_HEAD`記錄您使用上次`git fetch`調用從遠程存儲庫中獲取的分支。 `ORIG_HEAD`是由以大刀闊斧的方式移動`HEAD`的命令創建的,用于在操作之前記錄`HEAD`的位置,以便您可以輕松地將分支的尖端更改回運行它們之前的狀態。 `MERGE_HEAD`在運行`git merge`時記錄您要合并到分支中的提交。當您運行`git cherry-pick`時,`CHERRY_PICK_HEAD`會記錄您正在挑選的提交。
請注意,上述任何 _refs / *_ 情況可能來自 _$ GIT_DIR / refs_ 目錄或來自 _$ GIT_DIR / packed-refs_ 文件。雖然未指定引用名稱編碼,但首選UTF-8,因為某些輸出處理可能會假定使用UTF-8中的引用名稱。
```
@
```
單獨 _@_ 是`HEAD`的捷徑。
```
<refname>@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
```
引用后跟 _@_ 后綴為日期規格括號對(例如 _{昨天}_ , _{1個月2周3天1小時1秒前}_ 或 _{1979-02-26 18:30:00}_ )指定先前時間點的ref值。此后綴只能在引用名稱后立即使用,并且引用必須具有現有日志( _$ GIT_DIR / logs /< ref>_ )。請注意,這會在給定時間查找**本地** ref的狀態;例如,上周本地_主_分支機構的內容。如果要查看在特定時間內提交的提交,請參閱`--since`和`--until`。
```
<refname>@{<n>}, e.g. master@{1}
```
后綴為 _@_ 的后綴為括號對中的序數規范(例如 _{1}_ , _{15}_ )指定第n個先驗那個參考的價值。例如 _master @ {1}_ 是 _master_ 的前一個值,而 _master @ {5}_ 是 _master_ 的第5個先前值]。此后綴只能在引用名稱后立即使用,并且引用必須具有現有日志( _$ GIT_DIR / logs /< refname>_ )。
```
@{<n>}, e.g. @{1}
```
您可以使用帶有空參考部分的 _@_ 構造來獲取當前分支的reflog條目。例如,如果你在分支 _blabla_ ,那么 _@ {1}_ 意味著與 _blabla @ {1}_ 相同。
```
@{-<n>}, e.g. @{-1}
```
構造 _@ { - < n>}_ 表示在當前分支/提交之前檢出的第n個分支/提交。
```
<branchname>@{upstream}, e.g. master@{upstream}, @{u}
```
后綴 _@ {upstream}_ 到分支機構(簡稱_< branchname> @ {u}_ )指的是由branchname指定的分支設置為在其上構建的分支(配置為`branch.<name>.remote`和`branch.<name>.merge`)。缺少的branchname默認為當前的。當拼寫為大寫時,這些后綴也被接受,無論如何它們都意味著相同的東西。
```
<branchname>@{push}, e.g. master@{push}, @{push}
```
后綴 _@ {push}_ 報告分支“我們將推送到哪里”如果`branchname`在`branchname`被檢出時運行(或者當前`HEAD`如果沒有指定分支機構)。由于我們的推送目的地位于遠程存儲庫中,當然,我們報告與該分支對應的本地跟蹤分支(即 _refs / remotes /_ 中的內容)。
這是一個讓它更清晰的例子:
```
$ git config push.default current
$ git config remote.pushdefault myfork
$ git checkout -b mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
```
請注意,在我們設置三角形工作流程的示例中,我們從一個位置拉出并推送到另一個位置。在非三角形工作流程中, _@ {push}_ 與 _@ {upstream}_ 相同,并且不需要它。
拼寫為大寫時也接受此后綴,無論情況如何都是相同的。
```
<rev>^, e.g. HEAD^, v1.5.1^0
```
修訂參數的后綴 _^_ 表示該提交對象的第一個父級。 _^< n>_ 表示第n個親本(即_< rev> ^_ 等同于_< rev> ^_ )。作為特殊規則,_< rev> ^ 0_ 表示提交本身并且在_< rev>時使用。_ 是引用提交對象的標記對象的對象名稱。
```
<rev>~<n>, e.g. master~3
```
后綴_?< n>_ 到版本參數意味著提交對象是指定提交對象的第n代祖先,僅跟隨第一個父對象。即_< rev>?_相當于_< rev> ^^^_ ,其相當于_< rev> ^ 1 ^ 1 ^_ 。請參閱下文,了解此表單的用法。
```
<rev>^{<type>}, e.g. v0.99.8^{commit}
```
后綴 _^_ 后跟括號對中包含的對象類型名稱意味著在_< rev>處取消引用對象。_ 遞歸地直到_< type>類型的對象為止。找到_或者不再解除引用對象(在這種情況下,barf)。例如,如果_< rev>_ 是commit-ish,_< rev> ^ {commit}_ 描述了相應的提交對象。類似地,如果_< rev>_ 是樹,_< rev> ^ {tree}_ 描述了相應的樹對象。 _< rev> ^ 0_ 是_< rev> ^ {commit}_ 的簡寫。
_rev ^ {object}_ 可以用來確保 _rev_ 命名一個存在的對象,而不需要 _rev_ 作為標簽,并且不需要解除引用 _rev_ ;因為標簽已經是一個對象,所以即使一次到達一個對象也不需要解除引用。
_rev ^ {tag}_ 可用于確保 _rev_ 標識現有標記對象。
```
<rev>^{}, e.g. v0.99.8^{}
```
后綴 _^_ 后跟空括號對意味著該對象可以是標記,并遞歸取消引用標記,直到找到非標記對象。
```
<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}
```
后綴 _^_ 到一個修訂參數,后跟一個括號對,其中包含一個由斜杠引導的文本,與下面的_:/ fix討厭錯誤_語法相同,只是它返回可以從_< rev>到達的最年輕的匹配提交 _^_ 之前的_。
```
:/<text>, e.g. :/fix nasty bug
```
冒號后跟一個斜杠,后跟一個文本,命名一個提交,其提交消息與指定的正則表達式匹配。此名稱返回可從任何ref訪問的最新匹配提交,包括HEAD。正則表達式可以匹配提交消息的任何部分。為了匹配以字符串開頭的消息,可以使用例如_:/ ^ foo_ 。特殊序列_:/!_ 保留用于匹配的修飾符。 _:/! - foo_ 執行負匹配,而_:/ !! foo_ 匹配文字_!_ 字符,然后是 _foo_ 。以_開頭的任何其他序列:/!_ 暫時保留。根據給定的文本,shell的單詞拆分規則可能需要額外的引用。
```
<rev>:<path>, e.g. HEAD:README, :README, master:./README
```
后綴_:_后跟一個路徑,命名由冒號前部分命名的樹形對象中給定路徑上的blob或樹。 _:path_ (在冒號前面有空部分)是下面描述的語法的特例:在給定路徑的索引中記錄的內容。以 _./_ 或 _../_ 開頭的路徑是相對于當前工作目錄的。給定路徑將轉換為相對于工作樹的根目錄。這對于從具有與工作樹具有相同樹結構的提交或樹來解決blob或樹最有用。
```
:<n>:<path>, e.g. :0:README, :README
```
冒號,可選地后跟一個階段號(0到3)和一個冒號,后跟一個路徑,在給定路徑的索引中命名一個blob對象。缺少的階段編號(以及其后面的冒號)命名階段0條目。在合并期間,階段1是共同的祖先,階段2是目標分支的版本(通常是當前分支),階段3是正在合并的分支的版本。
以下是Jon Loeliger的插圖。提交節點B和C都是提交節點A的父節點。父提交從左到右排序。
```
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
```
```
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
```
## 指定范圍
遍歷諸如`git log`之類的命令的歷史操作在一組提交上,而不僅僅是單個提交。
對于這些命令,使用上一節中描述的表示法指定單個修訂版意味著來自給定提交的提交`reachable`集。
提交的可達集是提交本身和其祖先鏈中的提交。
### 提交排除
```
^<rev> (caret) Notation
```
要排除從提交可到達的提交,使用前綴 _^_ 表示法。例如。 _^ r1 r2_ 表示從 _r2_ 可到達的提交,但排除可從 _r1_ (即 _r1_ 及其祖先)到達的提交。
### 虛線范圍符號
```
The .. (two-dot) Range Notation
```
_^ r1 r2_ 設置操作經常出現,因此有一個簡寫。如果你有兩個提交 _r1_ 和 _r2_ (根據上面的SPECIFYING REVISIONS中解釋的語法命名),你可以要求從r2可以訪問的提交,不包括那些可以從r1到達的提交 _^ r1 r2_ 可以寫成 _r1..r2_ 。
```
The …? (three-dot) Symmetric Difference Notation
```
類似的符號 _r1 ... r2_ 稱為 _r1_ 和 _r2_ 的對稱差異,定義為 _r1 r2 - not $(git merge) -base --all r1 r2)_。它是可以從 _r1_ (左側)或 _r2_ (右側)中的任何一個到達的提交集,但不是兩者都可以。
在這兩個簡寫符號中,您可以省略一端并將其默認為HEAD。例如,_原點.._ 是 _origin..HEAD_ 的簡寫并詢問“自從我從原點分支分叉后我做了什么?”同樣, _.origin_ 是 _HEAD..origin_ 的簡寫,并詢問“自從我從它們分叉后,起源做了什么?”注意 _.._ 將意味著 _HEAD..HEAD_ ,這是一個空的范圍,既可以從HEAD到達又無法到達。
### 其他< rev> ^父簡寫符號
存在三個其他的縮寫,對于合并提交特別有用,用于命名由提交及其父提交形成的集合。
_r1 ^ @_ 符號表示 _r1_ 的所有親本。
_r1 ^!_ 表示法包含commit _r1_ 但不包括其所有父母。這個符號本身表示單個提交 _r1_ 。
_< rev> ^ - < n>_ 符號包括_< rev>_ 但不包括第n個親本(即_< rev> ^< n> ..< rev>_ 的簡寫),_< n>如果沒有給出,_ = 1。這通常對于合并提交很有用,您可以通過_< commit> ^ -_ 來獲取合并提交中合并的分支中的所有提交_< commit>_ (包括_< commit>_ 本身)。
雖然_< rev> ^< n>_ 是關于指定單個提交父級,這三個符號也考慮其父級。例如你可以說 _HEAD ^ 2 ^ @_ ,但你不能說 _HEAD ^ @ ^ 2_ 。
## 修訂范圍摘要
```
<rev>
```
包括可從< rev>到達的提交(即< rev>及其祖先)。
```
^<rev>
```
排除可從< rev>到達的提交(即< rev>及其祖先)。
```
<rev1>..<rev2>
```
包括可從< rev2>到達的提交但不包括那些可以從< rev1>到達的那些。何時< rev1>或者< rev2>省略,默認為`HEAD`。
```
<rev1>...<rev2>
```
包括可從< rev1>到達的提交或者< rev2>但排除那兩個可以訪問的。何時< rev1>或者< rev2>省略,默認為`HEAD`。
```
<rev>^@, e.g. HEAD^@
```
后綴為 _^_ 后跟at符號與列出_< rev>的所有父項相同。_ (意思是,包括從其父母可以訪問的任何內容,但不包括提交本身)。
```
<rev>^!, e.g. HEAD^!
```
后綴為 _^_ 后跟感嘆號與提交_< rev>相同。_ 然后它的所有父母都以 _^_ 為前綴來排除它們(以及它們的祖先)。
```
<rev>^-<n>, e.g. HEAD^-, HEAD^-2
```
等同于_< rev> ^< n> ..< rev>_ ,_< n>如果沒有給出,_ = 1。
以下是使用上面的Loeliger插圖的一些示例,其中注釋的擴展和選擇中的每個步驟都經過仔細說明:
```
Args Expanded arguments Selected commits
D G H D
D F G H I J D F
^G D H D
^D B E I J F B
^D B C E I J F B C
C I J F C
B..C = ^B C C
B...C = B ^F C G H D E B C
B^- = B^..B
= ^B^1 B E I J F B
C^@ = C^1
= F I J F
B^@ = B^1 B^2 B^3
= D E F D G H E F I J
C^! = C ^C^@
= C ^C^1
= C ^F C
B^! = B ^B^@
= B ^B^1 ^B^2 ^B^3
= B ^D ^E ^F B
F^! D = F ^I ^J D G H D F
```
## 也可以看看
[git-rev-parse [1]](https://git-scm.com/docs/git-rev-parse)
## GIT
部分 [git [1]](https://git-scm.com/docs/git) 套件
- git
- git-config
- git-help
- git-init
- git-clone
- git-add
- git-status
- git-diff
- git-commit
- git-reset
- git-rm
- git-mv
- git-branch
- git-checkout
- git-merge
- git-mergetool
- git-log
- git-stash
- git-tag
- git-worktree
- git-fetch
- git-pull
- git-push
- git-remote
- git-submodule
- git-show
- git-log
- git-shortlog
- git-describe
- git-apply
- git-cherry-pick
- git-rebase
- git-revert
- git-bisect
- git-blame
- git-grep
- gitattributes
- giteveryday
- gitglossary
- githooks
- gitignore
- gitmodules
- gitrevisions
- gittutorial
- gitworkflows
- git-am
- git-format-patch
- git-send-email
- git-request-pull
- git-svn
- git-fast-import
- git-clean
- git-gc
- git-fsck
- git-reflog
- git-filter-branch
- git-instaweb
- git-archive
- git-bundle
- git-daemon
- git-update-server-info
- git-cat-file
- git-check-ignore
- git-checkout-index
- git-commit-tree
- git-count-objects
- git-diff-index
- git-for-each-ref
- git-hash-object
- git-ls-files
- git-merge-base
- git-read-tree
- git-rev-list
- git-rev-parse
- git-show-ref
- git-symbolic-ref
- git-update-index
- git-update-ref
- git-verify-pack
- git-write-tree