“git checkout <commit id>”正在将分支更改为“无分支”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18054057/
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
"git checkout <commit id>" is changing branch to "no branch"
提问by mk..
I am working on a branch in git. When I do
我正在 git 的一个分支上工作。当我做
git checkout <commit id>
(commit id obtained from git log), it is getting committed to that particular change but branch is changed to <No-branch>.
（从 获得的提交 ID git log），它正在致力于该特定更改，但分支已更改为<No-branch>。
Why is this happening? How do you resolve this?
为什么会这样？你如何解决这个问题？
回答by
If you checkouta commit sha directly, it puts you into a "detached head" state, which basically just means that the current sha that your working copy has checked out, doesn't have a branch pointing at it.
如果您checkout直接提交 sha，它会将您置于“分离头”状态，这基本上只是意味着您的工作副本已检出的当前 sha 没有指向它的分支。
If you haven't made any commits yet, you can leave detached head state by simply checking out whichever branch you were on before checking out the commit sha:
如果您还没有进行任何提交，您可以通过在检查提交 sha 之前简单地检查您所在的任何分支来离开分离的头部状态：
git checkout <branch>
If you did make commits while you were in the detached head state, you can save your work by simply attaching a branch before or while you leave detached head state:
如果您确实在处于 detached head 状态时进行了提交，则可以通过在离开 detached head 状态之前或期间简单地附加一个分支来保存您的工作：
# Checkout a new branch at current detached head state:
git checkout -b newBranch
You can read more about detached head state at the official Linux Kernel Git docs for checkout.
您可以在官方 Linux Kernel Git docs for checkout 中阅读有关分离头状态的更多信息。
回答by Andrejs Cainikovs
By checking out to one of the commits in the history you are moving your git into so called 'detached state', which looks like is not what you want. Use this single command to create a new branch on one of the commits from the history:
通过检查历史记录中的提交之一，您将 git 移动到所谓的“分离状态”，这看起来不是您想要的。使用此单个命令在历史记录中的其中一个提交上创建一个新分支：
git checkout -b <new_branch_name> <SHA1>
回答by Daniel Powell
If you are branch masterand you do a git checkout <SHA>
如果你是分支master并且你做了一个git checkout <SHA>
I'm fairly certain that this causes git to load that commit in a detachedstate, changing you out of the current branch.
我相当肯定这会导致 git 以分离状态加载该提交，从而将您从当前分支中移出。
If you want to make changes you can and then you can do a git checkout -b <mynewbranch>to create a new branch based off that commit and any changes you have made.
如果您想进行更改，您可以，然后您可以git checkout -b <mynewbranch>根据该提交和您所做的任何更改创建一个新分支。
回答by Munim
Is that commit in the other branch? Git checkout <commitid>will just switch over to the other branch if the commit has happened in the other branch. You will want to merge the changes to your first branch if you want the code there.
那是在另一个分支中提交吗？Git checkout <commitid>如果提交发生在另一个分支中，则只会切换到另一个分支。如果您想要那里的代码，您将希望将更改合并到您的第一个分支。
回答by Qiulang
Other answers have explained what 'detached HEAD' means. I try to answer why I want to do that. There are some cases I prefer checkout a commit than checkout a temporary branch.
其他答案已经解释了“分离头”的含义。我试着回答我为什么要这样做。在某些情况下，我更喜欢签出提交而不是签出临时分支。
To compile/build at some specific commit (maybe for your daily build or just to release some specific version to test team), I used to checkout a tmp branch for that, but then I need to remember to delete the tmp branch after build. So I found checkout a commit is more convenient, after the build I just checkout to the original branch.
To check what codes look like at that commit, maybe to debug an issue. The case is not much different from my case #1, I can also checkout a tmp branch for that but then I need to remember delete it. So I choose to checkout a commit more often.
This is probably just me being paranoid, so I prepare to merge another branch but I already suspect I would get some merge conflict and I want to see them first before merge. So I checkout the head commit then do the merge, see the merge result. Then I
git checkout -fto switch back to my branch, using-fto discard any merge conflict. Again I found it more convenient than checkout a tmp branch.
为了在某些特定提交时编译/构建（可能是为了您的日常构建，或者只是为了向测试团队发布一些特定版本），我曾经为此签出一个 tmp 分支，但是我需要记住在构建后删除 tmp 分支。所以我发现 checkout a commit 更方便，在构建之后我只是 checkout 到原始分支。
要检查该提交时的代码是什么样的，也许是为了调试问题。这个案例与我的案例#1 没有太大不同，我也可以为此签出一个 tmp 分支，但我需要记住删除它。所以我选择更频繁地检查提交。
这可能只是我偏执，所以我准备合并另一个分支，但我已经怀疑我会遇到一些合并冲突，我想在合并之前先看到它们。所以我检查头部提交然后进行合并，查看合并结果。然后我
git checkout -f切换回我的分支，使用-f丢弃任何合并冲突。我再次发现它比结帐 tmp 分支更方便。
