Joh*_*lph 9 merge tfs branching-and-merging
我有一个发布分支(RB,从C5开始)和trunk(C10)上的变更集,我现在想要合并到RB上.
该文件在C3处变化(两者共用),一个在RB上的CS 7中,一个在C9(中继)中,一个在C10中).因此,我更改的文件的历史记录如下所示:
RB: C5 -> C7
Trunk: C3 -> C9 -> C10
当我将C10从主干合并到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作为客户端.
Bob*_*mer 13
我在TFS分支和合并方面有一些类似的初步斗争(我们有开发,集成和主要分支).
简短版本是您无法直接从提示合并到共同的祖先.
因此,如果C3分支到C5,那么C7分支到C9,该工具提供的内容在TFS如何工作的背景下是有意义的.你基本上需要从C10/C9到C7,然后从C7到C3.
用更具体的例子来说明一个不同的方法,这就是我们如何处理项目中的多级分支和合并.
我们从trunk/main开始.
然后我们分支到一个集成分支.
然后我们(这是关键)从集成到我们各自的开发分支分支,以便我们可以处理即将发布的版本.
由于更改在dev分支中完成,我们首先通过从集成到我们的dev分支合并来反向集成(因此我们接收其他所有人的更改).然后,我们通过从我们的各个dev分支转到共享集成分支来转发集成.
一旦集成通过QA,我们然后通过合并主干到集成来反向集成(以防万一中有任何修补程序),然后将集成中的所有组合更改向下集成到main.
在发布日,我们从main进行最后一个分支到我们随后部署的新发布分支.
基本上,在TFS中,您总是必须在分支/合并树上上下移动从树干到肢体到分支到叶子 - 您不能在任何时候绕过分支层次结构中的任何步骤.
隐喻地,TFS分支和合并更像是树懒爬上树而慢慢地下到树枝的末端,而不会让它失去它的抓地力而不是在树枝之间跳跃的猴子;)
需要一点时间来适应,但一旦完成(尤其是当你已经习惯了正向集成/反向整合模式)它的工作原理一种享受,尤其是当你有几个人都在做开发,你需要包裹起来每个人的变化没有东西踩到了.
希望有所帮助!