以下是该方案。
我们正在开发一种产品，我们拥有产品的基础产品和区域变体。我们已经将所有公共代码检入主干线，同时我们为主干线的变化创建了2个分支（branch_us，branch_uk）。有一些常用的代码不断被检入主干，而被检入branch_uk的代码，branch_us依赖于检入主干的代码。这样做是因为我们期望在未来的版本中添加更多区域，因此我们希望最大限度地重用以及薄区域变化层。
根据当前的策略，开发人员必须在本地开发，然后手动将常用文件签入main_trunk和区域变体，分为branch_uk和amp; branch_us。然后每次将代码检入main_trunk时，我们必须从 main_trunk-＆gt; branch_uk ＆amp;执行合并。 main_trunk-＆gt; branch_us 我们可以为branch_uk＆amp;执行构建之前branch_uk（两个单独的部署），因为branch_uk / us分支中的新代码依赖于main_trunk中的新公共代码。这种模式似乎非常痛苦地思考和非生产性。
我不是TFS的专家。以下是我的意见：
有没有办法TFS可以在每次签到后（在main_trunk中）动态地从main_trunk中将更改传入branch_uk / branch_us而不进行手动合并？
的
的
你们对代码管理过程有什么其他建议可能比现有的更有效/更高效吗？
的的
任何想法和反馈将不胜感激！
答案 0 :(得分：4)
这对我来说似乎是一种奇怪的架构，但当然我从一个几乎完全无知的位置来到它，所以可能有一个令人信服的理由以这种方式接近它。
话虽如此：听起来我觉得你没有一个具有两个区域变体的应用程序，你有两个独立的应用程序，它们共享一个共同的祖先。对你的问题的简短回答是＆＃34;否＆＃34;。一个稍微长一点的答案是＆＃34;不，但你可以编写代码来自动化它。＆＃34;
更周到的问答是＆＃34;你确定集中版本控制是适合这项工作的工具吗？＆＃34;使用Git可能更直观。实际上，您拥有的是基础存储库和该存储库的两个分支。开发人员可以针对任何有意义的fork进行操作，如果某些内容表示应该应用于所有本地化的更改，请打开pull请求以将更改合并到基本存储库中。这将需要开发人员更多的纪律，因为他们必须确保他们的提交是隔离的，以便他们可以打开包含适用于核心平台的只是提交的拉取请求。 Git拥有强大而又困难的历史重写工具，可以提供帮助。或者，当然，他们可以在核心平台上工作之间来回切换，然后将更改从核心平台拉回到单独的存储库。这会让你回到你开始的地方，但Git合并非常快，不应该成为一个大问题。
无论哪种方式，考虑本地化是单个应用程序是你的错误。
非源代码控制答案可能涉及更改应用程序的体系结构，以便所有本地化都使用相同的代码库，但具有特定于语言环境的功能，这些功能以配置标志和运行时可发现的MEF插件的组合表示，或制造一个＆＃34;核心＆＃34;作为独立服务运行的应用程序平台，以及单独开发的区域设置特定服务，仅表示与核心应用程序平台的偏差。