2014-09-30 47 views
0

我最近继承了一个没有版本控制的ASP.Net Web窗体项目,我试图将它移入TFS。在某个时候,项目被拆分为一个客户端的定制版本,其中登录使用ADFS而不是我们的数据库驱动的表单。拆分后,一些功能被添加到主版本中以管理用户;这些在自定义版本中不需要。对一个版本的任何更改都会被手动应用到另一个版本(如果它们影响到非定制部件的话)(尽管可以预见,这有时会被遗忘)。TFS分支的自定义版本,排除这些自定义从合并?

每个版本有开发和生产服务器上的文件夹,这样的文件夹结构是这样的:

/Production/General 
/Production/Custom 
/Dev/General 
/Dev/Custom 

假定这将是困难的两个版本,功能切换完全合并,什么是最好的方法来管理这个?

我在想我可以使用差异来拉出生产版本的共同点,并使我的主要分支。然后,我可以从主让两个生产版本分支,有其当前的状态作为第一个办理登机手续,然后做类似的事情在开发文件夹,如:

- MAIN 
    | |- General 
    | |- GeneralDev 
    | 
    |- Custom 
    |- CustomDev 

但是,我不知道如何管理合并。有没有办法阻止某些文件仅在特定分支之间合并?如果我在CustomDev中进行了更改,我想将它正常地合并到General中,那么我希望能够将此更改转换为General和GeneralDev,而不必将Custom的所有其他自定义设置为...

Is there a这样做的方式(无需每次合并时都排除文件),还是只需将这些视为两个单独的项目并手动同步更改?

回答

0

使用分支机构应该简化合并操作,只需手动完成,因为分支机构可帮助您了解更改的历史记录。您可能需要定义一个合并的谨慎程序,以确保合并总是正确完成 - 这可能涉及限制允许合并的人员,因为经常有太多厨师可能会损坏汤汁。

但是,考虑到在这种情况下不断增加的合并成本和风险 - 这是一项巨大的技术债务,因为任何需要合并的变更都需要4倍的成本才能实现。只是测试两个分支不受小变化的影响是很困难的,因为您必须检查并合并,然后才能确定它是否正常 - 最好能够在您的PC上构建两种变体并在您检查任何内容之前对其进行测试in。

至少你应该尽量减少所需的合并,所以看看你可以在什么地方重构代码库(可能会逐渐逐渐减少)以减少合并的需要。看看你得到最多合并流失的代码。也许你会发现,在你的登录类中有几个需要合并的方法,其余的可以共享 - 所以使用分类或单独的cpp文件或将代码分解成助手或派生类 - 任何可以实现将这些方法分解为单独的文件。然后,只需要合并共享的一段代码,而不必连续不断地合并每个更改。随着时间的推移,您可能能够正确隔离和模块化非共享代码。

但是,我建议不要在任何合并必须双向的情况下进行分支。

另一种方法是分支合并和逆合并。对两个代码库进行区分,并在任何有区别的地方将代码的两个变体放在一个条件编译块(#if ...#else ... #endif)中,以便可以从一组源代码文件。这很丑陋,但允许您在没有任何分支或合并的情况下处理代码 - 您的开发人员仍需记住编译这两种代码的变体,以确保他们的更改能够在两个版本中工作,但这比合并并重建这两个变种。再次,随着时间的推移,寻求模块化差异,以便可以最小化和/或聚合以最小化影响。这种方法也可能允许将行为的某些部分更改为运行时而不是编译时选择,因此一些行为可以以不同且更有用的方式重新使用。使用体面的差异工具(例如Araxis Merge),即使使用大型代码库,这也不算太糟糕。几天的重构痛苦可以为您节省多年的麻烦。

我知道我在暗示你想要避免的事情,但越早解决技术债务就越痛苦。在短期内平滑症状与分枝会更容易,但永远不会解决潜在的问题......而技术债务的事情是,越久离开它越糟糕。