什么是 Git 修订表达式?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/1215814/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-10 06:49:16  来源:igfitidea点击:

What is a Git Revision Expression?

gitgit-gui

提问by Tyler Carter

So, I am using Git GUI to make a repository. But I cant find ANY trace on Google, the Documentation, or anywhere else what a 'Revision Expression' is, and it is required to create a new Branch.

所以,我使用 Git GUI 来创建一个存储库。但是我无法在 Google、文档或其他任何地方找到“修订表达式”是什么的任何痕迹,并且需要创建新分支。

Also, it seems that this is used many other places in the program, so I belive it is important to know.

此外,这似乎在程序中的许多其他地方都使用过,所以我相信知道这一点很重要。

I did find a question on this on StackOverflow, but the guy never got an answer.

我确实在 StackOverflow 上找到了一个关于这个的问题,但那个人从来没有得到答案。

I just need to know: What is a Revision Expression?

我只需要知道:什么是修订表达式?

回答by gahooa

git needs to be able to identify a commit during a number of common operations

git 需要能够在许多常见操作期间识别提交

https://git-scm.com/docs/git-rev-parse

https://git-scm.com/docs/git-rev-parse

There are a number of ways to identify a commit. You could use a branch, tag, commit sha1, or expressions. For example:

有多种方法可以识别提交。您可以使用分支、标记、提交 sha1 或表达式。例如:

git log HEAD

HEADeventually resolves to a specific commit, and you will be given the log for that. YOu could also say:

HEAD最终解析为特定的提交,您将获得相应的日志。你也可以说:

git log master

masteris a branch, and that will also resolve to a specific commit.

master是一个分支,也将解析为特定的提交。

git log fd72e9c99312

Now that IS the actual commit.

现在这是实际的提交。



The below documentation is what you are looking for. Taken from the git-rev-parsecommand documentation at http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.

以下文档是您要查找的内容。取自http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html 上git-rev-parse命令文档。

SPECIFYING REVISIONS

指定修订

A revision parameter typically, but not necessarily, names a commit object. They use what is called an extended SHA1 syntax. Here are various ways to spell object names. The ones listed near the end of this list are to name trees and blobs contained in a commit.

修订参数通常但不一定会命名提交对象。它们使用所谓的扩展 SHA1 语法。以下是拼写对象名称的各种方法。此列表末尾附近列出的是命名提交中包含的树和 blob。

The full SHA1 object name (40-byte hexadecimal string), or a substring of such that is unique within the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit object if there are no other object in your repository whose object name starts with dae86e.

完整的 SHA1 对象名称(40 字节的十六进制字符串),或在存储库中唯一的子字符串。例如,如果存储库中没有对象名称以 dae86e 开头的其他对象,则 dae86e1950b1277e545cee180551750029cfe735 和 dae86e 都命名相同的提交对象。

An output from git-describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated object name.

git-describe 的输出;即最接近的标签,可选后跟一个破折号和一些提交,然后是一个破折号、ag 和一个缩写的对象名称。

A symbolic ref name. E.g. master typically means the commit object referenced by $GIT_DIR/refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell git which one you mean. When ambiguous, a is disambiguated by taking the first match in the following rules:

符号引用名称。例如,master 通常表示 $GIT_DIR/refs/heads/master 引用的提交对象。如果你碰巧同时拥有 head/master 和 tags/master,你可以明确地说 head/master 来告诉 git 你的意思是哪一个。当有歧义时, a 通过在以下规则中取第一个匹配项来消除歧义:

if $GIT_DIR/ exists, that is what you mean (this is usually useful only for HEAD, FETCH_HEAD, ORIG_HEAD and MERGE_HEAD);

如果 $GIT_DIR/ 存在,那就是你的意思(这通常只对 HEAD、FETCH_HEAD、ORIG_HEAD 和 MERGE_HEAD 有用);

otherwise, $GIT_DIR/refs/ if exists;

否则, $GIT_DIR/refs/ 如果存在;

otherwise, $GIT_DIR/refs/tags/ if exists;

否则, $GIT_DIR/refs/tags/ 如果存在;

otherwise, $GIT_DIR/refs/heads/ if exists;

否则, $GIT_DIR/refs/heads/ 如果存在;

otherwise, $GIT_DIR/refs/remotes/ if exists;

否则, $GIT_DIR/refs/remotes/ 如果存在;

otherwise, $GIT_DIR/refs/remotes//HEAD if exists.

否则, $GIT_DIR/refs/remotes//HEAD 如果存在。

HEAD names the commit your changes in the working tree is based on. FETCH_HEAD records the branch you fetched from a remote repository with your last git-fetch invocation. ORIG_HEAD is created by commands that moves your HEAD in a drastic way, to record the position of the HEAD before their operation, so that you can change the tip of the branch back to the state before you ran them easily. MERGE_HEAD records the commit(s) you are merging into your branch when you run git-merge.

HEAD 命名您在工作树中的更改所基于的提交。FETCH_HEAD 记录您使用上次 git-fetch 调用从远程存储库获取的分支。ORIG_HEAD 是由以剧烈方式移动您的 HEAD 的命令创建的,以记录 HEAD 操作前的位置,以便您可以轻松地将分支的尖端更改回运行它们之前的状态。MERGE_HEAD 记录您在运行 git-merge 时合并到分支中的提交。

A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30:00}) to specify the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at commits made during certain times, see --since and --until.

一个 ref 后跟后缀 @ 以及括在大括号对中的日期规范(例如 {yesterday}、{1 月 2 周 3 天 1 小时 1 秒前} 或 {1979-02-26 18:30:00})到在先前的时间点指定 ref 的值。此后缀只能紧跟在引用名称之后使用,并且引用必须具有现有日志 ($GIT_DIR/logs/)。请注意,这会在给定时间查找本地 ref 的状态;例如,上周在您当地的主分支中有什么。如果您想查看在特定时间进行的提交,请参阅 --since 和 --until。

A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1}, {15}) to specify the n-th prior value of that ref. For example master@{1} is the immediate prior value of master while master@{5} is the 5th prior value of master. This suffix may only be used immediately following a ref name and the ref must have an existing log ($GIT_DIR/logs/).

一个 ref 后跟后缀 @ 用括号对(例如 {1}, {15})括起来的序数规范来指定该 ref 的第 n 个先验值。例如 master@{1} 是 master 的直接优先值,而 master@{5} 是 master 的第 5 个优先值。此后缀只能紧跟在引用名称之后使用,并且引用必须具有现有日志 ($GIT_DIR/logs/)。

You can use the @ construct with an empty ref part to get at a reflog of the current branch. For example, if you are on the branch blabla, then @{1} means the same as blabla@{1}.

您可以使用带有空引用部分的 @ 构造来获取当前分支的引用日志。例如,如果您在分支 blabla 上,那么@{1} 的含义与 blabla@{1} 相同。

The special construct @{-} means the th branch checked out before the current one.

特殊结构@{-} 表示在当前分支之前签出的第 th 个分支。

A suffix ^ to a revision parameter means the first parent of that commit object. ^ means the th parent (i.e. rev^ is equivalent to rev^1). As a special rule, rev^0 means the commit itself and is used when rev is the object name of a tag object that refers to a commit object.

修订版参数的后缀 ^ 表示该提交对象的第一个父级。^ 表示第 th 个父级(即 rev^ 相当于 rev^1)。作为特殊规则,rev^0 表示提交本身,当 rev 是引用提交对象的标记对象的对象名称时使用。

A suffix ~ to a revision parameter means the commit object that is the th generation grand-parent of the named commit object, following only the first parent. I.e. rev~3 is equivalent to rev^^^ which is equivalent to rev^1^1^1. See below for a illustration of the usage of this form.

修订参数的后缀 ~ 表示提交对象是命名提交对象的第 th 代祖父,仅在第一个父之后。即 rev~3 相当于 rev^^^ 相当于 rev^1^1^1。有关此表格用法的说明,请参见下文。

A suffix ^ followed by an object type name enclosed in brace pair (e.g. v0.99.8^{commit}) means the object could be a tag, and dereference the tag recursively until an object of that type is found or the object cannot be dereferenced anymore (in which case, barf). rev^0 introduced earlier is a short-hand for rev^{commit}.

