前言，这个想法应该是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的合并即可。

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

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