在GIT bugfix分支中，如何拉动并移除另一个分支（只是为了一起测试它）？

我想知道以下场景中的理想流程是什么：

• 发展特色
• 功能A使来自软件另一部分的bug（B）变得明显
• 从a创建一个错误修复分支以修复B。没有a，我们看不到错误修复B是有效的。（编辑：因为我们只能在A存在时才能看到错误。B总是错误的，但在分支A之前没有可见的症状。分支A本身没有错误）

现在，在错误修复的PR中，有一个分支A，它使得在差异中更难看到错误修复是什么。另外，技术审查员有可能被引诱从错误修复分支B的A处审查内容

因此，错误修复分支B中的分支A对功能审查员来说是好的，但对技术审查员来说是坏的

我一直在根据需要将A拉入B，但拉入似乎并不可靠（也许我错了）

我这里的问题不仅仅是git语法，而是处理这种情况的更一般的工作流。我希望避免限制审阅者做git工作，并展示准备好审阅的东西

---

在这种情况下，你知道一个好的工作流程吗？（如果有点花哨，请在您的回复中添加git命令）

如果我有什么错误，我从一开始就向您道歉，但是您的一些细节让我感到困惑，尽管我读了两三遍（“没有a，我们看不到错误修复B是有效的”-B怎么可能没有a，当它起源于a时？）

关于标题中的问题： 如果您有一个分支

X

以及如何在其中拉另一个分支

Y

来测试它，然后将其删除，我建议将分支

X

克隆到一个

X1

中，然后将

Y

分支合并到其中，以便您可以查看/测试它们的行为。之后，可以安全地删除分支

X1

git checkout X; 
git checkout -b X1;
git merge Y;

这也可以通过拉式请求来实现，以获得更好的可视化效果

但是，如果您正在开发一个功能分支

a

，如第一个项目符号中所述，则无需在

a

上创建错误修复分支，直到您将分支a合并到主分支中（

主分支

，或您所称的任何分支）。修复bug应该直接在A中完成

我提出的解决方案，至少到目前为止，我是如何享受项目工作的：

• 创建要素分支

  A

  off

  master

  分支
• 偶尔，为了测试

  A

  ，将

  master

  分支合并到一个（

  git checkout A；git merge master；

  ）->这样可以确保功能分支始终与主分支保持最新状态，并且使分支的最终PR更容易，因为两者之间的变化将更少
• 在功能分支

  A

  上完成开发后，通过pull请求将其合并

---

希望这在某种程度上有所帮助

这实际上取决于功能分支所处的状态

• 如果特征分支合并到主分支中，则热修复分支是合适的；在master之外创建它（通过

  git checkout-b

  ），修复异常行为，验证该分支上的，然后将其合并回master

• 如果特征分支未合并到主分支，则不需要热修复分支；在下一次提交时修复错误

这种说法有点令人担忧：

如果没有A，我们看不到错误修复B是有效的

这个bug在A中是可复制的，在B中是不可复制的。如果你没有办法验证这个代码，你应该把它作为你绝对的首要任务

这种说法更令人担忧：

现在，在错误修复的PR中，有一个分支A，它使得在差异中更难看到错误修复是什么。另外，审查者有可能被引诱从错误修复分支B的A处审查内容

这意味着两件事：

• 代码审查没有发现这个bug，这意味着审查过程中存在缺陷
• 代码在得到充分验证之前就被合并了，这意味着在质量保证和验证阶段存在缺陷

---

您的审阅者必须有足够的纪律，将每个提交都视为一个原子实例。如果有一组pull请求，那么不要让它们被任何其他PR/branch/commit分散注意力。如果有一个提交解决了审查提出的所有问题，那么这些修复需要在该分支上。

查找引入错误的提交的a-B合并基或对分。在那里修复它并将其合并到A和B中（如果有更多受影响的引用，例如受支持版本的发布标记，请将它们包括在合并基本命令0中）

---

一些商店有关于记录合并的当地政策，如果他们说你不能这样做，那么在上面添加

--squash

。

谢谢。我已编辑了这个问题以消除混淆。基本上，您的建议是让一个分支同时具有BugFixB和“暴露”特性a，只是为了查看，而不是合并。在我看来，这似乎很好，只要修复的bug很小，并且没有太多的迭代。我知道我糟糕的措辞（编辑的问题）已经误导了你。我是否正确理解您的建议是在分支A中进行错误修复，而只是在其自己的提交中进行修复？我不确定是否理解这里的所有内容（“bissect”）。这个bug是几个月前引入的一个特性的一部分，但在我使用特性a之前，它从未出现过。它存在于一个多团队组织中，因此它与我自己的提交历史无关。我希望对修复本身进行审查，因为在这两者之间可能会产生一些依赖于错误行为的东西。好的，在您更习惯使用git作为工程日志之前，不要担心对分。但是有多所学校

# if there's more than A and B involved, include them in this command

base=`git merge-base A B`   # the bugged commit is often better but 
                            # there's no easy command to find it :-)

git checkout $base
# fix fix commit commit
git checkout A; git merge $base   # or `git branch fix314 $base` and merge by name
# repeat the above for each branch