nightire
@nightire
注册于 2015年2月15日
As a designeer, I hope you can prove me wrong.
关注功能不可用
关注了
1024
关注者
65532
极客科技生活方式文艺范儿设计艺术吃喝玩乐喜闻乐见其 他草 稿
  • 9 项
    最近更新:4年前

    子树(Subtree),既不是子模块(Submodule)也不是合并策略中的子树合并(Subtree Merge),它虽然不是 Git 内建的功能,但子模块和子树合并的优点都兼而有之,并且它比子模块更简单,比子树合并更全能。

    子树能干什么?最典型的应用场景就是你有一个项目,这个项目里面包含有子项目,你希望子项目可以单独拥有版本控制(因为子项目可能可以重用于其他项目),但由于子项目被包含在主项目中,因此你也不希望总是在两/多个仓库(Git Repository)之前来回切换。于是子树可以做到的就是:

    1. 所有的操作都在主项目中完成,使用的都是 Git 的常规指令,唯一要学习的就是子树子命令
    2. 子项目拥有自己的版本控制系统,也就意味着可以拥有独立的历史记录
    3. 本地发生的变更可以分别推送至主项目和子项目,并且只有涉及到子项目相关的变更才会被推送至子项目,子树分离的细节由 Git 在背后掌控
    4. 分离的子树由于拥有独立的版本控制,所以可以很方便的整合进其他的项目,并且可以做到一处变更多处生效
    5. 子树的版本仓库同样拥有完整的 Git 特性,比如分支、标签等,因此分离/整合子树也可以做到分支和标签控制等

    好处固然很多,但是坑也不会少。本单(系列)的目的就是简明扼要的介绍子树的使用方法以及注意事项。

    对于子树的使用,有一些很经典的场景,比如说创建子树的过程可以是从无到有的,也可以是从一到多的。具体而言,从无到有就是在项目启动的一开始就有计划的使用子树在其中,而从一到多则是项目已经进行了一阵子才决定总中分离出一个或多个子树。二者的主要区别在于是否有涉及到主项目或子项目的代码产生,因此创建子树时的考量和具体步骤也会略有差别。

    本单介绍第一种,即从无到有创建子树。