时间戳

首页 > 解决方案 > Git：我怎样才能完全依赖尚未合并的 PR？

git - Git：我怎样才能完全依赖尚未合并的 PR？

问题描述

目标是保持工作流程高效且历史记录干净。

一个常见的问题

我想介绍几个相互依赖的小功能，我不想在等待第一个合并的第二个 PR 上被阻止（我确实希望它位于单独的分支中）。

为了澄清，我需要添加 2(+) 个功能：feature-1和feature-2. feature-2取决于feature-1。这些都将存在于不同的分支上，并且可能需要几天时间feature-1才能接受 PR。我想在feature-2一个单独的分支上工作，同时等待，同时feature-1可能有一些需要的更改应该渗透到feature-2.

3个解决方案：

我目前的解决方案是后者：

  1. 创建一个feature-1分支master

  2. 写代码，推送，启动 PR

  3. master在等待它合并时将其在本地合并到

  4. 从那个 a 分支feature-2（现在这取决于feature-1）

  5. 如果请求对 进行更改，请feature-1修复它们，乐观地合并回master，合并回feature-2，并在任何需要的时候执行此操作feature-1，feature-2IE 始终流经本地（仅）版本的 master。

我不喜欢我的主人会有与官方不同的历史，但由于 git 就像一个仅附加（大部分）的 vcs，而且我认为提交是一个关联操作......他们的历史实际上会是相同的？

标签： gitworkflow

解决方案

我希望我能理解这个问题......但我将解释如何轻松地处理这个工作流程。

如果从feat1 开始feat2，当你在feat2 上工作时，你可能会遇到一些场景：

场景 1：feat1 获得了一些额外的复活......小菜一碟：

git rebase feat1

场景 2：feat1 被移动了（可能是重新定位）。这涉及更多一点。我们甚至不确定 feat1 的修订是否在没有冲突的情况下被重新调整，我们现在只是分支被移动并且我们不知道其他任何事情（开发人员可能已经决定重新开始，因此原始修订没有任何关系到新的）：

git rebase --onto feat1 old-tip-of-feat1 feat2 # ask git to move feat2 discarding all old revisions of feat1, and put them on top of feat1

实际上它不一定是分支的旧尖端，它可能是feat2历史上feat1的最后一个版本。

场景 3：feat1 被合并到 master。这很简单：

git rebase master

这些是基础。

推荐阅读