R. 贡献流程导引

这里是自用的MMLP wiki沙盒。可能会在这里不定期写一些东西，如果有朝一日能写完甚至可能会搬过去，不过现在就先这样吧。

贡献流程导引

粗略地说，前面几部分是广泛的原则性要求；对于初来乍到的贡献者，本章大概算是操作的指南。
本部分将会包含贡献平台的基础讲解，以及本项目从提交贡献到接受的贡献流程。

一、贡献平台讲解

本项目是构建在Git/Github系统上的。由于目前我们还没有提供其他贡献系统的计划，就撰写本段时而言（20240119），所有的贡献都将需要通过此平台来提交。因此，对其进行简单的讲解，是有必要的。

这并不意味着我们会在此向你灌注关于Git与Github的一切——这是Git与Github各自的参考文档的工作。相反，我们在此只会点明必要的基础知识；如果需要更高级的操作，可以参考其他专业文献，例如git-scm:Pro Git Book。

如果你认为你已经较为熟练地掌握了这些技能，大可跳过这一部分。

什么是Git/Github？

• 粗略地说，Git是一种版本控制系统，用于在一个项目中维护修改历史，支持用户随时调出，并以历史上的任意一处为基础做修改。
  
• 粗略地说，Github是一个Git存储库的托管平台，用于为不愿或不会自己搭建Git服务的用户提供了便捷的搭建服务，同时集成了诸多高级功能——很多和Git没什么关系。

对于这两个条目的具体定义并不是本文的重点；如果需要，可以在这两个项目的官方文献（Git，Github）中查阅。

为什么是Git/Github？

在本项目创建伊始，其实使用Github平台并没有特殊的理由，仅仅是其提供了免费的文件托管服务，从而免除了自建文件管理平台的难题；使用Git系统当然也没有别的理由，只是Github（以及后来搭建，目前停用的Weblate翻译平台）需要在Git系统上运作。

而从现状看来，使用Github平台倒是有了新的益处：Github目前集成了强大的连续集成系统（Github Actions），目前本仓库的打包流程就构建在这一系统上。

Git概念导引：修改包、更改树、分支、合并

由于这一部分常常需要与未经汉化的程序参数打交道，本段中会大量掺杂英文原文。事实上，由于各大软件中普遍以英文引用这些内容，全数提供中文反而会导致不必要的混乱。

Git系统中，用以表示一项修改的对象是修改包 commit/patch。
大体来说，修改包包括了修改内容和修改包附加数据；“附加数据”包括描述文本 commit message、作者信息、生成时间，等等。

这样的修改包，正如其名，表示的是对于若干文件的修改差异，而非文件本身；接受方必须拥有对应的初始文本，才可以正确地解读这一内容。
然而，提交者常常会在历史版本上生成修改包；这可能是由于未同步现有更改，或是目标在生成修改包后有后续更改，等等。因此，修改包的附加数据中还保存有前序提交的标记符；这一标记符是由每个提交的内容生成的SHA值（这是一种信息摘要手段）。如果有计算机技术背景的话，你可以认为这是一种指针，指向前序提交。

   -------------------------------------     --------...
<--|--- 前序更改 | 更改内容 A | 附加数据 | (<--|--- ......)
   -------------------------------------     --------...

后面简化为：

... <- A <- ... 

---

Git系统会事无巨细地记录下一个项目所有的修改包，除非明确要求除去；这是为了避免接到古老的修改包后找不到前序修改的尴尬情况。

而如果把一个项目从创建到当下的所有更改汇总起来，按照前序顺序整理的话，这就叫做更改树，因为该项目中的任何更改都可以从当前所在修改包回溯回去。

一棵修改树大概会长这样：

... <- A <- B <- C <- D <- E * main
       | <- F <- G    |      * next
            | <- H    | <- J * pu
       | <- I * fe1

需要注意的是，没有规定一个修改包之后只能跟随单个修改包；事实上，Git系统并没有提供明确的“后续更改”字段，这是因为已被上传的更改包不宜修改——原因嘛，可以看看这个。

---

在上面的示例中，我们提前用到了一些记号；比如，上面的* main是什么？

这个叫做分支 branch。
简单地说，分支就是一个特殊的标签。一般而言，这个标签的意思是某项工作目前的进度；因此，在工作进行时，分支所处的位置是会不断移动的。使用Git或基于Git的工具时，通常，每提交一个修改包，所选定的分支就会自动前移到该修改包。
一棵修改书中，分支可以有不止一个。其中，代表整个仓库的进度的为主分支，包含的一般都是已完成的工作；在本仓库中，主分支main包含了最终分发的资源包内容，其他分支上的修改包必须汇入到主分支，才可以被自动分发。

---

通常而言，修改包不会直接提交到主分支上，而是从当时的主分支所在处，新建一个分支。而当这些分支上的内容成熟时，就需要设法将这些修改包合并 merge到主分支上。

合并有多种方式；在本仓库，目前最为常用的是缩并 squash，即，将工作分支中，不属于主分支的所有修改集中到一个修改包，然后提交到主分支。在Github系统中，这些操作是很方便的。
不过，在此我们必须提出一些重要的事情：

• 修改包可能冲突！
  简单地说，主分支是会运动的。从你创建新分支到合并，主分支完全可能出现新提交。此时，无论使用何种合并方式，都需要设法将旧更改应用到新更改上。很不幸，如果两处都修改了同一位置，自动合并工具将不能完成冲突！这叫做合并冲突 merge conflict。
  当然，冲突是可以手动解决的——可以参考你所使用的编辑工具的相关说明。
• 尽量不要复用分支！（更不要复用主分支） 这是缩并的后果。
  刚才提到了，缩并是“将工作分支中，不属于主分支的所有修改集中到一个修改包，然后提交到主分支”。然而，问题是：这个新的修改包并不在工作分支上！因此，如果复用分支，且没有特别处理，在下一次合并时，上次修改的内容将会重复添加！这恐怕就不太好了。
  当然，这样的分支不是不能救回来；如果你会运用一些高级的git操作，比如变基 rebase，那也不是不行——不过这就麻烦了。

Github概念导引：

............

---

^ 目录
Q. 模组翻译的特殊要求 <--- ---> S. 本仓库的结构向导