我们在发布周期中维护多个TFS分支.当前流程是在完成用户故事时将WIP分支中的变更集挑选到测试分支.
我很想知道git-tf是否允许以这种方式使用多个远程分支,并且它是否能够检入合并而不是检查看起来像新代码的代码.
这里有一个讨论:
并且有人提到git-tfs不能与直接使用VS的其他人玩得很好.有谁知道git-tf的情况如何？
此时,git-tf并不代表同的Git分支TFS分支,不翻译在任一方向合并-也就是说,它不会在合并检查,也不会显示一个TFS的结果合并为一个git合并.这是一个非常重要的问题,因为两个体系结构中的合并之间存在一些非常基本的差异.
TFS合并为git merges:
在git中,您合并两个提交,最后得到一个结果提交.TFS看起来很相似 - 因为您选择了合并源和目标变更集,但合并源不必是变更集.您可以根据标签,工作区版本,日期等进行合并.这意味着您最终可以最终合并来自多个不同更改的不同文件.这是一个容易解决的问题(最终,我认为,将其表示为一些疯狂的章鱼合并).
一个更难解决的问题是基于TFS分支创建git分支.这更像是一个设置问题 - 即你想要哪些分支？他们都是？他们中有一些？如果答案是"所有这些",那么在进行初始克隆时很容易设置.但对我来说,这是第一次设置的数百个分支机构,而且价格昂贵.如果答案是"其中一些",那么当你进行克隆时你必须全部指定它们,否则你最后会以恶劣的方式重写git历史.
git合并为TFS合并:
在git中,分支是一种短暂的.它实际上只是指向树中节点的指针......没有长寿状态说"提交1b4caf曾经在分支中" branch.想象一下,你有一些master指向TFS分支的$/Proj/maingit分支和另一个test指向的git分支$/Proj/test.在git中,你合并test到main.没问题,在这一点上main的HEAD承诺有父是test的HEAD.但是如果你开始改变test分支中的东西,很快就很难确定.
此外,现在git-tf将单个git分支映射到您的TFS服务器路径.对于合并签到,我们必须立即检查多个分支.假设你做了一些提交master和一些提交test然后合并他们HEAD的每一个.现在我们必须检查每个TFS分支的几个提交,然后进行合并.这不一定很难,但它与git-tf目前的工作方式背道而驰.
这绝不是一个不可能的问题,但需要一些巧妙的工程和一些巧妙的测试.但它还没有.
| 归档时间： |
|
| 查看次数： |
1102 次 |
| 最近记录： |