ORIG_HEAD

从git重置

"pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD. git reset --hard ORIG_HEAD Resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit. git reset --merge ORIG_HEAD After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running "git reset --hard ORIG_HEAD" will let you go back to where you were, but it will discard your local changes, which you do not want. "git reset --merge" keeps your local changes.

在应用任何补丁之前，ORIG_HEAD被设置为当前分支的尖端。 如果你有多次提交的问题，比如在错误的分支上运行'git am'，或者在提交中出现错误，可以通过更改邮箱来更容易地修复(例如，在"From:"行中出现+错误)，这是非常有用的。 此外，归并总是集合'。git/ORIG_HEAD'重置到HEAD的原始状态，这样就可以使用'git reset ORIG_HEAD'来删除有问题的合并。

Git 2.40 (Q1 2023)更多地记录了ORIG_HEAD:

参见Philippe Blain (phil-blain)的commit f1c9243, commit c6eec9c, commit 0c514d5, commit d03c773, commit e29678b(2023年1月10日)。 (由Junio C Hamano—gitster—在commit 9c2003a中合并，2023年1月21日)

git-rebase.txt:添加一个关于'ORIG_HEAD'被覆盖的注释 报道:Erik Cervin Edin 署名:菲利普·布莱恩 致谢:菲利普·伍德

'ORIG_HEAD'在重基开始时被写入，但不保证仍然指向重基结束时的原始分支尖端。 实际上，在重基期间使用其他写入'ORIG_HEAD'的命令，比如使用'git reset'(man) HEAD^'拆分提交，将导致'ORIG_HEAD'被覆盖。 这让一些用户感到困惑。 在“描述”部分添加注释，并提到使用分支的reflog的更健壮的替代方案。

Git rebase现在包括在它的手册页:

【注意】: ORIG_HEAD不能保证仍然指向前一个分支提示 在rebase结束时，如果其他命令写入该伪引用 (例如git重置)是在rebase期间使用的。 然而，上一个分支提示可以使用当前分支的reflog(即@{1})访问。

And:

txt:明确命令写入'ORIG_HEAD' 署名:菲利普·布莱恩 致谢:菲利普·伍德

当提到'ORIG_HEAD'时，要明确指出哪个命令写了这个伪引用，即'git am'(man)， 'git merge'(man)， 'git rebase'(man)和'git reset'(man)。

修订现在包括在其手册页:

ORIG_HEAD是由命令创建的，这些命令以激烈的方式移动您的HEAD 方法(git am, git merge, git rebase, git reset)， 在操作前记录HEAD的位置，以便 您可以轻松地将分支的尖端更改回运行它们之前的状态。

HEAD

注:从这里开始

HEAD is a moving pointer. Sometimes it means the current branch, sometimes it doesn't. So HEAD is NOT a synonym for "current branch" everywhere already. HEAD means "current" everywhere in git, but it does not necessarily mean "current branch" (i.e. detached HEAD). But it almost always means the "current commit". It is the commit "git commit" builds on top of, and "git diff --cached" and "git status" compare against. It means the current branch only in very limited contexts (exactly when we want a branch name to operate on --- resetting and growing the branch tip via commit/rebase/etc.). Reflog is a vehicle to go back in time and time machines have interesting interaction with the notion of "current". HEAD@{5.minutes.ago} could mean "dereference HEAD symref to find out what branch we are on RIGHT NOW, and then find out where the tip of that branch was 5 minutes ago". Alternatively it could mean "what is the commit I would have referred to as HEAD 5 minutes ago, e.g. if I did "git show HEAD" back then".

git1.8.4(2013年7月)引入了一个新的符号! (实际上，它将在1.8.5,2013年第四季度:通过提交9ba89f4重新引入)，由Felipe Contreras编写。

现在你可以说“@”，而不是输入四个大写字母“HEAD”， 如。“git log @”。

参见commit cdfd948

输入“HEAD”很乏味，尤其是当我们可以用“@”来代替的时候。 选择'@'的原因是它自然地遵循ref@op语法(例如HEAD@{u})，除了我们没有引用，没有操作，当我们没有这些时，假设'HEAD'是有意义的。 现在我们可以使用'git show @~1'之类的东西。 到目前为止，“@”是一个有效的名称，但它与这个想法相冲突，所以让我们让它无效。可能很少有人，如果有的话，使用这个名字。

HEAD is (direct or indirect, i.e. symbolic) reference to the current commit. It is a commit that you have checked in the working directory (unless you made some changes, or equivalent), and it is a commit on top of which "git commit" would make a new one. Usually HEAD is symbolic reference to some other named branch; this branch is currently checked out branch, or current branch. HEAD can also point directly to a commit; this state is called "detached HEAD", and can be understood as being on unnamed, anonymous branch.

@单独是HEAD的快捷方式，因为Git 1.8.5

ORIG_HEAD是HEAD的先前状态，由可能有危险行为的命令设置，以便于恢复它们。现在Git有reflog: HEAD@{1}大致相当于ORIG_HEAD (HEAD@{1}总是HEAD的最后一个值，ORIG_HEAD是危险操作前HEAD的最后一个值)。

要了解更多信息，请阅读git(1) manpage / [gitrevisions(7) manpage][git-revisions]、git用户手册、git社区手册和git术语表

来自man 7 gitrevisions:

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

ORIG_HEAD

从git重置

"pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD. git reset --hard ORIG_HEAD Resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit. git reset --merge ORIG_HEAD After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running "git reset --hard ORIG_HEAD" will let you go back to where you were, but it will discard your local changes, which you do not want. "git reset --merge" keeps your local changes.

在应用任何补丁之前，ORIG_HEAD被设置为当前分支的尖端。 如果你有多次提交的问题，比如在错误的分支上运行'git am'，或者在提交中出现错误，可以通过更改邮箱来更容易地修复(例如，在"From:"行中出现+错误)，这是非常有用的。 此外，归并总是集合'。git/ORIG_HEAD'重置到HEAD的原始状态，这样就可以使用'git reset ORIG_HEAD'来删除有问题的合并。

Git 2.40 (Q1 2023)更多地记录了ORIG_HEAD:

参见Philippe Blain (phil-blain)的commit f1c9243, commit c6eec9c, commit 0c514d5, commit d03c773, commit e29678b(2023年1月10日)。 (由Junio C Hamano—gitster—在commit 9c2003a中合并，2023年1月21日)

git-rebase.txt:添加一个关于'ORIG_HEAD'被覆盖的注释 报道:Erik Cervin Edin 署名:菲利普·布莱恩 致谢:菲利普·伍德

'ORIG_HEAD'在重基开始时被写入，但不保证仍然指向重基结束时的原始分支尖端。 实际上，在重基期间使用其他写入'ORIG_HEAD'的命令，比如使用'git reset'(man) HEAD^'拆分提交，将导致'ORIG_HEAD'被覆盖。 这让一些用户感到困惑。 在“描述”部分添加注释，并提到使用分支的reflog的更健壮的替代方案。

Git rebase现在包括在它的手册页:

【注意】: ORIG_HEAD不能保证仍然指向前一个分支提示 在rebase结束时，如果其他命令写入该伪引用 (例如git重置)是在rebase期间使用的。 然而，上一个分支提示可以使用当前分支的reflog(即@{1})访问。

And:

txt:明确命令写入'ORIG_HEAD' 署名:菲利普·布莱恩 致谢:菲利普·伍德

当提到'ORIG_HEAD'时，要明确指出哪个命令写了这个伪引用，即'git am'(man)， 'git merge'(man)， 'git rebase'(man)和'git reset'(man)。

修订现在包括在其手册页:

ORIG_HEAD是由命令创建的，这些命令以激烈的方式移动您的HEAD 方法(git am, git merge, git rebase, git reset)， 在操作前记录HEAD的位置，以便 您可以轻松地将分支的尖端更改回运行它们之前的状态。

HEAD

注:从这里开始

HEAD is a moving pointer. Sometimes it means the current branch, sometimes it doesn't. So HEAD is NOT a synonym for "current branch" everywhere already. HEAD means "current" everywhere in git, but it does not necessarily mean "current branch" (i.e. detached HEAD). But it almost always means the "current commit". It is the commit "git commit" builds on top of, and "git diff --cached" and "git status" compare against. It means the current branch only in very limited contexts (exactly when we want a branch name to operate on --- resetting and growing the branch tip via commit/rebase/etc.). Reflog is a vehicle to go back in time and time machines have interesting interaction with the notion of "current". HEAD@{5.minutes.ago} could mean "dereference HEAD symref to find out what branch we are on RIGHT NOW, and then find out where the tip of that branch was 5 minutes ago". Alternatively it could mean "what is the commit I would have referred to as HEAD 5 minutes ago, e.g. if I did "git show HEAD" back then".

git1.8.4(2013年7月)引入了一个新的符号! (实际上，它将在1.8.5,2013年第四季度:通过提交9ba89f4重新引入)，由Felipe Contreras编写。

现在你可以说“@”，而不是输入四个大写字母“HEAD”， 如。“git log @”。

参见commit cdfd948

输入“HEAD”很乏味，尤其是当我们可以用“@”来代替的时候。 选择'@'的原因是它自然地遵循ref@op语法(例如HEAD@{u})，除了我们没有引用，没有操作，当我们没有这些时，假设'HEAD'是有意义的。 现在我们可以使用'git show @~1'之类的东西。 到目前为止，“@”是一个有效的名称，但它与这个想法相冲突，所以让我们让它无效。可能很少有人，如果有的话，使用这个名字。

我的理解是HEAD指向当前分支，而ORIG_HEAD用于在执行“危险”操作之前存储前一个HEAD。

例如，git-rebase和git-am在应用任何更改之前都会记录分支的原始提示。