Apollo CLI is a productive tool when integrate Apollo into your application. It can:

1. service:push - Publish Schema to https://engine.apollographql.com, share among your team.
2. client:codegen - Generate TypeScript interface definition from GraphQL schema.

Install Apollo CLI

1

npm i -g apollo

Publish Schema： service:push

Here we assume you’ve already started Apollo Server(Started on port 4000). Open https://engine.apollographql.com in browser, create a bucket named magic-mooc， Then run :

1

apollo service:push --graph=magic-mooc --key=user:gh.guoguolong:vKOUWxxp71eyns94RnorPg --endpoint=http://localhost:4000

it’ll publish schema to engine.apollographql.com. Let your other team members check it.

You can also move the command arguments into the file .env and apollo.config.js, then simply use apollo service:push to publish it.

# apollo.config.js

1
2
3
4
5
6
7
8

module.exports = {
    service: {
        name: 'magic-mooc',
        endpoint: {
            url: 'http://localhost:4000/graphql'
        }
    }
}

# .env

1

APOLLO_KEY=user:gh.guoguolong:vKOUWxxp71eyns94RnorPg

Try aplollo service:push again.

Generate TypeScript definition file：client:codegen

We often develop ReactJS with TypeScript for type check. apollo client:codegen can check all the source code under src folder and it’s sub-folder. If find any gql definition, it’ll generate TypeScript interface into the generated folder for subsequent use.

Unfortunately, I only succeed it by the file way(schema.gql). below is the sample I made:

Step 1. Create apollo.config.js

Move to project root folder(You should have src sub-folder and some of the gql definitions), create apollo.config.js like this:

1
2
3
4
5
6
7

module.exports = {
    client: {
        service: {
            localSchemaFile: "./schema.gql"
        }
    }
}

Step 2. Download schema.gql

Open Graph Endpoint in browser: http://localhost:4000, easily find the gql definitions then download it as schema.gql

Step 3. Generate TypeScript Interface

1

apollo client:codegen --target typescript --watch

Reference：Configuring Apollo projects

A NodeJS Web Framework based on ExpressJS

Git工作流程种类繁多，常见的有：

Git flow: http://nvie.com/posts/a-successful-git-branching-model/
Github flow: scottchacon.com/2011/08/31/github-flow.html
Gitlab flow: http://doc.gitlab.com/ee/workflow/gitlab_flow.html

三种流程各有特点，无所谓哪个更好，各有特色。鉴于我司各个技术层次工程师现状和项目种类，我们需要定义组织内特有的git流程，并分级、分阶段实施.

前面提到我司项目种类，主要是两大类：

- 上线类项目：有master分支并被TMP控制权限的Web项目。

- 非上线类项目：分支任意设置，通过 gitbucket 系统直接管控分支权限（如果需要），但通过非tmp渠道上线的项目（如npm包引用、app渠道发布）。

A. 上线类项目的git流程

三个Level的简化流程

Level 1: 遵从TSP/SVN发布流程(并行合并到master)

远程仓库分支看起来：

1

master branch test

关键特征

• master作为发布分支
• 多个迭代的功能可能同时存在于每一个分支.
• 每个迭代开发团队自行进行分支合并

基本工作流程

1. JIRA自动创建git项目：默认创建好branch、test、master分支(master分支等同于svn的stable分支)
2. branch分支：总是在branch下开发——实质含义是：开发时期代码总是共用远程branch分支，至于本地对应分支名是任意的，虽然我建议你使用同名branch作为本地分支.
3. test分支：开发完提交到远程branch，开发人员测试通过后，合并到test分支提交给测试人员 —— 和svn一样，是使用cherry pick合并，不是全量合并！否则你会把别人branch上的代码也合并过去.
4. master分支：测试人员将test分支部署测试完毕后，亲自或授权开发人员合并到master分支：建立JIRA单，走TMP发布流程申请权限，然后提交合并代码到master分支.
5. 发布：通过TMP发布maser分支代码到PRE，测试通过后再发布到PRD，

