更新

Author: muyaCode

.github/workflows/algolia.yml

@@ -12,7 +12,7 @@ jobs:
         id: algolia_config
         run: echo "config=$(cat crawlerConfig.json | jq -r tostring)" >> $GITHUB_OUTPUT
       - name: Push indices to Algolia
-        uses: signcl/docsearch-scraper-action@master
+        uses: signcl/docsearch-scraper-action@main
         env:
           APPLICATION_ID: ${{ secrets.APPLICATION_ID }}
           API_KEY: ${{ secrets.API_KEY }}

deploy.sh

@@ -19,9 +19,9 @@ git add -A
 git commit -m "GitHub Action 自动部署：$time"
 
 # # 如果发布到 https://<USERNAME>.github.io   -f 强制推送
-# git push -f [email protected]:<USERNAME>/<USERNAME>.github.io.git master
-git push -f [email protected]:muyaCode/FrontEndLearnNotes.git master:gh-pages # 发布到Gitee
-# git push -f [email protected]:muyaCode/FrontEndLearnNotes.git master:gh-pages # 发布到GitHub
+# git push -f [email protected]:<USERNAME>/<USERNAME>.github.io.git main
+git push -f [email protected]:muyaCode/FrontEndLearnNotes.git main:gh-pages # 发布到Gitee
+# git push -f [email protected]:muyaCode/FrontEndLearnNotes.git main:gh-pages # 发布到GitHub
 
 
 # 退出到本项目根目录

docs/Document/Git/02_Git命令详解.md

@@ -79,17 +79,17 @@ git pull --rebase origin [branchName] = git fetch + git rebase
 
 
 # 假设当前分支dev, commit 为 a b c d e
-# 假设master分支, commit 为 a b f g h
-git pull --rebase origin master
+# 假设main分支, commit 为 a b f g h
+git pull --rebase origin main
 # 当前分支dev commit 变为 a b c d e f g h
 ```
 
-#### git rebase master
+#### git rebase main
 
 ```bash
 # 假设当前分支dev, commit 为 a b c d e
-# 假设master分支, commit 为 a b f g h
-git rebase origin/master
+# 假设main分支, commit 为 a b f g h
+git rebase origin/main
 # 当前分支dev commit 变为 a b f g h c d e
 ```
 
@@ -118,7 +118,7 @@ git remote show <remote_name>
 
 ### stash——贮藏代码
 
-场景：当你的功能还没开发完不能 commit 但是现在需要 rebase 下 master,缓存区的代码该咋办？当你写了几行代码，但是现在需要切到其他分支去改 bug，缓存区的代码该咋办？
+场景：当你的功能还没开发完不能 commit 但是现在需要 rebase 下 main,缓存区的代码该咋办？当你写了几行代码，但是现在需要切到其他分支去改 bug，缓存区的代码该咋办？
 
 用 git stash 就好啦
 
@@ -193,28 +193,28 @@ git push <远程主机名> <本地分支名>
 
 #### 实例
 
-以下命令将本地的 master 分支推送到 origin 主机的 master 分支。
+以下命令将本地的 main 分支推送到 origin 主机的 main 分支。
 
 ```bash
-git push origin master
+git push origin main
 ```
 
 相等于：
 
 ```bash
-git push origin master:master
+git push origin main:main
 ```
 
 如果本地版本与远程版本有差异，但又要强制推送可以使用 --force 参数：
 
 ```bash
-git push --force origin master
+git push --force origin main
 ```
 
-删除主机的分支可以使用 --delete 参数，以下命令表示删除 origin 主机的 master 分支：
+删除主机的分支可以使用 --delete 参数，以下命令表示删除 origin 主机的 main 分支：
 
 ```bash
-git push origin --delete master
+git push origin --delete main
 ```
 
 以我的 https://github.com/tianqixin/runoob-git-test 为例，本地添加文件：
@@ -223,14 +223,14 @@ git push origin --delete master
 touch runoob-test.txt      # 添加文件
 git add runoob-test.txt
 git commit -m "添加到远程"
-master 69e702d] 添加到远程
+main 69e702d] 添加到远程
  1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 runoob-test.txt
 
-git push origin master    # 推送到 Github
+git push origin main    # 推送到 Github
 ```
 
