版本控制

版本号

1. 主版本号
   就API修改而言，主版本号的改变表明添加了大量向后兼容的新特性，或者向后兼容性遭到了破坏。总之，API主版本号的增长向客户表明API进行了重大修改。
2. 次版本号
   每当添加较小的特性或修正重大错误时这个数会增大。次版本号的修改通常不应该涉及任何不兼容的API修改。用户应该能够升级到新的次版本，而不必对自己的软件做任何改动。不过一些新的特性可能被添加到API中。
3. 补丁版本号
   补丁版本号的变更应该暗示现行的API接口没有修改，也就是只有API的行为有所改变。

提供API的版本信息

API的版本信息应该可以在代码中访问，以便允许客户以API版本号为条件编写代码。

//version.h#define API_MAJOR 1#define API_MINOR 2#define API_PATCH 0class Version{public:    static int GetMajor();    static int GetMinor();    static int GetPatch();    static std::string GetVersion();    static bool IsAtLeast(int major, int minor, int patch);    static bool HasFeature(const std::string &name);}

软件分支策略

大型软件项目通常会涉及某种形式的分支策略，这就需要同步开发、固定及维护不同的软件发布版本。

分支策略

每个软件项目都需要一条”主干”代码路线，它是项目源代码的持久存储库。对于每次版本发布，或者必须与下次发布区分的开发工作，可由主干代码派发出分支。这个模型支持并行开发，可以将新特性加入项目，同时锁定对即将发布版本的修改，使现存的特性集保持稳定。

只在必要时再分支，尽量延迟创建分支的时间。尽量使固体不过分支代码路线而非冻结代码路线。尽早且频繁地合并分支。