从形象上理解，版本库可以简单理解为一个目录，这个目录里面的所有文件都可以被管理起来，每个文件的修改、删除，都能被跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。版本库是版本控制实现的基本集合，通过一个单一的基线可以获得该版本库的快照，所有受控文件都属于某个版本库。一般的，一个小系统的全部源代码、文档、配置文件等存放在同一个版本库当中。除了支持版本控制所需基本功能，版本库最重要的功能是分支功能。与分支相对应的是主干，主干可以形象地理解为“本尊”，分支可以形象地理解为“分身”。在版本库中一般用诸如“trunk”或者“master”作为主干的名称。使用分支意味着可以把不同工作从主干上分离开来，以免影响主干。常见的分支功能有新开分支以及合并分支，可以基于最新主干或者最新分支或者任何历史基线来创建分支，可以合并任何两个分支，常见的合并方向是从分支向主干合并。由上可见，分支使用极为灵活，使用得好，效率提升；使用不好，可能出现分支地狱（过多分支难以区分和管理使用），因此软件开发必须考虑选择合适的分支策略。

分支策略有如下四大模式：①先锋主干多稳定分支。在得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。这是业界产品型软件采用较多的模式。稳定分支上的有些修改，比如缺陷修复，需要合并到主干，但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱难以合并，所以这个分支策略选择需要谨慎。②守护主干多先锋分支。在得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容推荐在不同的分支上开发。从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。在不确定的情况下，推荐拉不同的分支，这样可以灵活地选择合适分支合适时机来合并到主干。③主干无分支。只有主干，没有分支，所有紧急的和正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙地藏起来。对程序的结构提出了高要求，分分合合要方便，需要利用功能开关配置。单从效率讲，这是最高效的模式，但要有内建质量的配套措施才可以。常见的配套措施：持续集成、每日构建（编译部署更大范围测试），静态代码检查。④守护主干单分支。只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设持续集成。

以上四种模式并不是选定后就不能改变，可以结合出现的情况进行转换。主干无分支开发时碰到特殊情况时，拉短分支。在先锋主干稳定分支开发时与主干无分支，是可以在一段时间内相互转换的。守护主干多先锋分支与守护主干单分支结合使用，就是双主干多分支开发模式，最新流行的GitFlow就是这个模式。