我一直在四处寻找，但找不到关于这 3 个版本的 MSYS 发生了什么的完整描述。（完全有可能我只是不知道要寻找什么。）我知道 MSYS 是支持使用 MinGW 进行开发的 Linux 工具的最小端口，但我不清楚它们三者之间的关系或开发/维护它们的团队。
需要解决的具体问题：
免责声明：我是 MSYS2 开发人员
虽然 MSYS 没有死，但我会说它看起来也不是很健康。这是一个由 MinGW 团队在多年前作为Cygwin 的一个分支启动的项目，它从未跟上 Cygwin 的步伐。
msysgit 是MSYS 稍旧版本的一个分支，带有一些自定义补丁、旧版本的 Bash 和 Perl 以及 Git 的本机端口。
MSYS2 是由 mingw-builds 团队（他们是 MinGW-w64 工具链的官方打包者）的 Alexey Pavlov 发起的一个项目，它是 Cygwin 的最新分支，它密切跟踪最新的 Cygwin，以使其不会过时。Alexey 向前移植了旧的 MSYS 补丁并添加了一些他自己的补丁。
除了提供编译本地软件所需的 Unix 工具（MSYS 的既定目标），我们还从Arch Linux移植了Pacman包管理器。Pacman 不仅仅是管理二进制包（尽管它做得很好）。它有一个名为 makepkg 的软件构建基础架构，允许创建用于构建软件的配方（PKGBUILD 和补丁文件）。
恕我直言，Pacman 的采用显着改变了 Windows 上的开源开发。不再是每个人都使用自己定制的 shell 脚本以大杂烩、不兼容的方式构建软件，包现在可以依赖于其他包，PKGBUILD 文件和相关补丁可以用作构建新 PKGBUILD 的参考。它与（本机）Windows 所能获得的（尤其是 Arch Linux）一样接近 Linux 系统，并允许对所有已安装的软件包进行简单更新。
我们至少以 Windows XP SP3 为目标，并支持 32 位和 64 位 Windows。我们会要求您永远不要将 MSYS2 与 msys 或 msysgit 混合使用。Pacman 用于管理整个系统，因此来自其他系统的文件会导致冲突。
我们还尝试将补丁上传到我们构建的项目中，并积极征求其他开源项目的贡献。我们希望其他人发现与我们一起工作很容易。
我们的主要网站位于SourceForge 上，它包含指向我们的 PKGBUILD 存储库的链接。我们还在GitHub 上提供了一个更加用户友好的安装程序站点。
如果您想了解更多信息，请随时加入我们的 IRC (oftc #msys2)。
Git 2.8（2016 年 3 月）包含一个非常详细的提交，它解释了 msys2 对于新的git-for-windows的重要性，它在 2015 年初取代了 msysgit。
请参阅Johannes Schindelin ( )提交的 df5218b (2016 年 1 月 13 日) 。（由Junio C Hamano 合并 -- --在提交 116a866中，2016 年 1 月 29 日）dscho
gitster
很长一段时间以来，Git for Windows 都落后于 Git 的 2.x 版本，因为 Git for Windows 开发人员希望让这一大跃进与从 MSys 到 MSys2 的急需跃迁相吻合。
要理解为什么这是一个如此大的问题，需要注意的是 Git 的许多部分不是用可移植的 C 语言编写的，而是 Git 依赖于 POSIX shell 和 Perl 才可用。
为了支持脚本，Git for Windows 必须提供一个最小的 POSIX 仿真层，其中包含 Bash 和 Perl，当 Git for Windows 工作于 2007 年 8 月开始时，该开发人员决定使用MSys，这是 Cygwin 的精简版本。
因此，该项目的原始名称是“msysGit”（遗憾的是，这引起了很多混乱，因为很少有 Windows 用户知道 MSys，甚至更少关心）。为了编译适用于 Windows 的 Git 的 C 代码，也使用了 MSys：它支持两个版本的 GNU C 编译器：
- 隐式链接到 POSIX 仿真层的一种，
- 另一个针对普通的 Win32 API（带有一些便利功能）。
Git for Windows 的可执行文件是使用后者构建的，因此它们实际上只是 Win32 程序。为了区分需要 POSIX 仿真层和不需要的可执行文件，后者称为 MinGW（Windows 的最小 GNU），而前者称为 MSys 可执行文件。
不过，这种对 MSys 的依赖也带来了挑战：
- 我们对 MSys 运行时的一些更改——更好地支持 Windows 的 Git——没有被上游接受，所以我们必须维护自己的分支。
- 此外，MSys 运行时没有进一步开发以支持例如 UTF-8 或 64 位，除了直到很久以后（
mingw-get引入时）才缺乏包管理系统，MSys/MinGW 项目提供的许多包都落后于各自的源代码版本，特别是 Bash 和 OpenSSL。有一段时间，Git for Windows 项目试图通过构建这些包的更新版本来纠正这种情况，但这种情况很快就变得站不住脚，尤其是像 Heartbleed 错误这样的问题需要迅速采取行动，而这与开发 Git 无关。窗户进一步。
令人高兴的是，与此同时，MSys2 项目 ( https://msys2.github.io/ ) 出现了，并被选为 Git for Windows 2.x 的基础。
就像 MSys 一样，MSys2 是 Cygwin 的精简版，但它与 Cygwin 的源代码保持同步。
因此，它在内部已经支持 Unicode，并且它还提供了我们自 Git for Windows 项目开始以来就渴望的 64 位支持。MSys2 还从 Arch Linux 移植了 Pacman 包管理系统并大量使用它。这为 Linux 用户习惯从
yumorapt-get和 MacOSX 用户习惯从 Homebrew 或 MacPorts 或 BSD 用户从 Ports 系统到 MSys2 带来了同样的便利：一个简单的操作pacman -Syu会将所有已安装的包更新到最新版本目前可用。MSys2 也非常活跃，通常每周提供多次包更新。
仍然需要两个月的努力才能使所有内容达到 Git 的测试套件通过的状态，还有几个月才能发布第一个适用于 Windows 2.x 的官方 Git，并且还有几个补丁等待提交给各自的上游项目. 然而，如果没有 MSys2，Git for Windows 的现代化根本就不会发生。
此提交为支持基于 MSys2 的 Git 构建奠定了基础。
在评论中，这个问题是在 2016 年 1 月提出的：
由于 Windows 版 Git 已经基于 MSYS2，是否已将不依赖于仿真层的二进制文件作为 MSYS2 包提供？
雷·唐纳利当时回答：
我们还没有完全合并，不。不过我们正在努力。
但是... madz 指出，在 2017 年初，这种努力没有成功。
看：
问题是我无法及时贡献会导致新的 msys2-runtime 的更改。
不过，这并不是什么大问题：我只会让 Git for Windows 的分支无限期地运行。
因此，维基现在提到（2018 年）：
Git for Windows 为 msys2-runtime 创建了一些尚未发送到上游的补丁。（这是计划好的，但在 issue #284 中确定它可能不会发生。）
这意味着您必须为 Windows 自定义 msys2-runtime 安装 Git，才能在 MSYS2 中拥有一个完全工作的 git。
请注意，自提交 aeb582a9（Git 2.22，2019 年第二季度）以来，Git for Windows 项目开始升级到基于 Cygwin v3.x 的 MSYS2 运行时版本。
mingw：允许使用 MSYS2 运行时 v3.x 进行构建最近 Git for Windows 项目开始升级到基于 Cygwin v3.x 的 MSYS2 运行时版本。
这具有非常显着的后果，
$(uname -r)不再报告以“2”开头的版本，而是以“3”开头的版本。这破坏了我们的构建，因为df5218b (
config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0) 根本没想到报告的版本uname -r依赖于底层 Cygwin 版本：它期望报告的版本与“ 2”在“MSYS2”。因此，让我们反转该测试用例以测试除以“1”开头的版本（用于 MSys）之外的任何其他内容。
即使 Cygwin 最终发布像 314.272.65536 这样的版本，这也应该为我们的未来提供保障。
Git 2.22（2019 年第二季度）将针对 MSYS2 运行时 v3.x 系列的更新进行面向未来的测试。
请参阅Johannes Schindelin ( ) 的commit c871fbe（2019 年 5 月 7 日）。（由Junio C Hamano 合并 -- --在提交 b20b8fe中，2019 年 5 月 19 日）dscho
gitster
t6500(mingw): 使用 shell 的 Windows PID在 Git for Windows 中，我们使用 MSYS2 Bash，它从 Cygwin 的 POSIX 仿真层继承了一个非标准的 PID 模型：每个 MSYS2 进程都有一个常规的 Windows PID，此外它还有一个 MSYS2 PID（对应于模拟的影子进程） Unix 风格的信号处理）。
升级到 MSYS2 运行时 v3.x 后，无法再通过此影子进程访问
OpenProcess()，因此 t6500 错误地认为其中引用的进程gc.pid（在此上下文中实际上不是真正的gc进程，而是当前的 shell）不再存在。让我们通过确保
gc.pid在此测试脚本中写入 Windows PID 来解决此问题，以便git.exe能够理解该进程确实仍然存在。
我对它们之间联系的理解是
在 mermaid 中摆弄完整的图形定义。