如果遵从上面的步骤，你几乎与tmp/svn发布项目有完全一样的感受——tmp/svn有的问题，这里都存在！ 该git流程设置存在一个更致命的问题：tmp/svn上线功能的时候，能明确指定jira号对应的更新文件，以免误发他人的文件到线上；而git(无论Jenkins还是docker部署)只能指定head或特定版本号发布，这将几乎无法避免地带上他人合并到master但还没发布的代码.

BTW，在这个流程中，没有提及使用任何工具code review，实质是: 真的和tmp/svn方式一样—— 在你合并到master分支前，告诉code reviewer自己提交的代码版本号，code reviewer择机git pull下来进行查看，间接或者直接修改后提交。

注：对于极微团队，分支间同步更粗糙的方式是：全量合并，前提要保证远程开发分支代码在合并前可构建运行.

Level 2: cherry pick串行合并到master

远程仓库分支看起来：

1

master branch test

Level 2是在Level 1的基础上的改进，以下仅介绍差异：

关键特征

• 设置Merger 角色：专门负责合并test到master分支.

基本工作流程

1. test分支：假设有F1、F2两个特性均到了test分支，当天都测试通过后，分别向Merger提交了merge到master分支的请求，要求上线。
2. maste分支：Merger收到多个合并请求，根据业务安排，Merger同一时刻仅能选择1个特性合并到master，然后测试发布，直接该特性上线完成，才能继续合并第2个合并请求，反复前面的过程，直至所有特性测试发布完成.
   1. 因为test分支仍然同时存在多个迭代团队功能特性，比如Merger在选择合并F1到master分支操作时，必须使用cherry-pick，即：仅合并F1提交的版本号.

Level 3: 全量串行合并到master

远程仓库分支看起来：

1

master branch-f1 branch-f2 branch-f3

Level 3与Level 2和Level1 没有紧密的继承关系，但仍有如下关键的相似特征：

关键特征

• master仍然作为发布分支并受tmp控制.
• 设置Merger 角色：专门负责合并branch-*到master分支.
• 抛弃test分支

基本工作流程

Level 3 远程分支看起来如下：

1. branch-分支：每个特征开发小组在迭代伊始，从master复制一个开发分支即branch-分支进行开发.
   1. 开发和测试人员在同一个分支里开发和测试.
   2. 测试人员为每一个迭代创建相应的test环境，当然代码都是从相应的branch-*里拉出
2. 开发测试完成，迭代小组向Merger提交合并到master分支的申请，要求上线.
3. master分支：Merger同时收到多个合并请求，根据业务安排，Merger决定优先选择一个分支合并到master，然后测试发布，直接该特性上线完成，才能继续合并第2个合并请求，重复前面的过程，直至所有特性测试发布完成. 几个要点：
   1. 此merge和Level 2的合并同属合并，但是关键区别在于：这个合并是全量合并！举例说合并branch-f1的功能到master，既不会像cherry-pick那样把branch-f2的合并到master，也拜托了cherry-pick依次挑出相应的版本号进行合并，大大提高了合并效率和准确性。
   2. 发布完成后，对应的开发分支可以删除了。下次开发新的功能时，总是从master复制出一个新的开发分支

注：假设branch-f2分支创建的时候版本为f1，当branch-f2开发测试完成准备合并到master的时候发现f1已经在master了，必须反向合并：你应该总是在合并到master之前先反向合并master到branch-*分支，如果发现有更新，必须要进行回归测试！

最佳实践

1. 如果上线了一个功能，应总是给当前master的最新版本打上一个tag作为快照。尽管我们可能使用docker回滚，但是这个方式非常有助于历史回溯。
2. 向Merger提交merge申请，可使用 git 仓库的Merge Request功能，同时也实现了Code Review协作。
3. 使用git，没有hook限制提交的时候一定要输入JIRA号，tmp系统也不使用JIRA号，但是你提交变更，应该总是使用JIRA号便于历史回溯.

到Level 1、2、3在团队内实践熟练到一定阶段，我们可以考虑采用更严谨的git工作流程了.

B. 非上线类项目的git流程

非上线类项目是指通过非tmp渠道上线的项目（如npm包引用、app渠道发布），该类项目完全通过 gitbucket 系统进行管理，包括成员权限设定、分支任意设置等。因此，该类型的项目可以无障碍地选择使用文章开头提到的git flow、github fow或gitlab flow.

开发过程中，经常会有一些通用的部分希望抽取出来做成一个公共库来提供给别的工程来使用，而公共代码库的版本管理是个麻烦的事情。今天无意中发现了git的git submodule命令，之前的问题迎刃而解了。

添加 submodule

为当前工程添加submodule，命令如下：

1

git submodule add 仓库地址 路径

其中，仓库地址是指子模块仓库地址，路径指将子模块放置在当前工程下的路径。

注意：路径不能以 / 结尾（会造成修改不生效）、不能是现有工程已有的目录（不能順利 Clone）

命令执行完成，会在当前工程根路径下生成一个名为“.gitmodules”的文件，其中记录了子模块的信息。添加完成以后，再将子模块所在的文件夹添加到工程中即可。

删除submodule

submodule的删除稍微麻烦点：首先，要在“.gitmodules”文件中删除相应配置信息。然后，执行“git rm –cached ”命令将子模块所在的文件从git中删除。

更新submodule

当在其他地方使用git clone下来的工程中带有submodule时，初始的时候，submodule的内容并不会自动下载下来的，此时，只需执行如下命令：

1

git submodule update --init --recursive

即可将子模块内容下载下来后工程才不会缺少相应的文件。

在第一次使用git仓库之前，建议你总是全局设定好你的个人信息

git config –global user.name ‘’Howard”
git config –global user.email “'allen@banyuan.club“

I. 基础操作

1. 第一次拉仓库代码

git clone http://git.banyuan.club/starship.git

它实质做了几个工作：

• git fetch远程仓库到本地仓库
• 创建本地master分支，对应远程master分支
• checkout master分支到index和wd区
• 你在wd区开始开发工作！

2. 更新远程仓库上的代码

git pull

假如你当前工作在master本地分支，默认设定的上游仓库是orgin仓库的master分支，那么该操作执行的就是：将orgin/master分支的代码的差异从远程仓库下载下来，然后合并到本地仓库的master分支。相当于fetch和merge命令的集合：

git fetch origin master
git merge origin/master

使用后者分开命令是比较审慎的做法，可以在merge之前执行

git log -p master..origin/master
明确了解分支间的差异，再决定是否合并及如何合并.

3. 提交代码修改

如果你在本地wd区修改了如果代码并想提交到远程仓库，进入项目目录，执行：

git add .
git commit -m ‘some messges’
git push

如果有成员先于你提交了代码到远程仓库，在执行git push的时候会被阻止，此时请先执行 git pull（其实我们总是建议你在git push前执行git pull），下面是可能遇到的几种情况：

执行git pull，没有冲突立即合并，然后再执行 git push即可
执行git pull，有冲突，在wd区手工解决，然后重新执行 git add , git commit，再执行git push

II. 分支操作

1. 创建分支

假设你正工作在master本地分支，执行

git checkout -b dev

取远程同名分支origin/dev，并立即创建了一个名字为dev的本地分支，并切换WD到dev分支。接下来dev分支进行开发测试。直到完成后同步到远程仓库。

注：如果没有远程origin/dev分支，就基于当前操作的分支创建一个本地dev，没有对应的上游仓库分支.

git push origin dev

将把本地dev分支内容推到默认远程仓库的dev分支，如果远程仓库没有该分支，就创建一个。

此时另一个成员加入与你共同开发dev分支代码，他在自己的电脑上git clone代码仓库后，然后执行

git checkout -b dev origin/dev #假设已经执行过了默认克隆操作.

就基于远程仓库origin/dev，创建了本地分支dev，就可以开发了。

如果使用git branch 命令来创建分支，和git checkout方式的区别主要在于不会默认切换分支，另外git branch命令最好明确指定上游分支（如果需要的话），否则不会自动关联上游分支.

2. 分支合并

假设dev分支的代码已经开发完成，想合并到master分支，

a. 全量合并

git checkout master
git merge dev

这将把dev的所有改变都被合并到了master。如果你仅仅想合并指定修改，应使用cherry-pick

b. cherry-pick

例如：在分支dev下使用git log命令查出你要合并的修改commit id(以b732e9为例)，然后切换到master分支，执行：

git cherry-pick b732e9

3. 分支删除

• 删除本地分支

git branch -D dev01

• 删除远程分支

git push origin :remote-branch

• 删除远程分支本地缓存

git branch -r -d origin/dev01

III. 标签操作

发布一个版本后，最好为发布版本做个标签TAG

创建tag

git tag -a v0.1.0 -m ‘Intial Release v0.1.0’ # 也可以轻量级创建tag： git tag v0.1.0
git push origin –tags #提交所有tags
git push origin v0.1.0 #提交指定tag

查看tag

git tag -l #查看仓库里有多少个tag

也可以进入tag看下源代码

git checkout v0.1.0

删除tag

git tag -d 0.1.0 #删除本地tag
git push origin :refs/tags/0.1.0 #删除远程tag

附：日常操作必备命令

• 概览仓库情况: 多少分支、多少tag

git branch -a #查看远程仓库所有分支。
git tag -l #查看远程仓库所有标签 。

git ls-remote –tags origin
git ls-remote –heads origin
git ls-remote origin

• 查看上游仓库情况

  git remote -v

• 查看上游分支

  git branch -vv

• commit

  git commit
  git commit -a –amend #对最近一次commit的进行修改

• reset

  git reset／git checkout / git revert

一言难尽，但很重要。这个链接不错： https://segmentfault.com/a/1190000003102737

这里仅介绍最粗暴的一个：放弃工作目录所有修改！

git reset –hard HEAD

• DIFF

  git diff
  git diff #working copy和staging区域对比
  git diff –cached #等同–staged，stging区域和仓库对比
  git diff HEAD #working copy和staging和仓库一起对比
  git diff 6720722 b28b566 # 明确比较两个版本差异，一般选前者为更早的历史版本
  git diff master ^origin/master 比较本地master分支和远程master的差别

• 查看日志

  git log
  git log –name-status 每次修改的文件列表, 显示状态
  git log –name-only 每次修改的文件列表
  git log –stat 每次修改的文件列表, 及文件修改的统计

• whatchanged

  git whatchanged 每次修改的文件列表
  git whatchanged –stat 每次修改的文件列表, 及文件修改的统计

• git show 显示最后一次的文件改变的具体内容

• git rebase

• 查看当前WD的状态

git status

• 文件模式不反应为版本变更：git config core.fileMode false

• .gitignore文件

  .gitignore文件用来忽略不想上传或提交的文件或目录

• .gitkeep文件

  .gitkeep文件放在想提交的空目录下，作为占位符.

• 导出干净的某个分支代码:

  git archive –format zip –output “./my-project.zip” master -0

将master分支代码导出并zip 打包后放在当前目录下，my-project.zip就是目标文件，-0的意思是不压缩.

代码风格：C代码风格遵从 Google C Style 事半功倍。

工具：我用Sublime Text写C代码，其格式化插件，几乎只能使用 SublimeAStyleFormatter，不过已经足够了，而且足够的好。

安装Sublime下的SublimeAStyleFormatter插件

SublimeAStyleFormatter 主要关注在C、Java代码格式化。

Mac OS下打开Sublime Text，按CMD + SHIFT + P，弹出窗口输入install，下拉列表第一个显示的条目是：”Package Control: Install Package”，选中按回车键，输入 SublimeAStyleFormatter ，甚至只输入部分文字就会下拉列出该插件的名字，选中然后按回车键，稍等片刻，安装完毕。

