【问题标题】:Branch off a branch, How to rebase on another branch?分支一个分支,如何在另一个分支上变基?
【发布时间】:2017-03-21 14:42:26
【问题描述】:

我开始在分支 B 上工作。这是从branchA分支出来的。几周后,主线分支develop已经合并了很多提交。分支A和B都落后了。

--d1--d2--d3  ...2 weeks later...  --d253  develop
       \
        a1--a2--a3                         branchA
                   \
                    b1--b2--b3             branchB (current)

我想了解开发分支的最新信息。并且更喜欢在其最新的提交 d253 中重新设置我的分支 B 的开发。此外,来自 branchA 的所有提交都应该忽略。这将避免我为解决合并冲突付出巨大的努力(有很多)。因为我不是那个分支A的维护者。我可以在我的分支 B 中从 A 重新创建我需要的依赖项。不确定我应该在变基之前还是之后这样做。

--d1--d2--d3  .....  --d253  develop
       \                  \
        a1--a2--a3         \
                            \
                             b1'--b2'--b3'

Q1.这样做对吗

git checkout develop
git pull
git checkout branchB
git rebase --onto develop branchA

Q2。我们假设冲突的数量非常重要,大约 30 个文件。与git merge develop 相比,rebase 仍然是一个好方法吗?

【问题讨论】:

    标签: git git-rebase


    【解决方案1】:

    Q1 - 是的,它是执行图片中显示的命令的命令。如果分支 b 与分支 a 正交,我想这很好。我会犹豫不决;您是否有理由不想将两个分支都重新设置为当前的 d 提交?

    Q2 - 我没有注意到 rebasemerge 在解决冲突方面有很大不同。最大的区别在于,对于您指定的特定变基,您将不会包含 a 更改;这意味着如果 a 更改与 d 更改冲突,您不必处理它。 (如果 b 更改与 a 更改重叠,我认为这本身不会被视为冲突,但很可能导致代码处于损坏状态。)

    真正的问题是,b 提交是否已与其他开发人员共享?如果是这样,那么通常不建议将它们重新设置为基础,因为这会给其他开发人员带来问题。

    【讨论】:

    • branchB 尚未与其他开发人员共享。您能否解释“如果分支 b 与分支 a 正交”的含义?至于“我不想将两个分支重新设置为当前 d 提交的原因?”这是 b/c 我不维护分支 A。事实证明这是一个缓慢移动的分支,它将被合并到主线中的日子还很远。我的 branchB 更活跃,我需要从 A 获得的少数依赖项可以从 A 中挑选出来,或者我什至可以重新创建一些存根以使我的代码在等待 branchA 将来合并时正常工作。希望这是 rebase 的一个很好的理由。
    • rebase vs merge 我确实注意到rebase 正在“赶上”长链提交时有所不同。当 rebase 在目标分支的历史上重放此文件时,一个文件可能有 5 次冲突。并且需要解决冲突 5 次。使用合并,有一个最终的合并冲突步骤,所有文件都显示在一个屏幕中(我使用 IntelliJ)。每个冲突文件只需要解决一次。这么说,这并不意味着merge 更好。我非常喜欢 rebase 将我的更改放在目标之上,而不是合并提交。只是想更好地了解良好做法。
    • “正交”是指如果您的更改可以独立于a 对基本开发线进行,反之亦然。从你所说的情况来看,情况并非如此。如果你决定继续(比如从a 挑选你需要的东西),以后可能会导致更多的合并冲突;所以你必须决定这是否值得。
    【解决方案2】:

    为了仅使用来自 B 的提交将分支 B 重新设置为开发基础。必须使用带有 3 个参数的 rebase --onto

    git checkout branchB
    git rebase --onto develop branchA branchB
    

    感谢Git Tip of the Week: Rebasing Revisited“重新定位到”部分提供了一个类似于此问题中描述的场景的示例。

    也在git-rebase documentation。为方便起见,在此转载:

    首先让我们假设您的主题是基于下一个分支的。例如,在 topic 中开发的功能依赖于在 next 中找到的某些功能。

    o---o---o---o---o                  master
         \
          o---o---o---o---o            next
                           \
                            o---o---o  topic
    

    我们想从 master 分支创建主题;例如,因为主题所依赖的功能被合并到更稳定的主分支中。我们希望我们的树看起来像这样:

    o---o---o---o---o             master
        |            \
        |             o'--o'--o'  topic
         \
          o---o---o---o---o       next
    

    我们可以使用以下命令来获取:

    git rebase --onto master next topic
    

    【讨论】:

    • 您建议的rebase 命令中的最后一个参数不需要;它只是说“在开始之前结帐branchB”,并且您已经在命令之前使用了明确的分支B 的checkout
    • @MarkAdelsberger 谢谢,第三个参数的默认值令人困惑。第三个参数什么时候表示“检查第三个参数中的分支”,什么时候表示“直到当前分支中的这个提交”?如 Enrico Campidoglio 的回答中的I can't understand the behaviour of git rebase --onto 所示,“外科医生:带有 3 个参数的 git rebase --onto”部分
    • 嗯?好吧,我想这是一个解释问题,但要理解的是第三个参数是一个提交标识符(不一定是一个分支),它总是意味着“检查第三个参数”。如果第三个参数是HEAD^^(或其他对分支上提交但不在分支提示处的提交的引用),那么这具有说“直到此提交”的效果,但仍然通过检查该提交来完成启动变基(如果您先手动检查提交,仍然不需要;它只是语法糖)。
    • @MarkAdelsberger 重新运行模拟并确认您是对的。如果第三个参数(要变基的分支)已经签出,则可以省略。
    猜你喜欢
    • 1970-01-01
    • 2011-07-15
    • 2017-02-21
    • 1970-01-01
    • 2011-01-06
    • 1970-01-01
    • 2018-01-07
    • 2022-11-09
    • 1970-01-01
    相关资源
    最近更新 更多