在公司的项目开发过程中，我们在项目开始之前根据设计搞开发了一个单独的UI组件库 Components，在正式的项目里面前中期都是通过将我们的组件库通过npm包管理的方式在项目里面去引用，再import需要的组件；在一次发版后线上出现一个较为严重的问题，在线下复现查找问题 debugger 的时候, 调试到组件库的代码时，由于是经过打包的代码十分难以调试基本上全是 n啊 v啊，一堆看不出语义的变量，以至于没有办法快速定位是业务代码还是组件库里的逻辑有问题（尽管后面还是定位到了问题出现在业务代码里面。。）。

这种情况下，我们决定把组件库的代码引入到项目里面，通过子模块的实现引入进行管理，实际项目也没有通过npm包的形式引用组件库，直接放在了本地通过 Next 提供的 Dynamic 模块来进行组件的懒加载（暂时也没有太多的替代方案）。主要涉及到 git subModule 相关的操作。

子模块的管理和使用

实际上就是在一个git仓库下面将另一个 git 项目设置为项目的子模块(submodule)。这个子模块它是一个第三方开发的Git 库或者是你独立开发；既可以达到使用子模块中的代码的目的，两个项目又具有相对独立的提交。

通过 git submodule 可以查看当前子模块的信息如下：
子模块信息
包含子模块当前指向的commit_id 名称以及版本等其他信息

两个项目各自独立管理、在子模块有修改后更新子模块的指向

配置多个SSH

在工作中多访问公司的gitlab仓库，而在生活中又有自己的github仓库
记录一下方便日后查找

一般电脑中的SSH key 存放在 ～/.ssh目录中 如果有配置过的话存在 id_rsa \ id_rsa.pub 私钥和公钥, 将公钥配置到需要的代码平台

生成SSH key

本地配置多个ssh key

• 1、为公司生成一对秘钥ssh key

  ssh-keygen -t rsa -C 'yourEmail@xx.com' -f ~/.ssh/gitlab_id_rsa

• 2、为github生成一对秘钥ssh key

  ssh-keygen -t rsa -C 'yourEmail2@xx.com' -f ~/.ssh/github_id_rsa

• 3、在~/.ssh目录下新建名称为config的文件（无后缀名）。 用于配置多个不同的host使用不同的ssh key，常用内容如下：

  # gitlab Host gitlab.planetmeican.com HostName gitlab.planetmeican.com Port 2345 User git PreferredAuthentications publickey IdentityFile ~/.ssh/gitlab_id_rsa # github Host github.com HostName github.com PreferredAuthentications publickey IdentityFile ~/.ssh/github_id_rsa

配置文件参数

# Host : Host可以看作是一个你要识别的模式，对识别的模式，进行配置对应的的主机名和ssh文件
# port: 端口号，一般不需要配置
# HostName : 要登录主机的主机名
#PreferredAuthentications: 授权验证方式
# User : 登录名
# IdentityFile : 指明上面User对应的identityFile路径

• 4、分别往gitlab和github上添加生成的公钥

ssh-agent 与 SSH的区别

参考链接

Git 常用的命令笔记

Commitizen是一个撰写合格 Commit message 的工具。

本地分支重命名

git branch -m old new

git所有的命令都是以git开头 后面为所要做的操作 再后面即为参数

• 初始化 git init 初始化后会生成.git文件
• git clone URL 将URL地址下的资源clone到本地
• git add . 将当前目录下面的文件提交到暂存区
• git commit -m ‘你所做的修改，利于以后维护和回退’ 会得到一个指针
• git push origin master 上传代码到github master分支
• git branch 查看所有分支
• git branch hexo 新建名为hexo的分支
• git checkout hexo 切换到hexo分支
• git merge 合并指定分支到当前分支

##git合并分支
 git支持很多种工作流程，在进行合作开发时一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：

1. 去自己的工作分支

   git checkout work

2. 工作
   ….

3. 提交工作分支的修改

   git commit -a

4.回到主分支

git checkout master

5.获取远程最新的修改，此时不会产生冲突

git pull

6.回到工作分支

git checkout work

7.用rebase合并主干的修改，如果有冲突在此时解决

git rebase master

8.回到主分支

git checkout master

9.合并工作分支的修改，此时不会产生冲突。

git merge work

10.提交到远程主干

git push origin master

这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突.

可以在一条分支上一起开发，你有变更的时候，在提交前，使用

git stash

这样将本地的修改全部缓存在一个堆栈中了，然后把别人的修改同步过来

git pull –rebase

下一步是将自己的变更恢复到最新的节点上

git stash pop

然后再使用git commit提交，这样就会让一个分支的版本按顺序继续发展