-将本地的 master 分支推送到 origin 主机的 master 分支。
+将本地的 main 分支推送到 origin 主机的 main 分支。
 
 重新回到我们的 Github 仓库，可以看到文件已经提交上来了：
 
@@ -244,7 +244,7 @@ git pull：将远程仓库的修改拉取到本地仓库，更新本地分支的
 git pull <远程主机名> <远程分支名>:<本地分支名>
 ```
 
-如果远程分支是与当前分支合并，则冒号后面的部分可以省略。例如，`git pull origin master` 表示将 origin 主机的 master 分支拉取并合并到当前分支。
+如果远程分支是与当前分支合并，则冒号后面的部分可以省略。例如，`git pull origin main` 表示将 origin 主机的 main 分支拉取并合并到当前分支。
 
 ```bash
 
@@ -292,7 +292,7 @@ git reset 和 git rm --cached 都是用于修改暂存区的命令，但是有
 
 ### cherry-pick——复制提交
 
-场景：当你在 merge 或者 rebase 的时候发现冲突太多了，想哭的时候，可以用原分支 check 目标分支处理，然后再 cherry-pick 当前分支的每个提交，这样冲突就会少很多。或者另一分支上有些代码还没有 merge 到 master，但是你当前分支又非要用的时候，就可以 cherry-pick 过来一份。
+场景：当你在 merge 或者 rebase 的时候发现冲突太多了，想哭的时候，可以用原分支 check 目标分支处理，然后再 cherry-pick 当前分支的每个提交，这样冲突就会少很多。或者另一分支上有些代码还没有 merge 到 main，但是你当前分支又非要用的时候，就可以 cherry-pick 过来一份。
 
 ```bash
 # 将其他分支上已提交的commit在当前分支再提交一次，产生新的commithash
@@ -313,7 +313,7 @@ git show [commit hash]
 
 - 第三行第一个 hash 为编号 1，第二个 hash 为编号 2，以哪个父 hash 为主线则保留哪个，删除另一个
 
-- git revert -m 1 bd86846 则回滚 bd86846 的提交，且以 ba25a9d master 分支为主线保留，回滚掉 1c7036f 所在分支提交
+- git revert -m 1 bd86846 则回滚 bd86846 的提交，且以 ba25a9d main 分支为主线保留，回滚掉 1c7036f 所在分支提交
   rebase -i
 
 场景：使用 merge 导致 git 提交线乱七八糟，提交日志过多非常难看。自从使用了 rebase 提交线变得无比丝滑，使用 rebase -i 合并每个需求的所有提交成 1 个，使日志变得清晰
@@ -399,11 +399,11 @@ s 合并掉，squash = use commit, but meld into previous commit
    # 更新
    git pull
 
-   # 将远程主机 origin 的 master 分支拉取过来，与本地的 brantest 分支合并
-   git pull origin master:brantest
+   # 将远程主机 origin 的 main 分支拉取过来，与本地的 brantest 分支合并
+   git pull origin main:brantest
 
    # 远程分支是与当前分支合并，冒号后面的部分可以省略
-   git pull origin master
+   git pull origin main
 
    # 将当前分支推送到远程对应的分支（若远程无对应分支，则推送无效）
    git push
@@ -413,7 +413,7 @@ s 合并掉，squash = use commit, but meld into previous commit
 
    # 如果当前分支与多个主机存在追踪关系，则可以使用 -u 参数指定一个默认主机，这样后面就可以不加任何参数使用git push
    #，不带任何参数的git push，默认只推送当前分支，这叫做simple方式，还有一种matching方式，会推送所有有对应的远程分支的本地分支， Git 2.0之前默认使用matching，现在改为simple方式
-   git push -u origin master
+   git push -u origin main
 
    # 删除分支 （如果分支没有被合并不允许删除）
    git  branch -d 分支名称
@@ -559,7 +559,7 @@ git status
 git commit -m '添加内容'
 
 # 推送文件(将本地仓库的文件Push到远程仓库)
-git push origin master
+git push origin main
 
 # 推送
 git push
@@ -573,11 +573,11 @@ git branch 	分支名
 # 切换分支
 git checkout 分支名
 
-# 将dev分支合并到master分支
+# 将dev分支合并到main分支
 git merge dev
 
 # 主分支
-master	默认分支
+main	默认分支
 
 ```
 
