我们正在开发一个功能分支，最终将合并到我们的主分支中。从工作流的角度来看，我们通常会分支这个功能分支，进行更改/添加文件，然后提交拉取请求。这个工作流程的问题在于，当我们提交pull请求时，我们必须合并其他开发人员所做的任何更改，以确保我们的分支是最新的。通常这就像解决冲突和继续前进一样简单，但我们遇到的问题是，当我们从主要功能分支进行合并时，所做的任何更改都会被放入我的分支中，然后必须放置返回到pull请求的功能分支。我希望答案是“选择性合并”，你可以告诉git进行合并，但只合并我告诉它的文件，而不是整个分支。
示例：文件A存在于主要功能分支中。我创建了一个新的分支，并对文件A进行了更改。当我这样做时，另一个开发人员对文件B进行了更改并获得了他们的pull请求。现在，当我合并时，我得到文件A的任何更新（我想要的，所以我可以解决冲突）和文件B的更新（我不想要，因为我只是将相同的文件放回到拉取请求中没有变化）。我们正在使用bitbucket，由于某种原因，它没有意识到文件完全相同，并且它们出现在pull请求中。质量保证不喜欢这个，所以我需要找到另一种方式。
我已经找到了如何有选择地将来自另一个分支的文件签出到我自己的分支，但这将覆盖我在新分支中所做的任何更改，所以这不是一个真正的选择。
TL; DR 版本是，有没有办法将某些文件从另一个分支合并到我的分支中？
答案 0 :(得分：2)
在Git中，没有“选择性合并”的概念。如果执行合并并在提交图中连接两个节点以形成第三个节点，
A
\
-- C
/
B
C被认为是A和B的总和，并被假定为A和B内容的直接合并。从技术上讲，您可以选择不包括在创建提交C时在B中引入的所有更改，但不是表达“哦，我只是想立即忽略这些变化”（这就是你正在寻找的）它实际上表达了“来自B的那些变化是坏的，我正在积极地永远删除它们。”
虽然Git可以实现你想要的选择性合并类型，但它与事情的运行方式相反，Git不会为你提供超过必要的绳索。这是有充分理由的，你不应该解决它。