跳到主要内容

8 篇博文 含有标签「开发」

查看所有标签

· 阅读需 12 分钟

Commit 规范​

本文主要介绍使用 git commit 提交代码时 message 书写规范及校验约束工具 commitlint，推荐遵循 message 规范。

git commit 提交规范​

1.message 提交格式​

在执行 git add . 后，执行 git commit 时，代码有变动，并需要特殊说明更改内容时，message 信息遵循下方定义的格式。（如没有特殊更改及说明可以使用：git commit -m <message> 提交代码）。

示例

git commit

feat(global): 新增支持表格金额千分位显示

新增以下内容：
- 金额的小数位默认保留两位小数
- 金额的小数位没有的话自动补2位0
- 如果需要保留的不是2位的话自行改一下位数

Closes #122

注：issue#122：客户反馈希望表格中的金额用千分位展示。

message 格式​
<type>(<scope>): <subject>
<!-- 空行 -->
<body>
<!-- 空行 -->
<footer>
字段必须说明
*type是提交类别
scope否用于说明 commit 影响的范围，建议填写影响的功能模块
*subject是commit 目的的简短描述，不超过 50 个字符
body否(建议填写)描述当前修改的行为详细信息或修改的目的
footer否一般用于描述 BREAKING CHANGE 或修复的 bug 的链接，在项目开发中一般不需要填写，组件研发的工程需要填写
*type 提交类别​

必填，type 在 commit 的 message 中是必须存在的。type 可以有以下取值。

值说明
feat新功能、新特性
fix修复 bug
docs文档修改
perf更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
style仅仅修改了空格、格式缩进、逗号等代码格式，不改变代码逻辑，不影响代码运行的变动，注意不是样式修改
refactor代码重构（重构，在不影响代码内部行为、功能下的代码修改）
test测试用例新增、修改
revert回滚到上一个版本
build影响项目构建或依赖项修改
ci持续集成相关文件修改
workflow工作流相关文件修改
chore其他修改（不在上述类型中的修改）
scope 影响范围​

非必填（建议填写），scope 用于说明 commit 影响的范围，建议填写影响的功能模块。如果修改影响不止一个 scope，可以使用 * 代替。

*subject 简短描述​

必填，commit 目的的简短描述，不超过 50 个字符。

• 以动词开头

• 第一个字母小写

• 结尾不加句号

body 详细信息​

非必填（建议填写），可描述当前修改的行为详细信息或修改的目的。

非必填，一般用于描述 BREAKING CHANGE，在项目开发中一般不需要填写，组件研发的工程需要填写。Footer 部分只用于两种情况

（1）不兼容变动​

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      attrData: 'attribute',
    }

    After:

    scope: {
      attrData: 'citcAttribute',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code usin
（2）关闭 Issue​

如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue 。如果是关闭 bug，可以放上对应 bug 链接。

Closes #235
Closes #123, #245, #992

2 示例​

fix​

如果修复的这个 bug 只影响当前修改的文件，可不加范围。如果影响的范围比较大，要加上范围描述。

例如这次 bug 修复影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称。

// 示例 1

fix(global): 修复 checkbox 不能复选的问题

// 示例 2 下面圆括号里的 order 为订单模块的名称。

fix(order): 修复页面顶部提示语字体过小的 bug，将订单模块下所有页面顶部提示语的默认字体大小修改为 14px

// 示例 3

fix: value.length -> values.length

// 示例 4 在实际开发中一般会使用项目管理工具比如禅道，这个时候修复 bug，需要带上 bugID。

fix: bug5788 【订单管理订单台账】切换默认条数后合计数显示与切换前的格式展示不一致

feat​

// 示例 1 不推荐，没有提交类型，功能描述不是很清晰。内容较多时可以用一句话概括，具体内容写在 body 中。

修改新增 数据统计 tab 切换

//示例 2

feat: 新增分公司计划收入模块

chore​

chore 的中文翻译为日常事务、例行工作，顾名思义，即不在其他 commit 类型中的修改，都可以用 chore 表示。

chore: 将表格中的查看详情改为详情

Git Commit 强制规范工具（commitlint+husky）​

配置步骤汇总​

  • 安装 commitlint 和 husky
npm install --save-dev @commitlint/config-conventional @commitlint/cli husky@4.3.8
  • 根目录创建 commitlint.config.js
module.exports = { extends: ['@commitlint/config-conventional'] };
  • package.json 添加 hooks 实现 commit 时检查
{
  "devDependencies": {
  ...
  },
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
 }
 ...
}

1. commitlint​

commitlint 是当前使用最为广泛的 git commit 校验约束工具之一，在多人协作的背景下，推荐使用 commitlint + husky 规范 git commit -m "" 中的描述信息。commitlint 主要用途是在我们运行 git commmit -m 'xxx' 时，用来检查 xxx 是否满足固定格式。

安装及生成配置文件​

commitlint: 安装及生成配置文件

// 安装
npm install -g @commitlint/cli @commitlint/config-conventional
// 生成配置文件
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
或者
yarn add  @commitlint/config-conventional @commitlint/cli -D
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

config-conventional 是社区整理的常用的 Commit 规范，见如下

https://www.npmjs.com/package/@commitlint/config-conventional

默认采用 config-conventional：

module.exports = {extends: ['@commitlint/config-conventional']}

可自定义配置：

配置规则见 https://commitlint.js.org/#/reference-configuration

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [2, 'always', [
            "feat", "upd", "del", "fix", "refactor", "test", "perf", "docs", "style", "revert"
        ]],
        'subject-full-stop': [0, 'never'],
        'subject-case': [0, 'never']
    }
}

2. husky​

Husky can prevent bad git commit, git push and more 🐶 woof!

husky 是一个增强的 git hook 工具，可以在 git hook 的各个阶段执行我们在 package.json 中配置好的 npm script。

借助 husky 在每次 commit 时执行 commitlint 来检查我们输入的 message。

2.1 安装​

注意：指定-g 也不对所有 Project 生效！每个 Project 都需要重新安装 husky。这里需要注意一点是安装最新husky版本会有各种各样问题, 建议大家安装 4.3.8版本，可以确保没有问题。

npm install husky@4.3.8 -D -g
或者
yarn add husky@4.3.8 -D
2.2 配置​

在 package.json 中配置 husky，commit-msg 指定为 commitlint （将在 git hook 的 commit-msg 阶段调用 commitlint ）。

"devDependencies": {
...
},
"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
 }

安装配置完成后，当我们在当前项目中执行 git commit -m '测试提交' 时将触发 commit-msg 事件钩子并通知 husky，从而执行 commitlint -E HUSKY_GIT_PARAMS 命令，它将读取 commitlint.config.js 配置规则并对我们刚刚提交的测试提交这串文字进行校验，若校验通过，则完成 commit 提交。若校验不通过，则在终端输出错误，commit 终止。

示例

git commit -m "xxx"
husky > commit-msg (node v14.18.3)
⧗   input: xxx
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky > commit-msg hook failed (add --no-verify to bypass)
git commit -m "feat:  测试提交"
husky > commit-msg (node v14.18.3)
[master 3f60f34] feat: 测试提交
2 files changed, 8 insertions(+), 1 deletion(-)

使用 Commitizen 实现规范提交​

上面介绍了规范提交的格式和校验约束工具，如果在 git commit 的时候严格按照上面的规范来写，需要记住不同的类型到底是用来定义什么的，subject 怎么写，body 怎么写，footer 要不要写。心智是有负担的。下面推荐一个工具在提交的时候来提示必填字段。

Commitizen​

Zen-like commit messages for internet citizens.

Commitizen 是一个帮助撰写规范 commit messages 的提示工具。

1.安装和初始化​
# 第一步在工作目录安装 cz-relax
npm install cz-relax --save-dev
# 第二步初始化中文配置，如果报错提示需要使用force，请在最后添加 --force
npx cz-relax init --language zh
2.运行 git cz 效果​
git add .
git cz

cz-cli@4.2.5, cz-git@1.3.10

? 选择你要提交的类型 : Use arrow keys or type to search
❯ feat:     新增功能 | A new feature
  fix:      修复缺陷 | A bug fix
  docs:     文档更新 | Documentation only changes
  style:    代码格式 | Changes that do not affect the meaning of the code
  refactor: 代码重构 | A code change that neither fixes a bug nor adds a feature
  perf:     性能提升 | A code change that improves performance
  test:     测试相关 | Adding missing tests or correcting existing tests
(Move up and down to reveal more choices)

? 选择你要提交的类型 : feat:     新增功能 | A new feature
? 选择一个提交范围（可选）: empty
? 填写简短精炼的变更描述 :
 [Infinity more chars allowed]
 新增公司收入台账模块
? 填写更加详细的变更描述（可选）。使用 "|" 换行 :

? 列举关联issue (可选) 例如: #31, #I3244 :

###--------------------------------------------------------###
feat: 新增公司收入台账模块
###--------------------------------------------------------###

? 是否提交或修改commit ? (Yneh)
......

—END—

· 阅读需 5 分钟

现有分支：


dev-1.2.1
main
dev-1.2.2
pretest-1.2.2
develop
test

目前情况：dev-1.2.1已上线，已合并到main分支。

（一） 从dev-1.2.1分支上创建dev-1.2.2分支作为1.2.2迭代需求版本的基础分支。

（二）从dev-1.2.2分支上传创建pretest-1.2.2分支作为多个需求开发的合并分支。

新增的多个需求，每个需求都以dev-1.2.2分支为基础创建，开发完成后合并到pretest-1.2.2汇总， pretest-1.2.2为当前开发中最新的汇总分支，随时可以把该分支合并到develop分支部署开发环境联调接口，也可以合并到test分支部署测试环境进行测试。

（三）pretest-1.2.2分支合并到test分支测试，测试完成后，pretest-1.2.2分支合并到dev-1.2.2分支，由dev-1.2.2分支合并到main分支部署正式环境。

（四）pretest-1.2.2分支合并到test分支测试，测试出现的bug，从pretest-1.2.2创建bug分支修改bug，修复bug后合并到pretest-1.2.2分支，pretest-1.2.2分支合并到test分支测试进行复测。bug复测完没问题后毕重复（三）的流程。

遇到问题及解决方案：

遇到问题：

如果在开发过程中，某几个需求需要提前上线。

解决方案：

在dev-1.2.2上创建instancy-1.2.2分支，这几个需求在各自分支上开发完成后，合并到instancy-1.2.2分支，由instancy-1.2.2分支合并到develop分支部署开发环境联调接口，由instancy-1.2.2分支合并到test分支部署测试环境进行测试，测试阶段完成后由instancy-1.2.2合并到dev-1.2.2，dev-1.2.2合并到main分支，发布正式环境。剩余几个分支分别从dev-1.2.2分支拉取最新代码。继续剩余分支的开发。后续仍然走各自分支合并到pretest-1.2.2分支，pretest-1.2.2分支合并到develop，pretest-1.2.2分支合并到test分支，pretest-1.2.2合并到dev-1.2.2，dev-1.2.2合并到main部署正式环境的流程。

在上述过程中各自的分支仍是以原始分支dev-1.2.2为基础，并没有从pretest-1.2.2分支主动拉取其他分支提交的代码，如果两个分支相互关联，可以两个分支之间相互合并。然后合并到pretest-1.2.2分支。

这样做法优点是有一个最新的公共分支来合到develop和test分支，冲突会在开发过程中进行解决，而不是各个分支在上线时才合并如果发现有冲突，上线前还要解决冲突。

在实际开发中一般可以这样更简单的操作。

实际用到的分支：


main
dev-1.2.2
develop
test
feat/a
feat/b
feat/c

其中feat/a，feat/b，feat/c分别为要开发的新需求，仍是遇到以上问题，a，b两个分支需要提前上线，此时需要做的是开发完成的a，b分支分别合并到develop分支部署开发环境联调接口，联调结束后，a，b分别合并到test分支部署测试环境进行测试。测试出的bug在各自的a，b分支修复后分别合并到test分支测试。复测完毕，feat/a，feat/b分别合并到dev-1.2.2，dev-1.2.2合并到main部署正式环境的流程。

如果a，b分支的业务有交叉，在线上合并develop时会出现冲突，此时关闭合并请求，在本地拉取最新的develop代码。在develop创建一个新分支develop-conflict，把a，b合并到develop-conflict，在develop-conflict分支上解决冲突，解决冲突后把develop-conflict合并到develop，走正常流程。虽然test分支代码和develop是一致的，但是环境配置不一样不能讲develop下创建的分支不能直接合并到test，所以在test分支下创建test-conflict重复以上操作。后续的联调和测试的bug在a，b各自的分支修改。后续在合并到develop和test上时就不会再有冲突了。develop-conflict、test-conflict可以删除了。

—END—

· 阅读需 2 分钟

管理node多版本
在实际项目开发中，不同的项目我们往往需要用到不同版本的node做支持，并且需要根据项目需要切换，以下就是常用的命令行。
Mac下使用n模块去安装多个指定版本的Node.js，并使用命令随时切换。
node中的n模块是，node专门用来管理node版本的模块，可以进行node版本的切换，下载，安装。
官网文档：n - npm
1、安装n
npm install -g n
2、查看n 模块的版本
n --version
3、展示当前安装的所有版本
n list
4、安装指定版本
n 14.17.4
5、安装最新版本
n latest
6、安装稳定版本
n stable
7、删除版本
n rm 14.17.4
8、查看帮助
n help
9、切换当前node版本
输入sudo n，会弹出如下所示，

xiayi@xiayi-MacBookPro inkken.github.io % sudo n

    node/14.16.1
    node/14.21.3
    node/15.14.0
    node/16.15.1
    node/16.20.0
  ο node/18.18.0

Use up/down arrow keys to select a version, return key to install, d to delete, q to quit


上下键选中要切换的node版本按确认即可

切换当前node版本
查看切换后的Node.js版本
node -v
10、注意问题
问题1：使用n切换了node版本，提示切换成功，但是使用node -v查看node版本发现还是旧的版本，检查是否使用了brew管理下载过node
解决：先停止brew管理的node：brew unlink node版本
问题2：使用n相关命令，如果报错权限不足，需要加上sudo
比如：sudo n stable


—END—

· 阅读需 2 分钟

1.nrm
nrm(npm registry manager )是npm的镜像源管理工具，有时候国外资源太慢，使用这个就可以快速地在 npm 源间切换

2.1安装nrm
在命令行执行命令，npm install -g nrm，全局安装nrm。
2.2查看版本号
nrm -V

3.1查看当前源
nrm current

3.2使用
执行命令nrm ls查看可选的源。
nrm ls
                                                                                                                                   
npm ---- https://registry.npmjs.org/
cnpm --- http://r.cnpmjs.org/
taobao - http://registry.npm.taobao.org/
eu ----- http://registry.npmjs.eu/
au ----- http://registry.npmjs.org.au/
sl ----- http://npm.strongloop.com/
nj ----- https://registry.nodejitsu.com/
其中，带*的是当前使用的源，上面的输出表明当前源是官方源。

4.切换
如果要切换到taobao源，执行命令nrm use taobao。

5.增加
你可以增加定制的源，特别适用于添加企业内部的私有源，执行命令 nrm add ，其中reigstry为源名，url为源的路径。
nrm add registry  http://registry.npm.frp.trmap.cn/

6.删除
执行命令nrm del 删除对应的源。

7.测试速度
你还可以通过 nrm test 测试相应源的响应时间。
nrm test npm



—END—

· 阅读需 2 分钟

cnpm的使用：
因为谷歌安装插件是从国外服务器下载，受网络影响大，可能出现异常，如果谷歌的服务器在中国就好了，所以我们乐于分享的淘宝团队干了这事来自官网：“这是一个完整npmjs.org镜像，你可以用此代替官方版本（只读），同步频率目前为10分钟一次以保证尽量与官方服务同步“。

安装命令：
npm install cnpm -g --registry=https://registry.npmmirror.com
cnpm跟npm用法完全一致，只是在执行命令时将npm改为cnpm。

常用命令：
cnpm -v // 查看版本号
cnpm install (cnpm i) // 安装项目相关依赖（vue/react）
cnpm ci // 和cnpm install命令一样，是用来安装依赖的命令，但他可以比常规的 cnpm 安装快得多，也比常规安装更严格，他可以cnpm依赖安装的一致和稳定 (锁版本)
cnpm uninstall express // 卸载 Node.js 模块
cnpm update express // 更新模块
cnpm search express // 搜索模块
cnpm run dev // 启动开发环境 （vue）
cnpm run build // 打包生产环境的代码，打包成功会生成dist文件夹（里面有index.html文件和static文件夹）；项目上线时，只需要将 dist 文件夹放到服务器就行了。（vue）

cnpm start // 启动开发环境 （react）
cnpm run build // 代码会被编译到build目录。将整个应用打包发布，自动试用webpack进行压缩与优化。



—END—

· 阅读需 2 分钟

常用命令：

npm -v // 查看版本号

npm install (npm i) // 安装项目相关依赖（vue/react）

npm ci // 和npm install命令一样，是用来安装依赖的命令，但他可以比常规的 npm 安装快得多，也比常规安装更严格，他可以npm依赖安装的一致和稳定 (锁版本)

npm uninstall express // 卸载 Node.js 模块

npm update express // 更新模块

npm search express // 搜索模块

npm run dev // 启动开发环境 （vue）

npm run build // 打包生产环境的代码，打包成功会生成dist文件夹（里面有index.html文件和static文件夹）；项目上线时，只需要将 dist 文件夹放到服务器就行了。（vue）

npm start // 启动开发环境 （react）

npm run build // 代码会被编译到build目录。将整个应用打包发布，自动试用webpack进行压缩与优化。

—END—

· 阅读需 1 分钟

全局安装：
npm install --global yarn

安装后检查版本
yarn -v

初始化一个新项目
yarn init

添加依赖包
yarn add [package] 
yarn add [package]@[version] 
yarn add [package]@[tag]

将依赖项添加到不同依赖项类别中
分别添加到 devDependencies、peerDependencies 和 optionalDependencies 类别中：
yarn add [package] --dev 
yarn add [package] --peer 
yarn add [package] --optional

升级依赖包
yarn upgrade [package] yarn upgrade [package]@[version] yarn upgrade [package]@[tag]

移除依赖包
yarn remove [package]

安装项目的全部依赖
yarn
或者
yarn install

run react项目
yarn start

build react项目
yarn run build


—END—

· 阅读需 9 分钟

cd 到指定文件夹
git clone 链接
git checkout -b login  创建分支

git branch -D login    删除本地上的login分支(-D表示强制删除)

1.  首先将某个远程主机的更新，全部取回本地：git fetch
2.  再次查看远程分支：git branch -a 发现远程的分支已经可以看见
3.  然后拉取远程分支到本地：git checkout -b 远程分支名 origin/远程分支
4.  git push -u origin login    第一次将本地分支推送到远程服务器（远程服务器未创建该分支）并且命名为login

git commit -m "chore: 确认计划和公司收入信息模块删除多余注释"

chore

cherry-pick类似于一个定制化的merge，它可以把其它分支上的commit一个个摘下来，合并到当前分支。

git cherry-pick commitID
git cherry-pick 8e849fcb69d28ec1b36d9860a960bac0ef29ae7b

git cherry-pick commit1..commit100
左开右闭的操作，也就是说，commit1不会被合并到master分支，而commit100则会

git revert a19438f00c78a503b81d8be53fc5c18219fb3671 -m 1
Git revert 来取消历史中的某一次 merge


gh auth login
sudo GIT_USER=UniverseExcellence yarn deploy
https://github.com/GitKenCom/inkken.git


查询全局的配置  
git config --list

配置用户名和邮箱：
git config --global  user.name "用户名"
git config --global user.email "邮箱"

基本操作：
git status    检查未提交的文件
git add .      添加所有更改文件到暂存区
git status 
git commit -m "完成了xx功能"     把暂存区的代码提交到了本地仓库中
git branch    查看当前所处分支  当前处于login分支
git push  将当前主分支推送到远程仓库
git pull  拉取远程最新代码

创建本地分支并提交：
git checkout master  切换到主分支
git pull  拉取远程最新代码
git checkout -b login  创建分支
git branch    查看当前所处login分支
git push -u origin login    第一次将本地分支推送到远程服务器（远程服务器未创建该分支）并且命名为login

