Question

我今天有一种奇怪的情况......我会尝试重新创造我认为发生的事情。

我想将推测性更改（发送到a_file）移动到新分支，并在没有它的情况下继续处理主分支。

对于a_file和b_file 脏的主人，我做了：

git checkout -b saved_feature

git commit a_file -m "Putting this modification on a different branch"

git checkout master

此时git抱怨说b_file很脏 - 这是一个警示标志，但我没认出来。

我还在分行saved_feature，所以我想我能做到：

git stash save

git checkout master

到目前为止一切顺利

git stash pop

此时我收到一条错误消息，说明存储无法合并。

我检查日志 - 由于某种原因，最初提交给master分支但不在日志中的提交大约有6天。这些提交仅在我创建的新分支上（我检查过，以防我将它们提交到不同的分支）。

在检查saved_feature分支的日志后，我可以看到它们都在那里。

发生了什么事？

我接下来尝试了master：

git merge saved_feature

但快进选项因大量冲突而失败。

我还使用git-svn将更改推送到外部存储库，所以我再次master：

git svn rebase

这从svn恢复了一些先前推送的提交。

然后，我从saved_feature分支中挑选了最近提交的其余部分，然后我做了一个git stash pop，修复了应该自动合并的冲突，但没有，最后让我的master处于原来的状态。

任何人都可以在这个令人遗憾的故事中指出我的心理模型和git分道扬and的方式。我怎么能避免再次陷入这些混乱？

Answer 1

您可能是在主HEAD的祖先的detached HEAD上工作了最近6天。
（谢谢Chris Johnsen建议最后一部分：它可能解释一切）

假设你有：

x--x--x--x <- master
      ^
      |
      T1 (tag)

如果您执行'git checkout T1'查看T1内容，请点击：将分离的HEAD放在那里。
如果您从T1执行某些修复，则最终会使用

x--x--x--x <- master
      ^\
      | -y--y--y--y--y--y <- detached HEAD (a dirty, b dirty)
      |
     T1(tag)

现在，git checkout -b saved_feature此时会创建一个分支，其中包含最后6（天值）的提交：

x--x--x--x <- master
      ^\
      | -y--y--y--y--y--y--a <- saved_feature (a committed, b dirty)
      |
     T1(tag)

，但结帐到master对于文件b并不简单从master到saved_feature的合并也不会是微不足道的（当然不是快进的）

无论如何，这就是为什么始终关注current branch you are actually working in重要的原因。