@@ -607,7 +607,7 @@ git log -oneline -graph -[number]
 
 vue 规范：https://github.com/vuejs/vue/blob/dev/.github/COMMIT_CONVENTION.md
 
-Angular 规范：https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular
+Angular 规范：https://github.com/conventional-changelog/conventional-changelog/tree/main/packages/conventional-changelog-angular
 
 规范 1：
 

docs/Document/Git/04_Git提交流程.md

@@ -12,17 +12,17 @@
 
 ### 1、Git Flow 的常用分支
 
-#### 生产分支（master）‌
+#### 生产分支（main）‌
 
-Master 分支是仓库的主分支，也有人叫 Production 分支，这个分支包含最近发布到生产环境的代码，最近发布的 Release， 这个分支只能从其他分支合并，不能在这个分支直接修改 ‌
+main 分支是仓库的主分支，也有人叫 Production 分支，这个分支包含最近发布到生产环境的代码，最近发布的 Release， 这个分支只能从其他分支合并，不能在这个分支直接修改 ‌
 
 #### 补丁分支（hotfix）‌
 
-当我们在生产环境发现新的 Bug 时候，我们需要基于 master 分支创建一个 Hotfix 分支，然后在 Hotfix 分支上修复 bug，完成 Hotfix 后，我们要把 hotfix 分支合并回 Master 和 Develop 分支 ‌，所以 Hotfix 的改动会进入下一个 Release
+当我们在生产环境发现新的 Bug 时候，我们需要基于 main 分支创建一个 Hotfix 分支，然后在 Hotfix 分支上修复 bug，完成 Hotfix 后，我们要把 hotfix 分支合并回 main 和 Develop 分支 ‌，所以 Hotfix 的改动会进入下一个 Release
 
 #### 发布分支（release)‌
 
-当你需要发布一个新功能的时候，要基于 Develop 分支创建一个 Release 分支，在 Release 分支测试并修复 bug，完成 release 后，把 release 合并到 master 和 develop 分支 ‌
+当你需要发布一个新功能的时候，要基于 Develop 分支创建一个 Release 分支，在 Release 分支测试并修复 bug，完成 release 后，把 release 合并到 main 和 develop 分支 ‌
 
 #### 开发分支（develop）‌
 
@@ -34,15 +34,15 @@ feature 分支主要是用来开发一个新的功能，一旦开发完成，我
 
 ### 2、git flow 的具体使用细节
 
-当我们新建 git 仓库之后，默认会创建一个主分支也就是 master 分支，由于 master 分支是用于发布生产环境，所有必须保证 master 上代码的稳定性，所以我们不能直接在 master 分支上修改提交。我们要基于 master 分支创建一个 develop 分支，develop 分支用于保存开发好的相对稳定的功能，master 分支和 develop 分支是仓库的常驻分支，一直会保留在仓库中
+当我们新建 git 仓库之后，默认会创建一个主分支也就是 main 分支，由于 main 分支是用于发布生产环境，所有必须保证 main 上代码的稳定性，所以我们不能直接在 main 分支上修改提交。我们要基于 main 分支创建一个 develop 分支，develop 分支用于保存开发好的相对稳定的功能，main 分支和 develop 分支是仓库的常驻分支，一直会保留在仓库中
 
 当新的开发任务来了之后，就要编写代码了，我们尽量不要在 develop 分支上写代码，要保证 develop 分支的相对稳定，所以这时我要就要基于 develop 分支创建一个临时的开发分支，然后在开发分支上编写代码，等功能开发完之后我们再把开发分支合并到 develop 上
 
-新功能合并到 develop 分支之后，我们想把新功能发布到生产环境，首先基于 develop 分支创建 release 分支，然后在 release 分支测试完成之后，把 release 分别合并到 master 分支和 develop 分支
+新功能合并到 develop 分支之后，我们想把新功能发布到生产环境，首先基于 develop 分支创建 release 分支，然后在 release 分支测试完成之后，把 release 分别合并到 main 分支和 develop 分支
 
-#### release 分支合并到 master 分支之后，在 master 分支上打标签用于发布
+#### release 分支合并到 main 分支之后，在 main 分支上打标签用于发布
 
