TFS 合并是如何工作的？
我有一个发布分支（RB，从 C5 开始） 和 主干 (C10) 上的变更集，我现在想将其合并到 RB 上。
该文件在 C3 处发生了更改（两者共有），RB 上的 CS 7 中发生了一项更改，C9（干线）中发生了一项更改，C10 中发生了一项更改。因此，我更改的文件的历史记录如下所示：
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
当我将 C10 从 trunk 合并到 RB 时，我希望看到一个显示我的合并窗口 <代码>C10 | C3 | C7 因为 C3 是共同的祖先修订版，C10 和 C7 分别是我的两个分支的尖端。但是，我的合并工具显示了 C10 | C9| C7。
我的合并工具配置为显示 %1(OriginalFile)|%3(BaseFile)|%2(Modified File)，因此这告诉我 TFS 选择 C9 作为基本修订版。
这是完全出乎意料的，并且与我习惯在 Mercurial 或 Git 中合并的方式完全相反。是我搞错了什么，还是 TFS 试图通过合并让我发疯？
这是默认的 TFS 合并行为吗？如果是这样，您能否深入了解他们为什么选择这种方式实现？
我正在使用 TFS 2008 和 VS2010 作为客户端。
I have a release branch (RB, starting at C5) and a changeset on trunk (C10) that I now want to merge onto RB.
The file has changes at C3 (common to both), one in CS 7 on RB, and one in C9 (trunk) and one in C10). So the history for my changed file looks like this:
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
When I merge C10 from trunk to RB, I'd expect to see a merge window showing meC10 | C3 | C7 since C3 is the common ancestor revision and C10 and C7 are the tips of my two branches respectively. However, my merge tool shows me C10 | C9 | C7.
My merge tool is configured to show %1(OriginalFile)|%3(BaseFile)|%2(Modified File), so this tells me TFS chose C9 as the base revision.
This is totally unexpected and completely contrary to the way I'm used to merges working in Mercurial or Git. Did I get something wrong or is TFS trying to drive me nuts with merging?
Is this the default TFS Merge behavior? If so, can you provide insight into why they chose to implement it this way?
I'm using TFS 2008 with VS2010 as a Client.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在 TFS 分支和合并方面也遇到了一些类似的初始困难（我们有开发分支、集成分支和主分支）。
简而言之，您不能直接从尖端合并回共同祖先。
因此，如果 C3 分支到 C5，然后 C7 分支到 C9，则该工具提供的内容在 TFS 工作方式的上下文中是有意义的。您基本上需要从 C10/C9 到 C7，然后从 C7 到 C3。
用一个更具体的例子来换一种说法，以下是我们在项目中处理多级分支和合并的方法。
我们从主干/主干开始。
然后我们分支到集成分支。
然后（这是关键）我们从集成分支到我们单独的开发分支，以便我们可以处理即将发布的版本。
当开发分支中的更改完成时，我们首先通过从集成合并到我们的开发分支来进行反向集成（这样我们就可以获取其他人的更改）。然后，我们从单独的开发分支转到共享集成分支来进行转发集成。
一旦集成通过了 QA，我们就会通过将主干合并到集成来进行反向集成（以防主干中存在任何修补程序），然后将集成中的所有组合更改向前集成到主干中。
在发布日，我们将最后一个分支从主分支转移到新的发布分支，然后进行部署。
基本上，在 TFS 中，您始终必须在分支/合并树上从主干到肢体、从分支到叶子来回移动 - 您无法在任何时候绕过分支层次结构中的任何步骤。
打个比方，TFS 分支和合并更像是树懒爬上树，慢慢地爬到树枝的末端，永远不会失去它的抓地力，而猴子则在树枝之间跳跃；）
需要一点时间来适应，但一旦完成（特别是一旦您习惯了正向集成/反向集成范例）它会很有效，特别是当您有几个人都在进行开发并且您需要在不让事情被踩踏的情况下完成每个人的更改时。
希望有帮助！
I had some similar initial struggles with TFS branching and merging (We have dev, integration, and main branches).
Short version is that you cannot merge directly back from a tip to a common ancestor.
So if C3 was branched to C5, then C7 was branched to C9, what the tool is providing makes sense within the context of how TFS works. You essentially need to go from C10/C9 to C7 then from C7 to C3.
To put it a different way with a more concrete example, here's how we handle multi-level branching and merging in our projects.
We start with trunk/main.
We then branch to an integration branch.
We then (and this is key) branch from integration into our individual dev branches so we can work on upcoming releases.
As changes are complete in a dev branch, we first reverse integrate by merging from integration to our dev branch (so we pick up everyone else's changes). We then forward integrate by going from our individual dev branch to the shared integration branch.
Once integration passes QA, we then reverse integrate by merging trunk to integration (just in case there are any hotfixes in main), then forward integrate all of the combined changes in integration down to main.
On release day, we do one last branch from main into a new release branch which we then deploy.
Basically, in TFS you always have to go up and down the branching/merging tree from trunk to limb to branch to leaf - you cannot at any time bypass any step in the branch heirarchy.
Metaphorically, TFS branch and merge is more like as sloth crawling up a tree and slowly down to the end of a branch without ever letting lose it's grip vs. a monkey hopping between branches ;)
Takes a bit of getting used to, but once done (and especially once you're used to the forward integrate/reverse integrate paradigm) it works a treat, especially when you have several folks all doing development and you need to wrap up everyone's changes without having things stomped over.
Hope that helps!
我之前浏览过这个网站并发现了这个页面，这有帮助吗？
如何在 TFS 中分支和合并
i was looking around this site before and came across to this page, is this helpful?
How to branch and merge in TFS
我认为您可能有一个错误的合并方法，因为您所描述的完全可能，并且它对我有用。但你总是要记住，当你开始分支主分支时，要进行适当的 RI（反向积分）和 FI（正向积分）。在 codeplex 上搜索分支指南和最佳实践。
本质上，任何回滚到主分支的更改都必须在合并回之前重新部署回其他分支。这是最佳实践，每次都有效，之后，您可以继续从分支 FI 回到主干。
I think you might have a wrong merge methodology, because what you describe is completely possible, and it works for me. But you always have to remember when you start branching off the main branch is to do proper RI (Reverse Integration), and FI (forward integration). Have a search on codeplex for branching guidelines and best practices.
In essence, any changes that is dropped back to the main branch have to be RI'd back onto your other branches before merging it back. This is best practice and works every time, after that, you can continue to FI from branch back to main trunk.