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>
12 KiB
order, icon
| order | icon |
|---|---|
| 3 | mingcute:git-pull-request-fill |
純WebサイトのPRチュートリアル
「パラスちゃん」も理解できるGitHubのPull Requestの使用ガイド (*´▽｀)ノノ
この文書は機械翻訳です。もし可能であれば、中国語の文書を読んでください。もし誤りや修正の提案があれば、大変ありがたく思います。
::: warning このガイドでは、多くの概念を簡略化し、より多くの人々が実際に使用できるように、不格好であるが簡単な操作が含まれています。また、正しくない説明もありますので、大変恐れ入りますが、専門家の方々にはお許しください。 Gitの使用経験とプログラミングの基礎がある場合、Github Pull Request プロセス概要など、より上級のチュートリアルを見ることができます。 :::
基本概念および用語の説明
このセクションは少し退屈かもしれませんが、興味がない場合は直接実践部分に進むことができます。わからないことがあれば戻って読んでください。
Repository（リポ）
repo、コードやその他のリソースファイルを保存する場所です。
👇 これはMAAのリポジトリです（一般的にMAAのメインリポジトリと呼ばれます）。
Fork（複製）
フォーク、つまり、MAAのコードをコピーし、その後、変更などを行うことができるようにします。元のコードを壊さないようにするためです。
しかし、通常、「複製」と言うと、最初にコピーすることを考えることが多いですが、フォークには明確な翻訳がないため、通常、英語を直接使用する傾向があります。
コピー後のリポジトリは MAA (1) と呼ばれます（おおよその意味は伝わるかと思います）。
区別するために、元のMAAリポジトリは「主リポジトリ」「upstream（上流リポジトリ）」「origin（元のリポジトリ）」と呼ばれます。
それぞれの人がコピーできるので、コピーしたものを「個人リポジトリ」と呼びます。
Pull Request（プルリクエスト、マージリクエスト）
略称PR，「プルリクエスト(Pull Request)」とも呼ばれます。ただ、「プルリクエスト」と直訳すると奇妙に聞こえるため、一般的には「PR」と省略され、「PRを送ってくれ」というように言われます。
先程の話に戻りますと、自分でフォーク（複製）した個人のリポジトリを変更した場合、その変更内容をメインのリポジトリに反映させるにはどうすればいいでしょうか？ この場合、「PR」を立てて、自分の変更内容をメインのリポジトリに追加するための申請を行います。
もちろん、これは「リクエスト」であるため、承認が必要です。MAA Teamのメンバーは、あなたの変更に対していくつかの提案を行うかもしれません。もちろん、私たちの提案が完全に正しいわけではないので、合理的に議論しましょう。
👇 以下は、現在承認待ちの提出されたPRの例です。
Conflict（コンフリクト）
仮に、メインリポジトリにAというファイルがあり、その中身は「111」とします。
あなたはフォークして、中身を「222」に変更しました。しかし、ちょうどあなたがPRを提出しようとしたとき、別の人がフォークしてAファイルを「333」に変更してPRを提出しました。
これにより、Aファイルが2人によって異なる方法で変更され、どちらを受け入れるかが問題になります。これがConflict（コンフリクト）です。
Conflictを解決するのは少し面倒ですが、ここでは概念について説明し、実際に遭遇した場合に何が起こっているかを理解するために説明します。解決策については詳しく説明しません。
ウェブページでの PR 操作の全プロセス
-
まず、MAAのメインリポジトリにアクセスして、コードをforkします。
-
「Copy the master branch only」オプションを外して、Create Forkをクリックします。
-
次に、あなたの個人リポジトリに移動し、「あなたの名前/ MaaAssistantArknights」というタイトルが表示され、下に「MAAメインリポジトリから複製されたMaaAssistantArknights/MaaAssistantArknights」という文言が表示されます。
-
変更するファイルを探します。 "Go to file" をクリックしてグローバル検索を行うか、下のフォルダーから直接検索することもできます（ファイルの場所を知っている場合）。
-
ファイルを開いたら、ファイルの右上隅にある✏️をクリックして編集を開始します。
-
変更を加えます！（もちろん、リソースファイルなどの場合は、まずMAAフォルダー内で変更をテストし、問題がないことを確認してから、ウェブページに貼り付けて変更を行ってください）
-
変更が完了したら、一番下までスクロールして、変更内容を記述します。
-
変更するもう1つのファイルがある場合は、5-8を繰り返してください。
-
変更が完了したら、PRを行います！個人リポジトリのPull Requestタブをクリックします。
「Compare & Pull Request」ボタンがある場合は、それをクリックしてください。ない場合は、「New Pull Request」をクリックしてください。 -
これでメインリポジトリに移動します。PRする内容を確認してください。
スクリーンショットのように、真ん中に左向きの矢印があり、右側の「個人名/MAA」のdevブランチを「メインリポジトリ/MAA」のdevブランチにマージすることを申請しています。次に、タイトルや変更内容などを記述して、承認をリクエストします。
-
MAAチームの大佬たちに承認していただきましょう！もちろん、意見を提供してくださることもあるかもしれません
👇例えば（純粋に娯楽のために、本気にしないでください） -
大佬たちがさらに小さな問題を修正するように言った場合、あなたの個人のリポジトリに戻って、以前のdevブランチに切り替え、手順3-9を繰り返すだけで大丈夫です！
手順2（再度フォークする）を実行する必要はなく、手順10（再度プルリクエストする）を実行する必要もありません。現在のプルリクエストはまだ承認待ちの状態にあり、後続の変更はこのプルリクエストに直接反映されます。
👇 以下は例です。最下部に「再度変更デモを変更」というメッセージが追加されたことがわかります。 -
大佬たちの承認を得たら、すべて完了です！ バージョンがリリースされた後、あなたのGitHubプロフィールアイコンは自動的に貢献者リストに追加されます。皆様のご奉仕に深く感謝申し上げます！
なんで全部二次元キャラなんだろう、あ、私も二次元好きだったわ。ま、いいか::: tip 貢献/参加者 開発/テストに参加してくれたすべての友人たちに感謝します。皆さんの助けでMAAはますます良くなります！ (*´▽ ｀)ノノ:::
-
次回別のPRを提出する場合は、まずdevブランチに切り替えて、以下の図のように直接操作してください。
::: warning この操作は、あなたの個人リポジトリをメインリポジトリとまったく同じ状態に強制的に同期するものであり、最も簡単で効果的な競合解消方法です。ただし、あなたの個人リポジトリにすでに追加されているものは削除されます！
::: 競合が生じないことを確認できる場合は、右側の緑色の「Update Branch」ボタンを使用してください。私が言ったことが何を意味するのか分からない/関係ない場合は、左側のボタンをクリックしてください。
その後、ステップ3-14を繰り返し、変更を加え、PRを提出することができます。