1. 什么？按CMD + SHIFT + P，输入install的时候就卡住，你没有看到这个下拉条目？
这是你应该去 https://packagecontrol.io 首先安装 Sublime Text 的插件的管理工具。

2. 什么？按CMD + SHIFT + P完全没有反应？
Terrible，你不得不先学会科学上网！

SublimeAStyleFormatter的基本用法

写一段C代码

1
2
3
4
5
6
7
8

#include <stdio.h>

int main(void)
{
printf ("Hello World\n") ;
int sum =3+4;
return 0;
}}Ï

打开右键菜单 AStyleFormater->Format（快捷键：CMD + OPTION + F），点击确认后格式成：

1
2
3
4
5
6
7
8

#include <stdio.h>

int main(void)
{
    printf ("Hello World\n") ;
    int sum = 3 + 4;
    return 0;
}

的确好看了不少，不过还不足够，比如prinf函数和(之间有一个多余的空格，另外缩进是TAB，不是我想要的4个spaces。怎么办？

分别打开插件设置：Preferences->Package Settings->SublimeAStyleFormatter->Settings - Default 和 Settings - User，将Settings - Default里项修改的项复制到Settings - User里进行修改，如下：

1
2
3
4
5
6

{
    "options_default": {
        "indent": "spaces",
        "indent-spaces": 4,
    }
}

保存后再格式化一次，看看缩进的TAB是不是变成了4个spaces。

SublimeAStyleFormatter使用Google C Style

我的项目代码遵从了 Google C Style(Google的代码风格指南开源在 https://github.com/google/styleguide )，Oops，那么多代码格式设定看来都要在 SublimeAStyleFormatter 里设置。

参考 SublimeAStyleFormatter文档（开源在 https://github.com/timonwong/SublimeAStyleFormatter ），文档介绍极其简单，原来它是基于 Artistic Style，其实是要学会 Artistic Style 如何设置代码风格，然后将设置参数存成一个文本文件，如 .astylerc，然后被 SublimeAStyleFormatter 引用即可。

符合Google C Style的Artistic Style参数设置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

--style=google

--indent=spaces=4

--attach-namespaces
--attach-classes
--attach-inlines

--add-brackets

--align-pointer=name
--align-reference=name

--max-code-length=200
--break-after-logical

--pad-oper
--unpad-paren

--break-blocks
--pad-header

文件存储为.astylerc，放到家目录，插件的Settings - User再次修改为：

1
2
3
4
5
6
7
8
9

{
    "options_default": {
        "indent": "spaces",
        "indent-spaces": 4,
    },
    "options_c": {
        "additional_options_file": "$HOME/.astylerc"
    },    
}

注：$HOME就指代你的家目录

再按快捷键 CTRL + OPTION + F格式化代码，看看是不是变成下面这样：

1
2
3
4
5
6
7

#include <stdio.h>

int main(void) {
  printf("Hello World\n") ;
  int sum = 3 + 4;
  return 0;
}

DONE，完美！

在git clone时加上 –depth=1的含义是：

depth用于指定克隆深度，为1即表示只克隆最近一次commit.

这种方法克隆的项目只包含最近的一次commit的一个分支，体积很小，即可解决文章开头提到的项目过大导致Timeout的问题，但会产生另外一个问题，他只会把默认分支clone下来，其他远程分支并不在本地，所以这种情况下，需要用如下方法拉取其他分支：

1
2
3
4

$ git clone --depth 1 https://github.com/guoguolong/sharpcodes.git
$ git remote set-branches origin 'remote_branch_name'
$ git fetch --depth 1 origin remote_branch_name
$ git checkout remote_branch_name

Linter工具主要用来检查语言的代码风格和代码里的坏味道。这些工具通常可以独立或跟随构建工具一起使用，也可以集成到代码编辑器里使用。
Sublime Text3的 SublimeLinter插件功能强大，基于它开发的各种语言Lint插件功能卓越，本文主要介绍 ESLint、stylelint、htmlint 的插件使用。

前置知识

假设你已经安装了Sublime Text（包括SublimeLinter插件）、Node.js 8以上环境，熟悉node、npm以及现代Web前端开发工程组织（并已经有一个实验的前端项目工程），熟悉Sublime Text3的插件管理，否则阅读下文会比较吃力。

ESLint

ESLint主要用于检测ECMAScript/JavaScript的代码风格和语法合规性，类似JSLint或者JSHint，不过后面两者已经不再流行。
官网 https://eslint.org/ 关于如何独立使用ESLint，介绍得相当通俗易懂，我们这里着重介绍其Sublime Text插件的用法。

安装SublimeLinter-ESLint

在工程目录下安装ESLint先：

1

npm install eslint --save-dev

然后安装SublimeLinter-ESLint插件。

打开 Preferences->Package Settings->SublimeLinter->Settings，输入内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    "lint_mode": "save",
    "paths": {
        "osx": [
            "/usr/local/bin"
        ]
    },
    "linters": {
        "eslint": {
              "selector": "text.html.vue, source.js - meta.attribute-with-value"
        }
    }
}

• lint_mode:save：意为仅在js文件存储的时候，才进行lint检查，否则打开工程只要发现lint配置，就会整个工程检查所有Js文件的，那可耗时了。
• paths:osx:/user/local/bin 是指向node所在的目录。
• linters:eslint:selector：这里的说明使lint支持vue文件。

使遵从airbnb的JavaScript规范

安装Airbnb JavaScript规范非常时髦，安装其lint插件：

1

npm i eslint-config-airbnb-standard --save-dev

在实验工程目录下创建 .eslintrc （或者.eslintrcjs）文件，内容如下：

1
2
3
4
5
6

{
    "extends": ["airbnb-standard"]
    "rules": {
        "indent": ['error', 4]
    }
}

写一个JavaScript文件试试，存储时ESLint将遵从airbnb-standard检查，rules里可以定制项目自己的规则，比如上面的例子：大部分规则都遵从airbnb，但是缩进空格是四个（airbnb缩进的两个空格）。

stylelint

跟ESLint很类似， 官网 https://stylelint.io/ 的独立使用直接了当，我们重点仍然放在Sublime Text的插件使用。

安装 SublimeLinter-stylelint 插件

在实验工程目录下安装stylelint先：

1

npm install postcss stylelint --save-dev

然后安装SublimeLinter-stylelint插件。

配置项目使用stylelint-config-recommended css规范

在实验工程目录下安装 stylelint-config-recommended

1

npm install stylelint-config-recommended --save-dev

在项目根目录下创建文件 .stylelintrc，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12

{
    "extends": "stylelint-config-recommended"
    "rules": {
        "at-rule-no-unknown": [ true, {
          "ignoreAtRules": [
            "extends"
          ]
        }],
        "block-no-empty": null,
        "unit-whitelist": ["em", "rem", "s"]
    }
}

上面例子规则是：默认使用 stylelint-config-recommended 规则，然后在此基础上定制项目自有规则，如：尺寸单元只能使用em、rem、s等，如果设置width: 20px；这个px就是不合规的。

在Sublime Text里写一个css文件，存储一下试试，看上面的规则是否生效。

注：如果存储文件时，Sublime Text状态条显示err，总是按照ctrl + `打开控制台看详细错误信息。

htmllint

未完待续…

首先要安装 package control

A. Markdown Preview

B. Web前端开发用插件

SublimeLinter系列

https://github.com/standard
https://codeburst.io/eslint-with-airbnb-standard-js-sublime-text-965a1db58793

Vue Syntax Highlight

https://blog.csdn.net/qq_20011607/article/details/81370236

C. Side​Bar​Enhancements

边栏文件或目录可以直接打开浏览器、进入Finder、在新窗口打开

D. SublimeAStyleFormatter

C和Java的格式化插件，连接Artistic Style，非常方便. 参考 https://guoguolong.tech/2019/05/17/c/c-coding-style/

E. CodeFormatter

F. build: gcc java php python.