使用git的分支功能实现定制功能摘取与组合的想法

前言,这个想法应该是git比较通用的做法,只是我还没用过,所以把自己的想法记录在这里,督促自己以后按这个方式执行。

 

我们公司现在面临一个问题, 就是客户的定制需求很多,很杂,其中坑爹需求很多。

我还没真正面对过这些问题, 不过以在上一家公司的经验,有一些坑爹的需求,往往先加进来,用一段事件后,又会被还原成原本的样子。

对于这种问题,以前是没有很好的解决方案的,因为这种坑爹需求从加入到还原,中间还插入过很多其他的功能点修改。

很难一步还原。 

而我想到的方法是这样的, 其实应该也是git建议的用法,

即每次有新的功能点需求, 都为这个功能点创建一个分支,如fp1(function point1)分支,在该分支下做专属于这个功能点的改动。

如果其中需要改动到公用或全局的东西,理想情况下就先切换回主分支(一般是master)上,重构代码后,再到fp1下完成专属于功能点的改动。

在完成fp1后,再将其合并到master上,注意要写好提交的comment。

这样,在经过若干个功能点的提交之后。如果发现某个功能点需要被删除,或者要求被还原,这是,只要找到这个功能分支的合并提交点,将该次合并的修改还原即可。

 

这个方案还有2个明显的问题没有考虑清楚:

1.每个功能点分支在合并到主分支之后,是否要删除?

2.如果删除了,而这个功能点需要再次扩展或维护时,怎么办?

3.如果不删除,在经过较长时间后,再修改该功能,是否将主分支合并到该功能分支上,再进行修改? 如果是这样的话,会不会有什么问题?

 

 

对于上述3个问题,期待有经验的同学解答。 我暂时采取的解决方案是:

分支在合并后,短期内不删除(如一周或一个月,视项目组开发情况而定),在短期内不再出现改动后,删除分支。 但是在提交时注明功能点分支名称和合并说明。当需要根据该功能点进行维护时,新建分支,如果原分支名为fp1,那么新分支取名要和原分支名能明显看出有关联,如fp1-1。

在分支fp1-1合并后, 如果发现fp1需要整个还原,则找出fp1和fp1-1的合并记录,依次还原2次合并。 如果只要还原fp1-1,则只还原fp1-1的合并即可。

 

 

个人的想法就到这里, 由于只是想法,还未经过实践, 而实践是检验真理的唯一标准,所以接下来的工作我会实际试试我的想法,看效果如何。

之后如果有什么体会,或发现文中有什么错误,也会更新到该博文中。

 

 

posted on 2013-12-23 12:07  bee0060  阅读(...)  评论(...编辑  收藏

导航