-我们把代码发布到了生产环境，用户在使用的时候给我们反馈了一个 bug，这时我们需要基于 master 分支创建一个 hotfix 分支，用于修复 bug，bug 修好之后，把 hotfix 分支分别合并到 master 分支和 develop 分支
+我们把代码发布到了生产环境，用户在使用的时候给我们反馈了一个 bug，这时我们需要基于 main 分支创建一个 hotfix 分支，用于修复 bug，bug 修好之后，把 hotfix 分支分别合并到 main 分支和 develop 分支
 
 ### 3、Git flow 工具
 
@@ -293,7 +293,7 @@ git push [[email protected]](mailto:[email protected]):MFR/hybris5511.gitdevelop2 :de
 
 **特殊说明：**
 
-git 单个提交文件不能大于 100M。不然**Push rejected: D:\MavenSpace\thinkinjava: push master to origin/master was rejected by remote**
+git 单个提交文件不能大于 100M。不然**Push rejected: D:\MavenSpace\thinkinjava: push main to origin/main was rejected by remote**
 
 **回撤版本号：**
 

docs/Document/Git/05_服务器自动部署.md

@@ -127,7 +127,7 @@ echo '======上传代码到服务器======'
 cd /www/wwwroot/test/website
 # 这个很重要，如果不取消的话将不能在cd的路径上进行git操作
 unset GIT_DIR
-git pull origin master
+git pull origin main
 # 自动编译vue项目,如有需要请去掉前面的#号
 # npm run build
 # 自动更新composer（我暂时没试过）

docs/Document/Git/Git使用简要备忘录.md

@@ -74,9 +74,9 @@ git rm src/hello.cpp    #再删除该文件在本地库的记录，不让Git继
 可以使用`git log`命令和`git reflog`查看提交历史。
 
 ```bash
-me@LAPTOP-0EQDNUEB MINGW64 /d/MyProject/GitStudy (master)
+me@LAPTOP-0EQDNUEB MINGW64 /d/MyProject/GitStudy (main)
 git log
-commit d1b5ad37d697cd4906af1646fb52d4de16124c52 (HEAD -> master)　#最近一次提交的commit id；
+commit d1b5ad37d697cd4906af1646fb52d4de16124c52 (HEAD -> main)　#最近一次提交的commit id；
 Author: Me <[email protected]>
 Date:   Sun Oct 18 10:04:59 2020 +0800
 version 1.0.0: Add hello.cpp　　　　　　　　　　#最近一次提交的提交备注；
@@ -85,9 +85,9 @@ commit 63a0bb0caaf03715455f93542ef2cad6d7bd5d79　#上一次提交的commit id
 Author: Me <[email protected]>
 Date:   Sun Oct 18 10:00:10 2020 +0800
 initial version　　　　　　　　#上一次提交的提交备注；
-me@LAPTOP-0EQDNUEB MINGW64 /d/MyProject/GitStudy (master)
+me@LAPTOP-0EQDNUEB MINGW64 /d/MyProject/GitStudy (main)
 git reflog
-d1b5ad3 (HEAD -> master) HEAD@{0}: commit: version 1.0.0: Add hello.cpp
+d1b5ad3 (HEAD -> main) HEAD@{0}: commit: version 1.0.0: Add hello.cpp
 63a0bb0 HEAD@{1}: commit (initial): initial version
 ```
 
@@ -240,10 +240,10 @@ git merge mybranch
 
 例如，开发一个需要数百人协同参与的超大型项目时，项目设一名主管，根据项目的开发需要，每个开发模块设置一名副主管，每个副主管下属若干名开发者协同完成该模块的开发。工作流程如下：
 
-1. 普通开发者在自己的主题分支上工作，并根据 `master` 分支进行变基。 这里是主管推送的参考仓库的 `master` 分支。
-2. 副主管将普通开发者的主题分支合并到自己的 `master` 分支中。
-3. 主管将所有副主管的 `master` 分支并入自己的 `master` 分支中。
-4. 最后，主管将集成后的 `master` 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。
+1. 普通开发者在自己的主题分支上工作，并根据 `main` 分支进行变基。 这里是主管推送的参考仓库的 `main` 分支。
+2. 副主管将普通开发者的主题分支合并到自己的 `main` 分支中。
+3. 主管将所有副主管的 `main` 分支并入自己的 `main` 分支中。
+4. 最后，主管将集成后的 `main` 分支推送到参考仓库中，以便所有其他开发者以此为基础进行变基。
 
 ## 总结总结一下：
 
