Question

我正在开展的项目有许多分支，其中有两个我关注的分支Rat和Mouse。我从分支sprint1为我的工作sprint2创建了一个新分支，并使lexis提交到分支sprint1。后来我的队友说我应该从1而不是lexis分支。所以他做了以下

sprint2

然后他告诉我使用sprint1在分支On branch lexis he deleted my commit git fetch origin/sprint2 git reset --hard origin/sprint2 Then he cherry picked my commit from reflog上推送我的提交。我的怀疑是

我知道重置会使我的分支lexis与push -f完全相同。但他为什么要做lexis？
为什么使用sprint 2？

Answer 1

但为什么他会做git fetch？

确保使用最新更新的sprint2分支

为什么使用git push -f？

如果您已经推送lexis，则需要强制推送它，考虑其历史记录会发生变化（因为其基数不再是sprint1而是sprint2）

Answer 2

我认为看到这里发生的事情的图表对你最有利。

最初，我们假设lexis和sprint2开始时都是一样的：

sprint2: ... A -- B -- C
lexis:   ... A -- B -- C

在这里，我使用省略号来表示之前的所有内容。据推测，他们在某些时候都是一个共同的基础，但这与你的问题并不相关。您向lexis提交了一个提交，同时，其他人向sprint2提交了一些数字（比如说2）提交。此时，图表如下所示：

sprint2: ... A -- B -- C -- D -- E
lexis:   ... A -- B -- C -- F

此时，您应该位于sprint2之上，但您承诺sprint1。然后，您的同事核实了您的提交F，请留下我们：

sprint2: ... A -- B -- C -- D -- E
lexis:   ... A -- B -- C

然后，他从分支lexis执行了以下两个命令：

git fetch origin/sprint2         # update local tracking branch for sprint2
git reset --hard origin/sprint2  # reset local lexis to sprint2

这使得图表看起来像这样：

sprint2: ... A -- B -- C -- D -- E
lexis:   ... A -- B -- C -- D -- E

最后，他选择了你的提交F到这个新基地：

sprint2: ... A -- B -- C -- D -- E
lexis:   ... A -- B -- C -- D -- E -- F'

现在，你就是你想去的地方。您在当前基础sprint2之上只有一次提交。

请注意，最后一步看起来像这样：

git push --force origin lexis

这是必要的，因为分支的基础发生了变化，需要强行覆盖。

Answer 3

<local:HamburgerMenuItem ... SelectedItem="{Binding YourSourceProperty}" />只是为了确保您拥有git fetch的最新快照。

sprint2是必要的，因为git push -f之后lexis的本地副本已偏离远程副本。（将其视为git reset的{{1}}版本;无论push看起来如何，请立即将其视为本地git reset --hard。）

在使我的分支与某个远程分支相同的情况下，这些git命令意味着什么？

3 个答案: