Aka*_*ava 6 git merge tfs git-branch
我们有一个庞大的产品,并且具有许多功能,每个功能都需要很长时间,因此我们在TFS中维护短暂的功能分支.例如,
MAIN/
PROJECTMGT
EMAILMGT
etc..
一旦完成,它们就会合并回MAIN,每个不同的开发团队都会在不同的分支上工作.
合并过程
由于每个团队在不同的分支上工作,因此没有冲突,但负责将分支合并到MAIN的人需要查看不同文件夹中文件的清晰视图.因为我们需要在合并之前测试和检查分支,我们还需要看到不同分支的冲突并清楚地解决它们.
现在我们正在转向git,当我正在学习git时,我在如何组织分支方面遇到了一些困难.在处理文件和文件夹结构时,我们不知道我们实际上在哪个分支.
我们刚刚对git进行了测试,我们大多数在多个分支上运行的人都感到困惑,我们在合并时也犯了错误.
TFS自动将所有内容合并到文件实际所属的同一分支中,而不指定分支.
我正在阅读这篇文章,我看到了一些关于创建多个克隆以模拟TFS类型的物理文件夹分支的建议.
有人可以指导我,我该怎么办？我正在使用Visual Studio Tools for Git.
UPDATE
根据评论,这是我们目前的困难.
每个分支都有单独的NuGet包版本,例如一个分支可能正在使用EF 5而新分支具有EF 6,切换分支很痛苦,因为它需要nuget恢复及其所有警告.
就像nuget包一样,我们在不同的分支中有其他第三方库(二进制文件)和不同版本的库.
在合并时,它一团糟,我们继续问自己我们在哪个分支,但是在VS中它很容易,因为物理文件夹路径告诉我们我们的分支.
我发现在三天前退房时我们记得哪个分支是完全愚蠢的.虽然VS Git Tools在您进入源代码资源管理器时显示它,但是当我们打开多个VS实例时,这也会失败.
我们正在寻找一种工作流程,而无需使用"SWITCH BRANCH".
小智 3
根据对问题的评论，这将是有关如何创建多个克隆（可能签出不同分支）的答案。
然而，这很可能不是最好的解决方案，原因如下：
每个额外的克隆都会使用额外的驱动器空间。
使用额外的克隆可能不是使合并变得更容易的最佳方法。在 git 中以这种方式处理合并问题是非常非常规的。
使用额外的克隆可能不是让测试变得更容易的最佳方法。
由于您提到您正在使用 GitHub，因此如果您还没有本地克隆，则需要执行此步骤。
git clone <url-to-repo>
这将克隆您的存储库并自动检出该master分支，假设该master分支是您在 GitHub 上设置的默认分支。
如果您想要单独签出 N 个附加分支，则可以通过重复以下操作为每个分支创建另一个克隆：
git clone <path-to-first-local-clone>
git checkout <branch>
请注意，每个克隆最终将使用至少与原始克隆一样多的驱动器空间。--shared通过使用或--reference选项也许可以减少所使用的空间git clone，但我对这些选项如何工作还不太了解。