0

我正在努力确保不会弄乱我一直在研究的大型功能分支。我有两个遥控器：

origin - with branch dev
my - a fork of origin, with my branch dev

因此，工作流程是获取源，拉入我的源开发，从中分支，向上推，并将分支合并到源开发：

# On my dev
git fetch origin
... received new stuff...
git pull origin dev

我有一个依赖于未合并的其他分支功能的功能。所以，我这样做了：

# On my dev
git checkout -b first-feature
git checkout -b second-feature-based-on-first-feature

从这里开始，我一直在遵循我们的正常工作流程，当 origin dev 更新时，我们会在此基础上重新建立我们的分支：

git checkout first-feature
git pull --rebase origin dev
git push my first-feature -f

然后我会将第一个分支拉到我的第二个分支下：

git checkout second-feature-based-on-first-feature
git pull --rebase my first-feature
git push my second-feature-based-on-first-feature -f

今天 first-feature 被合并到 origin dev 中。我预计第二个功能在 github 上的拉取请求，它显示了两个提交（第一个功能和第二个功能），基本上现在才显示第二个功能。但事实并非如此。我在 origin dev 上重新设置了第二个功能，虽然一切看起来都很好，但我很担心这一点。我是否只是强制推动第二个功能？

我知道这有点具体。我想我的问题是：这应该如何工作，我哪里出错了（如果有的话）？我试图按照其他答案来建立一个分支，但这是一个陌生的领域，我不想犯一个巨大的错误。

4

1 回答 1

1

我认为您看到的问题是重写历史的副作用。

当您变基时，它实际上会更改提交哈希

提交的哈希取决于：

  1. 此提交的树（即您的源的当前状态）
  2. 提交的任何父母的哈希值
  3. 提交元数据（作者日期、作者、提交日期、提交者、提交消息等。）

来源

因此，当您使用 origin/master 重新设置第一个功能时，第二个功能的提交仍然基于原始第一个功能的提交，因此当您使用第一个功能重新设置第二个功能时，第一个功能上的提交不同，然后变基更改了更改的前两个提交。所以你有：

1) -- A 
       \ -- B
             \ -- C 
After rebase origin/dev
2) -- A  -- B'
   -- A  -- B
            \ -- C
Rebase with first-feature
3) -- A' -- B' -- B -- C'

至少这是从您描述的流程中出现的情况。我希望这有帮助！

于 2013-11-15T04:24:23.860 回答