这两种移动分支的方式之间有区别吗? [英] Is there a difference between these two ways of moving a branch?

问题描述

我正在遵循交互式 LearnGitBranching 教程，并遇到了两种在分支中移动的方法.我想确保自己没有遗漏任何东西.

I was following the interactive LearnGitBranching tutorial and came across two ways of moving around a branch. I want to be sure that I am not missing anything.

两者之间是否有区别

 git branch -f master master^ 

，并且假设HEAD指向master，

git reset HEAD^

并且，如果他们做同样的事情，为什么还要使用reset命令呢?这是git branch -f的简写吗?

And, if they do the same thing, why have the reset command at all? Would it mean it's simply a shorthand for git branch -f?

谢谢你！

推荐答案

如忽略所有模式及其作用，第一个问题的答案是:如果HEAD引用master并且您将master移至另一个使用git branch的提交，则可以，这实现了与通过git reset间接移动master相同.但是:

Ignoring all of the modes and what they do, the answer to the first question is: if HEAD refers to master and you move master to another commit with git branch, then yes, this achieves the same thing as indirectly moving master with git reset. But:

1. 我们不能简单地忽略reset的选项.
2. 我们还从如果HEAD引用master"开始回答.如果没有，怎么办?

1. We can't simply ignore the options to reset.
2. We also started the answer with "if HEAD refers to master". What if it doesn't?

尤其是对于点#1，git reset的默认模式为--mixed.在这种情况下，reset命令可以做的不仅仅是移动分支提示.它还可以更新git的索引(又称临时区域").

In particular, for point #1, the default mode for git reset is --mixed. The reset command can, and in this case does, do more than just move the branch-tip. It can also update git's index (aka "staging area").

您可以并且实际上可能应该考虑git的索引/登台区域，因为它是下次运行git commit时git准备提交的内容".当您git add使用git进行下一次提交的更改时，git会读取该文件的当前工作树版本，然后将 ¹ 写入索引中.

You can—and in fact, probably should—think of git's index / staging area as "what git is ready to commit the next time you run git commit". When you git add a file to make git pick up changes for the next commit, git reads the current work-tree version of that file, then writes that¹ into the index.

git reset所做的(或可以做的，并且对--mixed所做的)是 undo 这种索引修改，通过更改索引内容以匹配您重置为的提交.也就是说，git reset --mixed HEAD^不仅备份分支一次提交，而且 还将所有索引内容重置为备份的一次提交. git branch命令不会触及索引.

What git reset does (or can do, and does with --mixed) is undo this kind of index-modification, by changing the index contents to match the commit you reset-to. That is, git reset --mixed HEAD^ not only backs the branch up one commit, but also resets all the index contents to the backed-up-by-one commit. The git branch command does not touch the index.

