与Git的选择性合并？

我们正在开发一个功能分支，它最终将合并到我们的主分支中。从工作流的角度来看，我们通常从该功能分支分支，进行更改/添加文件，然后提交请求。这个工作流的问题是，我们必须合并其他开发人员在提交请求时所做的任何更改，以确保我们的分支是最新的。通常，这就像解决冲突并继续前进一样简单，但我们遇到的问题是，当我们从主功能分支进行合并时，所做的任何更改都会被放入我的分支，然后必须将其放回功能分支以进行拉取请求。我希望答案是“选择性合并”，您可以告诉git进行合并，但只合并我告诉它的文件，而不是整个分支

示例：文件A存在于主要素分支中。我在此基础上创建了一个新分支，并对文件a进行了更改。在我这样做的同时，另一个开发人员对文件B进行了更改，并批准了他们的请求。现在，当我合并时，我会得到对文件A的任何更新（我想要的，这样我就可以解决冲突）和对文件B的更新（我不想要，因为我只需要将相同的文件放回pull请求，而不做任何更改）。我们使用的是bitbucket，出于某种原因，它没有意识到这些文件是完全相同的，它们显示在pull请求中。QA不喜欢这样，所以我需要找到另一种方法

我发现了如何有选择地将文件从另一个分支签出到我自己的分支，但这将覆盖我在新分支中所做的任何更改，因此这不是一个真正的选项

---

TL；DR版本是，有没有办法只将另一个分支中的某些文件合并到我的分支中？

在Git中，没有“选择性合并”的概念。如果执行合并并连接提交图中的两个节点以形成第三个节点

A
 \
  -- C
 /
B

C被认为是A和B的总和，并被认为是A和B内容的直接合并。从技术上讲，您当然可以选择在创建commit C时不包括B中引入的所有更改，而不是表示“哦，我现在只想忽略这些更改”（这就是您所寻找的）它实际上表达了“来自B的那些变化是不好的，我将永远积极地删除它们”

---

虽然您想要的选择性合并类型在Git中是可能的，但它的运行方式与预期的工作方式相反，Git不会为您提供超出必要的约束。这是一个很好的理由，你不应该去解决它。

我不知道Bitbucket，但听起来很奇怪，如果文件没有被真正修改，它会列出这些文件。您确定文件模式没有任何更改吗？或者行尾？可能是重复的，我已经继续工作并找到了另一份工作，但我认为处理原始问题的最简单方法是对要素分支进行重基，这样您就有了自最初创建分支以来发生的任何更改。不过，谢谢你的回答。如果有人有类似的问题需要解答，就发布这个。