Attack on Life ⚔️

Git Submodule允许你将一个Git仓库作为另一个Git仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。
最近在实际项目开发中，用到了，也遇到一些细节问题，所以将Git子模块常用操作总结如下，以备不时之需。

添加子模块

1
2
3
4
5
6

# 添加子模块
$ git submodule add https://github.com/alanhg/Angular-group.git

# 设定映射路径lib
$ git submodule add https://github.com/alanhg/Angular-group.git lib

关于具体使用设定下，执行help命令

背景

最近在开发一款APP-CodeTracker,其实就是使用WakaTime-API拿到一些数据进行APP展示，而获取这些数据有两种办法，第一种是本身WakaTime账号给与的API-KEY，另一种方式是oauth2授权，用户通过登录账户授权给该APP，进而拿到授权后的令牌，获取相关信息。
本身输入API-KEY是最简单的方式，但是在实际使用中，因为APIKEY是很长且无需的字符串，用户并不可能记住，所以必须实现授权登录，查阅资料最终实现了这个功能，效果如下

实现方法

主要代码

使用场景

耗费一年心血的项目上线已经有了一段时间，觉得可以喘口气了，这个时候领导下达命令，需要开发B项目了，但是B项目有这样一个特征，就是跟A特别像，这个像是从功能、展现形式等等都很像，领导希望能够快速开发出来，基于此，我就需要考虑如何能够解决这个架子改造及实现最大程度的code复用问题。
我参与的项目整体技术架子如下:
Angular(frontend)-----------------node-express(backend)
当时咨询了很多的人，自己也想过，因为公司项目本身是在gitlab上管理的，所以随之有以下三个方案:

1. 一个仓库下，直接各个项目的都存在，仅仅是文件夹层面的区分,通过参数来控制
2. 分支化处理，比如branch-project-a,branch-project-b
3. git-submodule

方案对比

对比这三个方案,分析:
方案1肯定是直接否掉，因为这样子维护性就低的要死，仅仅是dev短期方便，但是人工造成错误的可能性及维护性都低，方案2，可以，但是这样就意味着多个项目是在一个仓库下进行dev和管理，那么换句话说这个developer的人就具有轻易的动多个项目的可能性，我认为这样子是很可怕的，另外，项目A与项目B的差异性开发就会导致未来分支数目众多，维护合并都不够清晰，简单，毕竟本来就不是一个项目，只是相似，仅此而已，so我认为方案2也应该杀掉。
方案3，git子模块方案相当于将部分code抽离成独立的一个仓库，然后利用git的子模块机制进行映射引入，然后本身子模块也是个仓库就可以独立开发维护，项目中引入后，只管像用第三方包的方式一样去使用即可。
思来想去，我认为方案最终要体现两点:项目A与项目B是两个相同，就决定了必须是独立的存在；项目A与项目B有相同点，决定了有一定的复用，所以基于此，确定选方案3

Travis CI is a hosted, distributed[2] continuous integration service used to build and test software projects hosted at GitHub.

背景

在github上部署了个人blog，为了便于在不同工作台上进行blog，所以将blog平台源码作为blog仓库分支也托管上，目前仓库下有master(静态页)，source(源码)。

CI化之前

每次增加新blog后，需要依次执行以下动作

最近客户提出一个要求，就是虽然我们已经有了移动网页版站点，但是让客户记住网址，输入网址这个是很辛苦的，那么就需要有APP，但是单纯开发APP的成本还是不少，那么如何最大限度的复用既有的东西呢，比如移动网页版，这个时候就催生这么一种解决方案，利用Cordova这种混合开发工具将移动站点打包为APP，那么APP这种存在就有了，对于特定客户，其实APP跟网页唯一的区别只是存在形式的不同，并不需要有什么差异性的功能，那么这种情境下，将M站点进行打包APP就再合适不过了。

可行性

能打包吗？

答案：OK,说白了就是利用系统浏览器打开网页,cordova有浏览器插件,所以肯定可以。

能上架吗?