Question

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

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

今天，第一个功能被合并到原始开发中。我期待github上的第二个功能的拉取请求，它显示了两个提交（第一个功能和第二个功能），基本上只是现在显示第二个功能。但事实并非如此。我在原点dev上重新设计了第二个功能，虽然一切似乎都没问题，但我很担心这一点。我是否只是强制推送第二个功能？

我知道这有点具体。我想我的问题是：这应该怎么做，哪里出错了（如果有的话）？我试图按照其他答案将一个分支建立在一个分支上，但这是一个不熟悉的领域，我不想犯下一个大错误。

Answer 1

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

当您进行rebase时，它实际上会更改提交哈希

提交的哈希取决于：

此提交的树（即您的来源的当前状态）
任何提交父母的哈希
提交元数据（作者日期，作者，提交日期，提交者，提交消息等）。

source

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

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

至少这是你所描述的流程中出现的内容。我希望这有帮助！

Git从另一个分支分支

1 个答案: