更新图片加速地址

README-en.md

@@ -21,31 +21,29 @@ English | [简体中文](README.md)
 <img src="https://camo.githubusercontent.com/82291b0fe831bfc6781e07fc5090cbd0a8b912bb8b8d4fec0696c881834f81ac/68747470733a2f2f70726f626f742e6d656469612f394575424971676170492e676966" width="800"  height="3">
 </div><br>
 
-
 **Check the online version：** [https://howtosos.eryajf.net](https://howtosos.eryajf.net/en)
 
 > 🙋 It is highly recommended to read it through the online version，The content is more aesthetically pleasing，The knowledge tandem is also more elegant！！！
 >
 > 🍺 Special thanks to [ArslanYM](https://github.com/ArslanYM) for its English translation of this project
 
-
 `Home：`
 
-![image_20230218_143536](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230218_143536.png)
+![image_20230218_143536](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230218_143536.png)
 
 `Content：`
 
-![image_20230218_143657](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230218_143657.png)
+![image_20230218_143657](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230218_143657.png)
 
 `v2`
 
-![image_20230908_155559](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230908_155559.png)
+![image_20230908_155559](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230908_155559.png)
 
 Mixed up on the Internet，It's inevitable that you'll all interact with GitHub to a greater or lesser extent，Most of the time the experience gained in the company with git is for GitLab，It's also easy to take for granted past experience into GitHub，And in fact there are some differences，Several projects have recently been open-sourced，Some also involve working with external developers，When I was really faced with dealing with a PR，The heart was flustered，I didn't know where to start for a while. Here is a compilation and record of the practice in this regard.
 
 Welcome to add, welcome to correct!
 
-**Course*
+\*_Course_
 
 - [On July 24, 2022, it was featured on GitHub Daily](https://github.com/bonfy/github-trending/blob/master/2022/2022-07-24.md#javascript)
-  ![GitHub-Trending](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220724_173425.png)
+  ![GitHub-Trending](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220724_173425.png)

README.md

@@ -1,6 +1,5 @@
 [English](./README-en.md) | 简体中文
 
-
 <h1 align="center">HowToStartOpenSource</h1>
 
 <div align="center">
@@ -18,12 +17,10 @@
 
 <p align="center"> ⚗️ GitHub开源项目维护协作指南</p>
 
-
 <div align="center">
 <img src="https://camo.githubusercontent.com/82291b0fe831bfc6781e07fc5090cbd0a8b912bb8b8d4fec0696c881834f81ac/68747470733a2f2f70726f626f742e6d656469612f394575424971676170492e676966" width="800"  height="3">
 </div><br>
 
-
 **查看在线版：** [https://howtosos.eryajf.net](https://howtosos.eryajf.net)
 
 > 🙋 强烈建议通过在线版进行阅读，内容更加美观，知识串联也更加优雅！！！
@@ -32,21 +29,21 @@
 
 `首页：`
 
-![image_20230218_143536](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230218_143536.png)
+![image_20230218_143536](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230218_143536.png)
 
 `内容：`
 
-![image_20230218_143657](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230218_143657.png)
+![image_20230218_143657](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230218_143657.png)
 
 `v2`
 
-![image_20230908_155559](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20230908_155559.png)
+![image_20230908_155559](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20230908_155559.png)
 
 混迹于互联网，或多或少难免都会与 GitHub 有交互，大多数时候在公司中积累的 git 使用经验都是面向 GitLab 的，也很容易想当然地将过往的经验套到 GitHub 中，而事实上还是有一些差别的，最近开源了几个项目，有一些还涉及到要与外部开发者协同工作，当我真正面对要处理一个 PR 的时候，内心是慌乱的，一时间不知道该从何处下手，这里就整理记录一下这方面的实践。
 
 欢迎补充，欢迎指正！
 
 **历程**
 
-- [2022年7月24日，登上了GitHub日推。](https://github.com/bonfy/github-trending/blob/master/2022/2022-07-24.md#javascript)
-  ![GitHub-Trending](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220724_173425.png)
+- [2022 年 7 月 24 日，登上了 GitHub 日推。](https://github.com/bonfy/github-trending/blob/master/2022/2022-07-24.md#javascript)
+  ![GitHub-Trending](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220724_173425.png)

docs/HowToStartOpenSource/01-basic-content/01-basic-configuration.md

@@ -5,15 +5,14 @@ title: 基础配置
 date: 2022-07-18 17:10:13
 ---
 
-
 配置项目的说明，对应官网，以及标签，这些信息将辅助别人快速认识这个项目，并深入了解学习这个项目。
 
-![image_20220718_171234](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171234.png)
+![image_20220718_171234](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171234.png)
 
 如果想要精简二级 tab，则可以在项目的设置中的 `Features` 配置项进行取舍：
 
-![image_20220718_171250](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171250.png)
+![image_20220718_171250](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171250.png)
 
 在 settings 的 Pages 配置页面中，我们可以选择将该项目配置为静态站点：
 
-![image_20220718_171321](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171321.png)
+![image_20220718_171321](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171321.png)

docs/HowToStartOpenSource/01-basic-content/02-personal-maintenance-process.md

@@ -3,7 +3,6 @@ title: 个人维护流程
 date: 2022-07-18 17:13:51
 ---
 
-
 如果你是项目的负责人，在后期项目维护中，同样不建议直接使用本地 push 的方式进行，尽管我们有这个项目的全部权限，也可能会因为某次失手，导致将不符合预期的内容提交。这里建议走 pr 的方式进行维护，便于在 merge 的时候二次核验一下代码差异。
 
 接下来是一个维护的常规流程。
@@ -39,28 +38,28 @@ $ git push --set-upstream origin test
 
 然后我们来到 GitHub 项目页，可以看到 test 分支：
 
-![image_20220718_171427](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171427.png)
+![image_20220718_171427](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171427.png)
 
 可以看到页面已经提示 test 分支，并有一个提交 PR 的按钮，我们来创建这个 PR：
 
-![image_20220718_171438](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171438.png)
+![image_20220718_171438](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171438.png)
 
 通常点击 1 的 tab 进行交互，2 号可以选择当前项目的不同分支，我们这里选择刚刚的 test 分支。
 
 编号 3 表示可以选择其他远程仓库进行合并，通常是与一个 fork 后的仓库进行交互。编号 4 可以清晰看到当前这次合并与源分支的差异。
 
 点击创建 PR：
 
-![image_20220718_171449](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171449.png)
+![image_20220718_171449](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171449.png)
 
 通常我们应该在这一步写明一个标题，以及当次将要合并的内容纲要。
 
-![image_20220718_171458](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171458.png)
+![image_20220718_171458](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171458.png)
 
 此时视角切回到项目主维护者，可以通过编号 1 和编号 2 来核对提交的次数以及差异内容，这里因为是从本地推送，所以通常直接二次 check 即可，如果是处理别人的 PR，则应该将代码拉到本地进行一些功能测验。
 
 编号 3 表示将这次 PR 进行合并，所有的提交都会合并到 main 分支中，如果该次 PR 有多次 commit，主分支也会呈现多次 commit 的历史。
 
 编号 4 表示将多次 commit 压缩成 1 次，然后再合并到主分支，一般与协助者协同维护项目的时候，应该选择第二项。
 
-当我们确认之后，就完成了一次自己面对项目的迭代推进流程。
+当我们确认之后，就完成了一次自己面对项目的迭代推进流程。

docs/HowToStartOpenSource/01-basic-content/03-collaborative-development-process.md

@@ -14,7 +14,7 @@ date: 2022-07-18 17:15:31
 
 通常作为协同者，我们会先把项目 fork 到自己的仓库中：
 
-![image_20220718_171810](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171810.png)
+![image_20220718_171810](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171810.png)
 
 现在我处于 lql95 的视角，已经将刚刚 eryajf 名下的项目 fork 到了自己的仓库，此时可以将该项目拉到自己本地进行编码：
 
@@ -48,7 +48,7 @@ $ git push --set-upstream origin main
 
 此时 lql95 的远程仓库实际可以相当于刚刚自己维护的 test 分支，我们需要到 eryajf 的仓库中请求对方将自己的修改 pull 过去：
 
-![image_20220718_171822](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171822.png)
+![image_20220718_171822](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171822.png)
 
 方向选择正确之后，我们就可以创建这个 PR 了，同样下一步需要填写标题与备注，这里的标题备注尽量将当次 PR 的内容以列表的形式表明，以便于维护者能够直观地审核自己的这次 PR。
 
@@ -76,11 +76,11 @@ $ git push
 
 这次提交同样会呈现在刚刚创建的那次 PR 之上，现在我们站在 eryajf 的视角来看看这个 PR：
 
-![image_20220718_171832](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220718_171832.png)
+![image_20220718_171832](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220718_171832.png)
 
 可以看到 lql95 的 2 次 commit，也可以在差异页面查看此次 PR 的详情，因为这次交互内容不多，所以这里看起来比较简单，在真实项目协作过程中，一次 PR 变化的文件可能有几十个，这个时候再通过页面来看就很不直观了，可以通过如下方式在本地处理。
 
-owner 在自己本地项目目录下，打开 `.git/config` 文件，在 `[remote "origin"]` 后添加一行：
+owner 在自己本地项目目录下，打开  `.git/config`  文件，在  `[remote "origin"]`  后添加一行：
 
 ```
 fetch = +refs/pull/*/head:refs/pull/origin/*
@@ -109,4 +109,4 @@ from the remote, but no such ref was fetched.
 $ git checkout -b eryajf_test refs/pull/origin/2
 ```
 
-此时项目在本地就将此次 PR 后的最新代码，以 eryajf_test 分支存在，我们可以对协作者提交的代码功能进行一些核验等工作，当我们测验感觉没有问题之后，就可以将代码进行合并了。合并的操作与上边一样，不再赘述。
+此时项目在本地就将此次 PR 后的最新代码，以 eryajf_test 分支存在，我们可以对协作者提交的代码功能进行一些核验等工作，当我们测验感觉没有问题之后，就可以将代码进行合并了。合并的操作与上边一样，不再赘述。

docs/HowToStartOpenSource/01-basic-content/04-PR-and-issue.md

@@ -3,13 +3,13 @@ title: PR与issue的联动维护
 date: 2022-07-19 14:49:19
 ---
 
-当我们需要解决项目中的一个bug时，通常一个新的`PR`会伴随一个`issue`，本文将介绍仅需通过创建`PR`时一个操作，关联上`issue`，然后当`PR`被同意之后，对应关联的`issue`也将随之关闭。
+当我们需要解决项目中的一个 bug 时，通常一个新的`PR`会伴随一个`issue`，本文将介绍仅需通过创建`PR`时一个操作，关联上`issue`，然后当`PR`被同意之后，对应关联的`issue`也将随之关闭。
 
 同样，我先在示例项目中创建一个`issue`：
 
-![image_20220719_145415](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_145415.png)
+![image_20220719_145415](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_145415.png)
 
-这种时候，作为项目维护者，我们可以直接点击`Development`中的 `Create a branch` 创建一个fix分支，这样会自动关联上这个`issue`，同理，当该fix分支创建的`PR`被合并之后，`issue`也会自动关闭。
+这种时候，作为项目维护者，我们可以直接点击`Development`中的 `Create a branch` 创建一个 fix 分支，这样会自动关联上这个`issue`，同理，当该 fix 分支创建的`PR`被合并之后，`issue`也会自动关闭。
 
 不过这里不讲此种方案，大家有兴趣可以自行体验一番。
 
@@ -31,35 +31,35 @@ git commit -m "fix: test bug"
 git push --set-upstream origin fix_testbug
 ```
 
-推到远程之后，我们来到GitHub页面中，此时可以看到GitHub会自动提示一个新的分支可以合并：
+推到远程之后，我们来到 GitHub 页面中，此时可以看到 GitHub 会自动提示一个新的分支可以合并：
 
-![image_20220719_150429](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_150429.png)
+![image_20220719_150429](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_150429.png)
 
 可以直接点击`Compare & pull request`：
 
-![image_20220719_151051](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_151051.png)
+![image_20220719_151051](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_151051.png)
 
-注意右侧`Development`中的说明，我们可以通过在说明中添加一些[关键字](https://docs.github.com/cn/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)，从而对`issue`进行关联，并触发关闭。当然也可以先创建PR，然后再进行关联也可以：
+注意右侧`Development`中的说明，我们可以通过在说明中添加一些[关键字](https://docs.github.com/cn/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)，从而对`issue`进行关联，并触发关闭。当然也可以先创建 PR，然后再进行关联也可以：
 
-![image_20220719_151313](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_151313.png)
+![image_20220719_151313](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_151313.png)
 
-完成关联的PR，可以看到有这样的状态显示：
+完成关联的 PR，可以看到有这样的状态显示：
 
-![image_20220719_151423](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_151423.png)
+![image_20220719_151423](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_151423.png)
 
 这个时候，我们点击到`#21`号`issue`中，也可以看到被关联到该`PR`上了：
 
-![image_20220719_151547](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_151547.png)
+![image_20220719_151547](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_151547.png)
 
 现在我们将 `#23` 号`PR`进行合并，合并之后可以看到关联的`issue`也被关闭了，此次关联的临时分支也被删除了：
 
-![image_20220719_151825](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_151825.png)
+![image_20220719_151825](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_151825.png)
 
 以上就是项目协同中，`PR`与`issue`的联动维护。
 
 ---
 
-**另外：** 这里插一个小点，当我们完成一次PR流程之后，作为项目主维护人，通常会再次切回到main分支，然后将远程被合并到main分支的代码拉到本地：
+**另外：** 这里插一个小点，当我们完成一次 PR 流程之后，作为项目主维护人，通常会再次切回到 main 分支，然后将远程被合并到 main 分支的代码拉到本地：
 
 ```sh
 git checkout main
@@ -68,19 +68,19 @@ git pull
 
 这样执行之后，会发现本地代码竟然已经超过远程分支了：
 
-![image_20220719_154112](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_154112.png)
+![image_20220719_154112](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_154112.png)
 
-其中的389fe那次是当前远程分支的ID，我们可以执行如下命令，与远程对齐：
+其中的 389fe 那次是当前远程分支的 ID，我们可以执行如下命令，与远程对齐：
 
 ```sh
 $ git reset --hard origin/main
 HEAD is now at 389fe7b fix: test bug (#23)
 ```
 
-这样本地与远程就实现了对齐，在下次重新切分支，然后提交PR的时候，就不会出现上边那种，带了`几次Merge`的情况了。
+这样本地与远程就实现了对齐，在下次重新切分支，然后提交 PR 的时候，就不会出现上边那种，带了`几次Merge`的情况了。
 
 图示如下：
 
-![image_20220719_154244](https://cdn.staticaly.com/gh/eryajf/tu/main/img/image_20220719_154244.png)
+![image_20220719_154244](https://cdn.jsdelivr.net/gh/eryajf/tu/img/image_20220719_154244.png)
 
-理论上这次只有一个提交，而不应该出现3个`commit`，就是这个原因。
+理论上这次只有一个提交，而不应该出现 3 个`commit`，就是这个原因。