版本控制：为什么做版本控制，版本控制历史，如何避免版本冲突

---

1 why use version control:
1.1 合作：
1.2 代码维护：
其实主要的目的是：同步，分享；
还有个好处是历史坚持：
坚持写SVN - LOG,好的svn log有标准的规范写法：例如： [BUG-001][ByGroup][Who][Date]

2 常用的版本软件发展过程：
2.1 服务器：
cvs,svn,svk

2.2 分布式，或者说没有服务器版本：
gc×t,mercurial/hg,hazar
不同点：
svn等必须要有一个服务器端：
分布式的好处是，当支持客户的时候，能够在没有网络的时候进行版本控制：
分布式代码最后总是合在一处的，所以和开发者人员多少无关：

---

如何避免版本冲突？
1 软件版本主干是其他组做的怎么办？
|
|----------------|
|                     |
Patch            Branch
|                     |
|                     |


首先：做好版本标号
然后：当发现一个bug，你准备做版本更新时候
如果，改动不是全局全面的话，你可以用打Patch的方式，保留修改前的状态，
从而减少主干改动带来的冲突

2 如何在代码里面避免冲突：
目标减小主干和自己修改冲突：
2.1 make 的改动：
新建经常修改的文件名，作为原有的copy:
比如我要加一下新的模块，如果要修改makefile,我们最好不要直接在原有的makefile上修改：
最好是建立一个新的build.makefile.xxx
这样，在版本工具更新的时候，这样就不会覆盖原有的makefile.

2.2 代码里的冲突避免方式：
原则：少动主干的东西，新建自己的改动文件，放在一起

比如：我们的branch开发团队的组名是：FSS
枚举，头文件：
头文件 -
比如：
原来： --/inc/sys_api.h
新建：--/inc-fss/sys_api.h

对于枚举：
可以在枚举元素里加前缀：fss-
如此一目了然：

对于switch case:
    Fss_case_function(); // 先于原有的case做处理：

switch()
{
case ....
    break:
   ....
case ....
    break:
   ....
default:
    Fss_case_function();
    break:
}
    Fss_case_function(); //也是一个switch case ，只不过是原有的switch case的扩展，并先于原有的switch case 执行：

---

C 语言的面向对象设计：

Struct A
{
    data
    function
    close //虚函数和析构函数
}

如果不想别人析构，那么你的虚函数不要变成实函数

Struct B
{
    Struct A
}

function
fun (A* )
fun (B* )
函数指针必须转换，那么在GDK里面会定义一个宏

---

单元测试：
Cunit
敏捷编程，极限编程：
基本设计思路：规范设计，需求分析，概略设计，详细设计。。。。
但，客户需求并不是不变的，
如何保证，需求变化后，我改动了一些代码，不会影响到其他代码呢？