git - git-stash 和 git-rebase 的真正功能是什么？

Question

我正在学习git，我对一些命令问题很困惑:

1. 我创建了两个分支 A 和 B。在我的本地存储库中，A 已经存在。现在我想将 B checkout 到同一个本地存储库中，并在不打扰 A 的情况下在 B 上进行操作。那么我可以在没有 git -stash A 的情况下 checkout B 吗？ (刚才直接敲checkout B，没有git -stash A，我觉得也可以，为什么？)git -stash有什么作用？

2. 我一直对 git -merge 和 git -rebase 感到困惑。什么情况下应该选择哪个？

Answer 1

Stash 只是将您未提交的更改 stash 起来，这样您就可以暂时处理其他事情。在过去，您习惯于提交更改、切换分支、切换回来，然后使用“git reset HEAD^”来撤销您的提交。

关于 rebase ，这是我的笔记:

类似于 merge ，但保持单线程的连续性。

简而言之，rebase 获取当前分支并在其历史记录中搜索它从指定分支 fork 的点。然后它将所有这些提交作为补丁并将它们应用到指定的分支，有效地将这些提交移植到指定分支的末尾。

之前:

     E--F--G        mybranch
    /
A--B--C--D          upstream

在“rebase upstream”之后:

           E'-F'-G' mybranch
          /
A--B--C--D          upstream

如果两个分支中都有任何提交(例如，因为您将补丁邮寄给某人并且已应用)，那么它们不会被冗余应用。请参见手册页。

注意:这可能会弄乱任何已经拥有您的分支副本的人。此命令最好仅用于尚未推送到另一个存储库的提交。

上游 可能是分支或任何其他有效提交。

如果遇到冲突，git 会向受影响的文件添加冲突标记 (<<<<<) 并停止 rebase 。解决冲突后，使用“git add file”。处理完所有冲突后，使用“git rebase --continue”。您也可以使用“git rebase --abort”取消 rebase

如果您在当前分支中有未提交的更改，则必须先将它们存储起来，然后再进行 rebase 。

---

还允许您使用“-i”选项重写当前分支的历史记录(参见“重新排列提交”):

之前:

A--B--C--D--E

之后:

A--B--E'-C'-D'

甚至 merge (压缩)提交:

A--B--CE'-D'

或者完全从链中删除提交:

A--B--D'-E'

---

到:

--onto branch 选项允许您将更改完全移植到不同的分支。例如，假设您的分支是从分支“foo” fork 出来的:

o--o--o--o--o  master
    \
     o--o--o--o--o  foo
                  \
                   o--o--o  mybranch

但是现在你希望它从 master 中 fork 出来:

o--o--o--o--o  master
    \        \
     \        o--o--o  mybranch
      \
       o--o--o--o--o  foo

你会检查 mybranch 并给出这个命令:

git rebase --onto master foo

在英语中，这表示“获取自(但不包括)foo 以来的所有更改，并将它们应用到 master。”

--onto 也可以用来从链中拼接出一个提交。请参阅手册页。 -i 也可以用于此目的。

---

注意: rebase 被认为是有害的:此命令通过有效地重写历史来起作用。有可能使自己处于无法从过去某个时间点重建存储库状态的状态。例如，在上面给出的第一个示例中，存储库状态 E、F 和 G 现在永远丢失了。

好消息是，如果您在执行 rebase 之前为事物分配分支名称或标签，那么什么都不会真正丢失。如果我在做 rebase 之前完成了 git branch foo，分支“foo”将指向存储库的原始状态 G，使其稍后可以恢复(直到删除分支 foo)。

       E-F-G   foo
      /
     /     E'-F'-G' mybranch
    /     /
A--B--C--D          upstream