后缀 ^ 后跟括在大括号对中的对象类型名称(例如 v0.99.8^{commit})表示该对象可能是一个标签,并递归取消引用该标签,直到找到该类型的对象或无法取消引用该对象不再(在这种情况下,barf)。前面介绍的 rev^0 是 rev^{commit} 的简写。

A suffix ^ followed by an empty brace pair (e.g. v0.99.8^{}) means the object could be a tag, and dereference the tag recursively until a non-tag object is found.

后缀 ^ 后跟一个空大括号对(例如 v0.99.8^{})意味着该对象可以是一个标签,并递归地取消引用该标签,直到找到一个非标签对象。

A colon, followed by a slash, followed by a text: this names a commit whose commit message starts with the specified text. This name returns the youngest matching commit which is reachable from any ref. If the commit message starts with a !, you have to repeat that; the special sequence :/!, followed by something else than ! is reserved for now.

冒号,后跟斜杠,后跟文本:这会命名提交消息以指定文本开头的提交。此名称返回可从任何引用访问的最年轻的匹配提交。如果提交消息以 ! 开头,则必须重复;特殊序列 :/! 后跟除了 ! 暂时保留。

A suffix : followed by a path; this names the blob or tree at the given path in the tree-ish object named by the part before the colon.

后缀 : 后跟路径;这会在由冒号前的部分命名的树形对象中的给定路径上命名 blob 或树。

A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path; this names a blob object in the index at the given path. Missing stage number (and the colon that follows it) names a stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch's version (typically the current branch), and stage 3 is the version from the branch being merged.

一个冒号,可选后跟一个阶段号(0 到 3)和一个冒号,后跟一个路径;这在给定路径的索引中命名了一个 blob 对象。缺少阶段编号(以及它后面的冒号)将命名为阶段 0 条目。在合并期间,阶段 1 是共同的祖先,阶段 2 是目标分支的版本(通常是当前分支),阶段 3 是正在合并的分支的版本。

Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent commits are ordered left-to-right.

这是 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

回答by Norman Ramsey

gahooa gives the comprehensive answer. The common case:

gahooa 给出了全面的答案。常见情况:

  • Name of an existing branch (e.g., master)
  • First few digits of a SHA1 checksum, best captured from gitkor git log
  • 现有分支的名称(例如,master
  • SHA1 校验和的前几位数字,最好从gitkgit log

Welcome to the wonderful world of git. TMI is par for the course...

欢迎来到美妙的 git 世界。TMI是课程的标准...

回答by WinWin

Another case, when using Emacs: Just type Ctrl-x v lto list all revisions. For a newbie to git (but not to Emacs/CVS) I was surprised to see that revisions are listed as:

另一种情况,当使用 Emacs 时:只需键入Ctrl-x v l以列出所有修订。对于 git 新手(但不是 Emacs/CVS),我惊讶地看到修订被列为:

commit 8d5ab12cd76d5e6098e5894c8713ec605fd9f153

It's definitely a refreshing change from the Major.minor.bugfix.buildnotation.

这绝对是Major.minor.bugfix.build符号的令人耳目一新的变化。

What's more (pleasantly) surprising is that Emacs handles git automatically without any need for me to tell it (via .emacs) that it needs to refer to git instead of CVS. Pretty amazing.

更(令人愉快)令人惊讶的是,Emacs 自动处理 git,无需我告诉它(通过 .emacs)它需要引用 git 而不是 CVS。相当了不起。

So to summarize, when Emacs prompts for a revision, just enter that 40 hex-digit number.

总而言之,当 Emacs 提示进行修订时,只需输入 40 个十六进制数字。

回答by saurabh gautam

when you are trying to create branch for the first time , Git GUI ask for Revision expression, from my understanding i think git needs already created and committed branch in order to track the newly made changes such as (new branch /modification in files) to compare it with something(here master branch).

当您第一次尝试创建分支时,Git GUI 要求 Revision 表达式,根据我的理解,我认为 git 需要已经创建和提交的分支以跟踪新所做的更改,例如(文件中的新分支/修改)到将它与某些东西进行比较(这里是 master 分支)。