删除本地分支和远程分支：
删除本地分支：
git checkout master  切换到主分支
git branch      查看本地的分支
git branch -D login    删除本地上的login分支(-D表示强制删除)
git branch  查看本地分支
删除远程分支：
git branch -r  查看远程的分支
git push origin -d login  删除远程上的login分支(-D表示强制删除)
git branch -r  查看远程的分支

合并分支到主分支：
git checkout master  切换到主分支
git branch      当前处于master分支
git merge login   合并login分支到主分支
git push  将当前主分支推送到远程仓库

拉取远程分支到本地（远程仓库有新分支，本地没有）：
1.首先将某个远程主机的更新，全部取回本地：git fetch
2.再次查看远程分支：git branch -a 发现远程的分支已经可以看见
3.然后拉取远程分支到本地：git checkout -b 远程分支名 origin/远程分支

本地删除了分支，远程也想删除：
1.使用git branch -d 分支名来删除本地分支。
2.使用git push origin -d 分支名直接来删除远程分支。在次使用git branch -a,发现分支已经不存在了。
或者
1.使用git branch -d 分支名来删除本地分支。
2.最简单的解决办法就是直接到gitlab/github进行删除.

远程删除了分支，本地也想删除：
1.git branch -a查看远程分支，红色的是本地远程远程分支记录。
2.执行下面命令查看远程仓库分支和本地仓库的远程分支记录的对应关系：git remote show origin  
3.会看到：refs/remotes/origin/远程仓库已经删除的分支名              stale (use 'git remote prune' to remove)
  其中：Local refs configured for 'git push':  命令下面的分支是本地仓库的远程分支记录中仍存在的分支，但远程仓库已经不存在
4.输入git remote prune origin来删除远程仓库已经删除过的分支
5.验证 git branch -a
 此时可以看到本地远程分支记录已经和远程仓库保持一致了

将主分支代码拉取到自己分支上：
1.切换到主分支（master）
git checkout master
2.拉取远程仓库代码
git pull
3.切换回自己的分支
git checkout 分支名称
4.把主分支的代码合并到自己的分支上
git merge master
5.把代码上传到远程仓库自己分支上
git push

如果当前功能直接在主分支上开发了  可以直接创建一个分支user 
git checkout -b user  
git branch
git add .
git status
git commit -m "完成了xx功能"
git status
git push -u origin user
git branch  查看当前分支为user
git checkout master
git branch
git merge user
git push   推送到主分支


拉取命令
git clone + 项目地址（项目地址：在GitLab中打开项目后直接复制"Clone with SSH"）
git pull  由于已经关联了地址，之后更新可以用git pull直接更新到最新
提交命令
提交新项目（未初始化Git仓库）
git init 使用cd命令进入到工程目录下，即进入工作区，把仓库变为可管理的git仓库，得到一个.git文件夹
git add . 将仓库下的所有内容添加到暂存区，如果只是个别内容就把“.”改为文件名
git commit -m  "注释内容"将暂存区的内容提交到本地版本库。（参数-m很重要）
git remote add origin + 远程仓库的地址（在GitLab上复制项目地址）把本地仓库和远程仓库关联
如果出现 fatal:remote origin already exists
那么输入命令：git remote rm origin
然后再重复：git remote add origin + 远程仓库的地址
git push -u origin master把当前分支master推送到远程仓库。参数-u的意思是，只要本地做了提交，以后就可以直接用git push代替原命令进行推送



配置github token

ghp_sxxxxxxxx*********************************

git clone  https://<your_token>@github.com/<USERNAME>/<REPO>.git
git clone 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@https://github.com/GitKenCom/inkken.git

git remote set-url origin https://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@github.com/GitKenCom/inkken.git

Docusaurus Plushie


登录：
gh auth login

xiayi@xiayi-MacBookPro ~ % gh auth login
? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Paste an authentication token
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
? Paste your authentication token: ****************************************
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as UniverseExcellence
xiayi@xiayi-MacBookPro ~ % 


部署
sudo GIT_USER=UniverseExcellence yarn deploy


—END—