使用--soft选项，您可以使git reset不触摸索引.在这种情况下，它确实与git branch -f做同样的事情-尽管如第2点所述，但这仅在HEAD引用master的情况下有效.如果要在不使用git reset的情况下进行软复位，则第一步是找出HEAD指向哪个分支(如果有).只有这样，您才能更新分支(只有在未处于分离式HEAD"模式下才可以).

You can make git reset not touch the index, by using the --soft option. In this case, it really does do the same thing as your git branch -f—although, as noted in point #2, this only works if HEAD refers to master. If you want to do a soft reset without using git reset, your first step is to find out what branch, if any, HEAD points to. Only then can you update the branch (and then only if you're not in "detached HEAD" mode).

为完整起见，在这里值得注意的是git reset --hard比git reset --mixed做得更多:它不仅更新分支提示并重置索引，还重置"您的工作树，使其看起来像新的目标提交.

For completeness, it's worth noting here that git reset --hard does even more than git reset --mixed: it not only updates the branch-tip and resets the index, it also "resets" your work tree, making it look like the new target commit.

还值得补充的是，故意使用git reset的几种常见用法只是利用了某些操作:

It's also worth adding that several common uses of git reset deliberately only make use of some of its actions:

• git reset --soft HEAD^在不更改索引或工作树的情况下备份了一次提交，因此新的git commit提供了与您刚刚备份的提交内容相同的新分支提示-超过.这使您可以更改提交消息. ² 与git commit --amend完全相同，不同之处在于后者实际上更容易实现.因此这种用法不再常见(这是git commit 必须 --amend选项之前的用法).

• git reset --soft HEAD^ backs you up one commit, without changing the index or work-tree, so that a new git commit provides a new branch-tip with the same contents as the commit you just backed-up-over. This lets you change the commit message.² This is exactly the same as git commit --amend, except that the latter is actually easier; so this usage is not common any more (it was how one did this before git commit had the --amend option).

git reset --mixed -- <path>将您移动"到您的当前提交(即，它将当前分支重写为指向它已经指向的位置，这是一个空操作)，但会重置索引，而无需更改工作-树.这使您可以撤消" git add或git rm --cached. ³ 通常，它只是拼写为git reset <path>，因为默认值为--mixed.

git reset --mixed -- <path> "moves" you to your current commit—that is, it rewrites the current branch to point to where it already points, which is a no-op—but resets the index, without altering the work-tree. This lets you "undo" a git add or git rm --cached.³ Usually it's just spelled git reset <path>, since --mixed is the default.

git reset --hard或git reset --hard <path>再次根本不会移动"您，但会重置索引并还原工作树版本.

git reset --hard or git reset --hard <path> again "moves" you not at all, but resets the index and restores the work-tree version.

reset命令有几个额外的选项(--merge和--keep；还有-p)，它们不太适合此模式.不过，在这里我只是忽略它们，以免答案太长.

The reset command has several extra options (--merge and --keep; and also -p) that don't quite fit this pattern. I'm just going to ignore them here, though, to keep this answer from getting way too long.

¹ 实际上，git将文件(或"blob")写入存储库，而不是索引.在编写Blob的过程中，git还会计算所得的SHA-1:对象的真实名称". (所有存储库对象均通过其真实名称" SHA-1找到.该存储库充当简单的键值存储，键为SHA-1，值为对象:文件，又称"blob"， SHA-1，文件名和执行权限位进入索引.索引在提交时根据需要转换为一个或多个git"tree"对象；这些树对象包含各种文件名，modse/execute-permissions和SHA-1.

¹Actually, git writes the file (or "blob") to the repository, rather than to the index. In the process of writing the blob, git also calculates the resulting SHA-1: the "true name" of the object. (All repository objects are found by their "true name" SHA-1s. The repository acts as a simple key-value store, with the key being the SHA-1, and the value being the object: the file aka "blob", or tree, or commit, or annotated-tag-object.) The SHA-1 goes into the index, along with the file's name and execute-permission bit. The index is later turned into one or more git "tree" objects at commit time, as needed; those tree objects contain the various file names, modse/execute-permissions, and SHA-1s.

² 更精确地说，您使用更正后的消息进行了新的，不同的提交.这也是git commit --amend所做的.旧的(修订前)提交仍在存储库中，并具有相同的SHA-1.新提交具有不同的消息和不同的时间戳，即使它从相同的索引开始，也具有不同的SHA-1，因此具有相同的树.

²More precisely, you make a new, different commit with the corrected message. This is also what git commit --amend does. The old (pre-amendment) commit is still in the repository, with its same SHA-1; the new commit, with its different message and different time-stamp, has a different SHA-1, even though it starts from the same index, and hence has the same tree attached.

³ 常规(不是--cached)git rm已从工作树中删除了文件，因此git reset --mixed不会这样做. git reset --hard <path>可以，或者您可以git checkout HEAD -- <path>找回文件.后者通过"索引进行写操作，因此这些命令在命令方面又变得非常多余，例如git reset --soft与git branch -f.

³A regular (not --cached) git rm has removed the file from the work-tree, so git reset --mixed won't do. git reset --hard <path> will do, or you can git checkout HEAD -- <path> to get the file back. The latter "writes through" the index, so again these wind up being pretty much redundant command-wise, like git reset --soft vs git branch -f.

这篇关于这两种移动分支的方式之间有区别吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！