@@ -296,7 +296,7 @@ $ git push origin xxx    //xxx是对应分支名
 - 合并分支
 
 ```bash
-$ git checkout master    //首先切换分支到master
+$ git checkout main    //首先切换分支到main
 $ git merge mybranch
 ```
 
@@ -337,17 +337,17 @@ $ git commit --amend
 
 1. Git 将会创建一个新的提交，其中包含之前的提交内容以及你刚刚添加的文件。
 
-### 您撤回了一次push
+### 您撤回了一次 push
 
-代码推送到远程仓库的master上以后，我发现有bug，挨批是不可避免了，批完还得接着解决...
+代码推送到远程仓库的 main 上以后，我发现有 bug，挨批是不可避免了，批完还得接着解决...
 
 1. 撤销最新的提交并保留更改
 
 ```bash
 $ git reset HEAD^
 ```
 
-这会将最新的提交从 master 分支中撤销，但会保留更改在工作目录中。你可以修改这些更改，然后重新提交。
+这会将最新的提交从 main 分支中撤销，但会保留更改在工作目录中。你可以修改这些更改，然后重新提交。
 
 1. 撤销最新的提交并丢弃更改
 
@@ -361,10 +361,10 @@ $ git reset --hard HEAD^
 
 如果你不想删除最新的提交，而是创建一个新的提交来修复问题，可以进行如下操作：
 
-- 在 master 分支上创建一个新的分支来进行修复：
+- 在 main 分支上创建一个新的分支来进行修复：
 
 ```bash
-$ git checkout -b fix-branch master
+$ git checkout -b fix-branch main
 ```
 
 - 在新分支上进行修改，修复代码中的问题。
@@ -376,17 +376,15 @@ $ git commit -m "Fixing the issue"
 $ git push origin fix-branch
 ```
 
+# 多个 Git 账户提交切换
 
-
-# 多个Git账户提交切换
-
-原文：[组织多个 Git 标识 |Garrit的笔记](https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities)
+原文：[组织多个 Git 标识 |Garrit 的笔记](https://garrit.xyz/posts/2023-10-13-organizing-multiple-git-identities)
 
 以下是有关如何管理多个 Git 标识（例如 personal、work、client1、client2）的快速提示。
 
-我把我的 Git 存储库分为三个级别。我的个人项目位于目录中。我所有的工作项目都住在.这是第一级。`~/sources``~/work`
+我把我的 Git 存储库分为三个级别。我的个人项目位于目录中。我所有的工作项目都住在.这是第一级。` ~/sources``~/work `
 
-级别 2 是客户端，例如 .当然，第 3 级是项目存储库：.`~/work/client1``~/work/client1/foo-api`
+级别 2 是客户端，例如 .当然，第 3 级是项目存储库：.` ~/work/client1``~/work/client1/foo-api `
 
 我的工作目录是这样组织的：
 
@@ -405,7 +403,7 @@ $ git push origin fix-branch
 
 ## .gitconfig 包括
 
-Git 的全局配置文件是 。如果您曾经设置过这样的参数：这就是它结束的地方。`~/.gitconfig``git config user.name "Foo Bar"`
+Git 的全局配置文件是 。如果您曾经设置过这样的参数：这就是它结束的地方。` ~/.gitconfig``git config user.name "Foo Bar" `
 
 .gitconfig 文件的一个很棒的功能是您可以**有条件地包含其他配置文件**，这就是诀窍所在。这是我的文件：`~/.gitconfig`
 
@@ -426,7 +424,7 @@ Git 的全局配置文件是 。如果您曾经设置过这样的参数：这就
 # ...
 ```
 
-默认情况下，我的姓名和电子邮件始终设置为我的个人身份。我还在此处存储了一些其他全局设置，但这些与本文无关。如果存储库位于目录内，则包含一个名为这只是另一个 gitconfig 文件。在我的情况下，这是这样的：`~/work``~/.gitconfig-work`
+默认情况下，我的姓名和电子邮件始终设置为我的个人身份。我还在此处存储了一些其他全局设置，但这些与本文无关。如果存储库位于目录内，则包含一个名为这只是另一个 gitconfig 文件。在我的情况下，这是这样的：` ~/work``~/.gitconfig-work `
 
 ```ini
 [user]