iOS project component library description
Component library name: test-sdk-ios
1. Description
Sometimes the project does not have a one-to-one correspondence between the component library and the git library. Libraries of the same type can be integrated into the same git repository and distinguished by different branches.
Generally speaking, the project consists of these: main project + strongly related business components (special functions such as third-party face recognition can be re-developed projects) + general business components (secondary development of network libraries, login modules, etc.) + foundation Business components (logs, common category method sets, databases, etc.) + third-party library components (afnetworking, masonry, etc.)
2. Branch Description
As mentioned above, each branch name can represent a component, and component upgrades and updates are distinguished by branch name + version number
1. Branch level directory
The branch hierarchy directory corresponds to different component levels. For example, k_base corresponds to the basic component level, k_common corresponds to the general business component level, k_Thirds corresponds to the third-party component level, and k_projectModule corresponds to the project strongly related business components. Under the branch directory are each component branch directory, one component branch directory corresponds to one component (module1, module2...)
2. Branch group directory
A branch group directory can have multiple branches, but only the branches related to the component are allowed to be stored.
Branch group directory naming rules: component name. Such as: LoginModule
3. Component branch
Component branches are development branches. You can create corresponding branches according to your own development needs, such as module_dev_1.0.0.
Suggestion: create different directories in {{branch group directory}}, corresponding to different branches, such as release, dev, hotfix, for easy management.
Note: There will be a branch with the same name as the directory under {{branch group directory}}, such as the {{module1}} branch under module1, which is equivalent to the master branch. After other branches are released, the modified content needs to be merged into this branch. The principle is Direct modification is not allowed on
4. Special branch
master分支：原本git仓库的默认分支，以后用不到
createPodDemo分支：新的组件从该分支创建出来
版本说明
1、相关说明
标签与版本
标签是git管理的一种手段，知识git某个提交的字符串描述，与库的版本不是完全相等的。如module1的{{1.0.0}}版本，可以对应git上饿{{1.0.0}}标签，也可以对应{{module1-1.0.0}}标签
cocoapods的版本管理及git标签的关系。
cocoapods的版本取的是module1.podspec文件中version字段的值，与git标签没有关系。
cocoapods获取某个版本的流程：
pod 'module',:git=>'git仓库地址',:tag=>'module-1.0.0'
复制代码这里直接通过git地址查找
四、安装及开发
1、远程引用
通过远程引用，知识对代码的引用，没有修改的权限。适合发布版本或者在开发模式不需要修改源码的情况。
引用tag和分支都可以，频繁修改就用分支
pod 'module',:git=>'git仓库地址',:tag=>'module-1.0.0'
pod 'module',:git=>'git仓库地址',:branch=>'branchName',subspecs => ['core','someother']
复制代码2、本地引用
在开发模式下，当需要对组件进行修改时，需要将组件改为本地引用
1、将代码下载到与主工程同级目录。
2、切到对应组件版本的分支，如module1-0.2.0-hotfix，切换至该分支。 3、修改podfile，将module1的远程引用改成本地引用
pod 'module1', :path => '../k_projectModule'
复制代码本地开发建议
我们很可能会同事对多个组件库进行修改，一个本地的k_projectModule库是无法满足的，可以将k_projectModule复制一份，将k_projectModule目录名改成相应的组件（如module2），然后在module2中切换到想要修改的分支。这样就不同频繁的暂存文件和切换分支。
五、新建组件
1. Determine the level of components.
2. Create a new branch from the createPodDemo branch.
3. Third-party components can directly find the source code and podspec, and drag them into the warehouse.