e461208bf9
格式化工具部分： 1. pre-commit 引入 python 的格式化工具，包括 black（代码格式化）和 isort（对“包导入顺序”的规范） 2. 允许 prettier 对文档站的 markdown 文件格式化 3. 不允许 prettier 对 markdown 文件中的代码块的代码本身进行格式化 4. 升级了 pre-commit 的各个 hook 的版本 5. 优化了 pre-commit 的日志文本显示 容器总览部分： 1. 由原来的单一轻量环境转为区分空环境、轻量环境和全量环境 2. 空环境是裸 Linux 镜像（Ubuntu），为默认环境 3. 轻量环境适合开发文档站前端 4. 全量环境适合开发 MaaCore 5. 目前，全量环境完整包含了轻量环境，轻量环境完整包含了空环境 6. 在仓库 README.md 中更新了三个环境的描述，并将链接分别设置为对应环境的创建链接 **注意：没有修改文档站中的对应文件** 7. 在各个语言的开发指南的最后，移除了 Codespace 部分的“安装额外依赖”相关描述，且将链接设置为全量环境的创建链接 **注意：没有添加“开发文档站”的指南和对应 codespace 的使用方式** 容器的轻量环境和全量环境共有部分： 1. 安装 black 和 isort 包 2. 调整 VS Code 设置，取消先前（对 markdown 文件单独指定 markdownlint 扩展作为格式化工具）的错误设置，现在 markdown 文件仍然使用默认的 prettier 扩展作为格式化工具 3. 引入 markdown-all-in-one 扩展作为语法提示工具 4. 将 node_modules 和 3rdparty 排除在 VS Code 的文本的搜索路径之外 容器的全量环境部分： 1. 为 tools 下的所有 python 脚本安装依赖 2. 使用 tools/maadeps-download.py 下载 maadeps，且将必要二进制文件软链接到 /usr/local/bin/ 3. 使用 apt 安装 cmake 和 clangd-20，将后者通过 update-alternatives 设置为系统 clangd 的默认版本 4. 使用 cmake tools 扩展，并按照 Linux 编译方法进行配置 5. 使用 clang-format 作为 c/cpp 的格式化工具，clang-format 程序主体来自 maadeps（已经软链接到 /usr/local/bin/） 6. 使用 clangd 作为 c/cpp 的语法提示工具 7. 将 MaaDeps、install 和 build 排除在 VS Code 的文本搜索路径之外 其它手动调整： 1. 更新文档站的 package.json，指定 pnpm 包管理器的版本 2. 手动保证 markdown 文件中的列表前后有空行（注意到 MarkdownLint 官方规则不一定能精准定位所有“列表前后空行”的问题，详见：https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md032---lists-should-be-surrounded-by-blank-lines ） 3. 修改了部分 markdown 文件中的 json 代码块的语法问题 **注意：相同的问题并未全部发现，仅修改了两处** 4. 在 tools 目录中，一处 python 脚本的包名误用（本地包名和某个 pip 包重名），这里修改了相应代码 5. 在 tools 目录中，一处 python 脚本使用了弃用的包 cchardet 的问题，这里更换了推荐使用的功能相近的包并修改了相应代码 自动化脚本提交的修改： 1. 自动格式化了大量 tools 中的 python 脚本 2. 自动格式化了大量 docs 中的 markdown 文件 Commits: * chore: pre-commit引入black和isort规范py文件 * chore: Auto update by pre-commit hooks [skip changelog] * chore: devcontainer添加isort扩展，排序python导入 * chore: pre-commit任务命名及更名 * style: isort fix * chore: Auto update by pre-commit hooks [skip changelog] * chore: 更新pre-commit的hook版本 * fix: 模块名与第三方库重名，大忌 * chore: 容器构建时额外安装isort * docs: md -> markdown * chore: 容器安装python包和maadeps * fix: 修复过时python包 * chore: 指定pnpm版本 * chore: container支持选择轻量环境 * chore: 去掉rust * chore: add plain env * chore: 使用clangd语言服务器 * chore: 无需单独设置markdown的格式化工具 * chore: 更新安装的clangd版本 * docs: 简易文档适配 * docs: 在仓库README中重新编排codespaces相关指引 * chore: Auto update by pre-commit hooks [skip changelog] * style: 调整缩进 * chore: 格式化工具不用特意排除被gitignore忽略的文件 * chore: sh文件在gitattributes中单列一类 * chore: 格式化docs下的markdown文件 * chore: 暂时不修改md文件中的代码块 * style: 人为明确markdown中的部分列表相关格式 * docs: 补上部分markdown的json代码块中缺失的逗号 * chore: Auto update by pre-commit hooks [skip changelog] * chore: Auto update by pre-commit hooks [skip changelog] * fix: 补上tools的服务器排序相关代码中缺失的逗号 Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * chore: 使用maadeps的clangd * build: 更新maadeps工具链版本 * style: prettier fix * revert: 还原maadeps版本 * revert: 取消使用maadeps的clangd依赖，改用系统apt安装 --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
8.7 KiB
order, icon
| order | icon |
|---|---|
| 3 | mingcute:git-pull-request-fill |
純網頁端 PR 教學
牛牛也能看懂的 GitHub Pull Request 使用指南 (*´▽｀)ノノ
::: warning
本教學中對很多概念進行了簡化，為了讓更多朋友能實際用起來，甚至有一些很不優雅但是簡單的操作，還有一些不那麽正確的解釋，還請大佬們輕噴。
若您有一定的 git 使用經驗及程式基礎，那你還看個🔨，可以看稍微進階一點的教學 Github Pull Request 流程簡述
:::
基本概念及名詞解釋
這一章節內容略微枯燥，不感興趣可以直接跳過到下面實作部分，有不理解的再回來看
Repository（倉庫）
簡稱 repo，存放我們代碼及其他資源檔案的地方
👇 可以簡單理解為目前這個網頁及裡面所有的內容，就是 MAA 的倉庫（我們一般稱之為 MAA 的主倉庫）
Fork（複製）
複製，字面意思，將 MAA 的代碼複製一份，然後可以進行後續修改等等的操作，避免把原來的弄壞了
但一般說中文 “複製” 我們可能首先想到的是 copy 的意思，fork 也沒有其他明確的翻譯，所以我們一般習慣直接說英文，比如 “把代碼 fork 一份走”
既然是複製後的，那就是 MAA (1)（bushi）
為了和原本的倉庫區分開，所以我們一般將原本的 MAA 倉庫稱為 “主倉庫”、“upstream （上遊倉庫）”、“origin （原倉庫）”；
因為每個人都可以自己複製一份走，所以複製後的稱之為 “個人倉庫”
Pull Request（拉取請求、合併請求）
簡稱 PR，“拉取請求” 這個太直譯了，聽起來很奇怪，而且字太多了打起來太累，所以也是一樣的大家一般就直接說： “來個 PR”
書接上文，你 fork（複製）的個人倉庫，修改完了，怎麽把內容提供給主倉庫呢？這時候我們就可以開一個 PR，申請將自己修改的內容加入到主倉庫中。
當然啦，既然是 “請求”，那自然是需要審批的，MAA Team 的各位可能會針對你的修改提一些意見等，當然我們的意見也不一定完全正確，大家合理討論 ~
👇 下面的是目前大佬們提的 PR，正在等待審批的
Conflict（衝突）
假設一下，主倉庫中有個 A 檔案，它的內容是 111
你 fork 了一份，將其內容改成了 222，但是你剛準備提交 PR，這時候張三也 fork 了一份並提交了 PR，並將 A 檔案改成了 333
這時候我們就會看到，你倆都修改了 A 檔案，並且修改的不同，那聽誰的好呢？這就是 Conflict（衝突）
衝突解決起來比較麻煩，這裡僅闡述概念，方便實際遇到時能理解發生了什麽，暫不闡述解決方案
純網頁端 PR 操作全流程
-
首先進入 MAA 主倉庫，fork 一份代碼
-
把 “僅 master 分支” 這個選項去掉，然後點擊 Create Fork
-
接下來來到了你的個人倉庫，可以看到標題是 “你的名字/MaaAssistantArknights”，下面一行小字 forked from MaaAssistantArknights/MaaAssistantArknights （複製自 MAA 主倉庫）
-
找到你要改的檔案，可以點 “Go to file” 進行全局搜尋，也可以直接在下面的資料夾裡翻（如果你知道檔案在哪的話）
-
打開檔案後，直接點擊檔案右上角的 ✏️ 進行編輯
-
開改！（當然如果是資源檔案這種，我們建議先在你電腦上的 MAA 資料夾裡測試修改，確認沒問題了再貼上到網頁上，避免改錯了）
-
改完了，翻到最下面，寫一下你改了啥
-
還有第二個檔案要改的？改完了發現弄錯了想再改改？都沒關係！重複 5-8 即可！
-
全改好了進行 PR ！直接點 個人倉庫 裡的 Pull Request 標籤頁
如果有 Compare & Pull Request 按鈕，那最好，直接點他！如果沒有也不用著急，點下面的 New Pull Request 也是一樣的（請看步驟 11） -
這時候來到了主倉庫，請核對一下你要 PR 的是否確認。
如圖中，中間有個向左的箭頭，是將右邊的 個人姓名/MAA 的 dev 分支，申請合併到 主倉庫/MAA 的 dev 分支。然後寫一下標題，你修改的具體內容等等的，然後點確認
-
等待 MAA Team 的大佬們審核吧！當然他們也可能會提意見
👇 比如（純屬娛樂切勿當真） -
如果大佬們說要再修改一些小問題的話，回到 你的個人倉庫，切換到先前的 dev 分支，重複 步驟 3-9 即可！
注意不需要操作步驟 2（重新 fork），也不需要操作步驟 10（重新 Pull Request），你目前的 Pull Request 仍處於待審核狀態，後續的修改會直接進入到這個 Pull Request 中
👇 比如可以看到最下面多了一條 “重新修改演示” 的內容 -
等大佬們審批通過，就全部完成啦！版本發布後，你的 GitHub 頭像將會自動進入到貢獻者列表名單中，非常感謝各位的無私奉獻！
怎麽全是二次元啊，哦我也是啊，那沒事了::: tip 貢獻 / 參與者 感謝所有參與到開發 / 測試中的朋友們，是大家的幫助讓 MAA 越來越好！ (*´▽｀)ノノ:::
-
下次如果還想提別的 PR，請先切換到 dev 分支，然後直接如下圖操作
::: warning 這個操作會強制將你的個人倉庫同步到和主倉庫一模一樣的狀態，這是最簡單粗暴但行之有效的解決衝突的方法。但如果你的個人倉庫已經有額外的編輯了，會被直接刪掉！ ::: 如果確定不會造成衝突，請使用右側綠色的Update Branch按鈕如果你不清楚 / 不 care 我上面說的這一大堆，也請點擊左側的按鈕
接著重複步驟 3-14，修改、提 PR 即可 ~