企业官网建设流程全解析

• 桌面应用

本文基于仓库根目录的 CONTRIBUTING.md 贡献指南，面向希望参与 Borderless-Gaming（一款将窗口化游戏转为无边框全屏的 Windows 开源工具）开发的开发者。文章完整覆盖"提交 Issue → Fork 仓库 → 创建 Topic 分支 → 遵循编码规范 → 提交 Pull Request"的全流程，并结合仓库源码（BorderlessGaming.sln、Program.cs、Config.cs 等）说明每一项规范的落地依据，让你在提交第一个 PR 之前就能充分了解项目的协作方式与代码结构。

项目速览：你将要贡献的 Borderless-Gaming

Borderless-Gaming 是一个将窗口化游戏转换为无边框全屏窗口的 Windows 桌面工具，核心价值是让游戏"看起来像全屏"却保留窗口模式的所有优点，省去反复 Alt+Tab 的等待。项目以 GNU GPL v2.0 协议开源（见 LICENSE），源码按两层结构组织：

• BorderlessGaming：主程序（WinForms 界面层），包含 MainWindow.cs、DesktopAreaSelector.cs 等窗体与入口 Program.cs；
• BorderlessGaming.Logic：核心逻辑库，包含配置模型（Models）、进程监控（ProcessWatcher.cs）、系统 API 封装（Windows）等与 UI 无关的实现。

整个解决方案只有这两个项目，解决方案文件 同时支持Debug/Release与Any CPU/x64/x86多种平台组合，贡献者通常只需关注这两个目录下的改动。

贡献前准备：账号、Issue 与 Fork

按照 CONTRIBUTING.md 的"如何准备"一节，正式开始改代码之前需要完成三件事：

1. 准备一个 GitHub 账号：所有 Issue 与 Pull Request 都通过 GitHub 协作完成；
2. 先提交 Issue，再动手改代码：如果尚未存在对应 Issue，先在 Issue 列表中以 ticket 形式登记你的问题。提交 Issue 时有两点硬性要求：
   • 若是 Bug，必须描述问题并给出可复现步骤（steps to reproduce）；
   • 必须明确指出你已知的最早受影响版本（the earliest version that you know is affected）。由于项目发布节奏与版本迭代较快（仓库 version.xml 中记录的当前版本为 9.6.0），标明版本能帮助维护者快速定位回归点。
3. Fork 仓库：如果你有能力且愿意修复该问题，将官方仓库 Fork 到自己的账号下，后续所有改动都在你自己的副本中进行。

另外，从 README.md 的"Helping Borderless-Gaming"一节可以补充两条与贡献相关的约定：发现 Bug 时尽量详述 Bug 及其上下文；如果是功能建议，先检索现有 Issue 列表确认是否已有人提过，若没有则以enhancement标签提交 Feature Request。

在 Fork 中创建 Topic 分支：不要直接在 master 上工作

Fork 完成之后进入"修改代码"阶段。核心原则是：为每一次改动创建独立的 Topic 分支（主题分支），避免直接在master分支上开发。

Topic 分支通常基于master分支创建，CONTRIBUTING.md 给出了标准的命令流程：

# 基于 master 创建新分支 git branch fix/master/my_contribution master # 切换到该分支 git checkout fix/master/my_contribution

分支命名要求"见名知意"，指南中给出的两个示例非常典型：

• better favorites detection（改进收藏夹进程检测）
• failed-to-edit-window-fix（修复窗口编辑失败的问题）

可以看到，命名由"意图描述 + 类型后缀"构成，让协作者仅凭分支名即可判断这次 PR 要解决什么。之所以刻意强调"不要直接在 master 上工作"，是因为 master 是合并基线，直接在其上提交会让后续的 PR 审查、rebase 和 cherry-pick 都变得混乱。

遵循仓库既有编码规范：两个空格、无尾随空格、a = b

CONTRIBUTING.md 明确要求贡献者沿用仓库已使用的编码风格，并给出了三条硬性语法规则：

• 缩进使用两个空格，禁止使用 Tab；
• 不允许尾随空白（trailing whitespace），空行中也不应残留空格；
• 赋值运算符两侧留空格，即a = b，而不是a=b；
• 除此之外，遵循源码中已有的约定（Follow the conventions you see used in the source already）。

这些规范并非空泛要求，仓库源码就是它们的活样例：

• 缩进风格：搜索整个 BorderlessGaming 与 BorderlessGaming.Logic 目录，未发现以 Tab 开头的行；例如 Program.cs 中Application.EnableVisualStyles();等语句均以两个空格缩进，ProcessWatcher.cs 的 196 处缩进行也全部为两空格风格；
• 赋值写法：以 DesktopAreaSelector.cs 为例，Location = new Point(rect.Left, rect.Top);与Size = new Size(rect.Width, rect.Height);均遵循a = b的空格规则；
• 命名与组织约定：项目采用 C# 的 PascalCase 成员命名、static工具类（如 Tools.cs）、ProtoBuf 模型类（[ProtoContract]/[ProtoMember]，见 AppSettings.cs）等既定模式，新增代码应保持同一风格。

以"逻辑单元"为单位提交，写清楚提交信息

指南要求按逻辑单元（logical units）拆分提交，并对每次提交做恰当的描述。这意味着：

• 不要在一次提交里混入多个无关改动，例如"修 Bug A + 顺手重排了某文件"应当拆成两个提交；
• 提交信息要能说明"为什么改"以及"改了什么"，让维护者在 review 和回滚时都能快速理解。

这一要求在仓库的后续维护中同样可见——例如 LanguageManager.cs 的语言包加载逻辑、Config.cs 的配置读写逻辑均按单一职责组织，便于逐模块审查与演进。

提交 Pull Request：选对目标分支、引用 Issue、交给他人审查

改动完成并提交后，进入"提交变更"环节，CONTRIBUTING.md 给出了四条明确规则：

1. 将改动推送到你 Fork 仓库中的 Topic 分支，然后向原仓库打开 Pull Request；
2. 选择正确的原分支作为 PR 的目标分支（通常是 master），确保补丁落在维护者期望合并的位置；
3. 在提交信息（或 PR 描述）中引用并更新对应 Issue，将代码变更与 Issue 关联起来；但请勿自行关闭该 Issue——关闭 Issue 的动作应留给维护者，由其确认修复已合并后再关闭；
4. 即使你拥有仓库的写权限，也不要直接推送或合并 Pull Request：PR 必须交由另一位团队成员审查（review）并批准后才能合并。这是为了避免"自己写、自己审、自己合并"带来的盲区，保持协作质量。

贡献前的源码导航：读懂仓库再动手

为了让你的 PR 更容易被接受，动笔前建议先花几分钟熟悉项目的关键代码路径，以下位置覆盖了绝大多数改动场景：

1. 程序入口与初始化流程

入口位于 Program.cs：Main()中依次调用Tools.Setup()（创建数据目录、注册全局异常处理、加载配置与语言包）、ForegroundManager.Subscribe()订阅前台窗口变化，最后Application.Run(new MainWindow())启动主界面。贡献者若改动启动流程，应围绕这三步展开。

2. 配置系统（config.bin）

配置由 Config.cs 管理，以 protobuf 二进制形式持久化（Security.SaveConfig/Security.LoadConfigFile），并在启动时通过 StartupOptions.cs 解析命令行参数（-m/--minimize最小化启动、-s/--silent静默启动）。可配置项定义在 AppSettings.cs，包括：

新增设置项时必须同步为字段加上[ProtoMember(n)]编号并注意向后兼容。

3. 语言包（.lang 文件）

项目支持多语言，语言文件位于 Languages/（如 en-US.lang、zh-CN.lang），格式为key|value每行一条，#开头为注释；解析逻辑见 Language.cs，加载与切换见 LanguageManager.cs。如果你想贡献翻译，这是最轻量、最适合作为"第一个 PR"的切入点。

4. 进程监控与无边框处理

核心逻辑在 ProcessWatcher.cs：后台线程每隔 3 秒（开启SlowWindowDetection后为 10 秒）扫描带窗口的进程，对匹配收藏规则（Favorite.cs 支持按进程名、窗口标题、正则三种匹配）的窗口调用RemoveBorder系列方法执行去边框、去菜单、最大化等操作。系统进程黑名单定义在 HiddenProcess.cs，新增需要屏蔽的进程可在此追加。

贡献清单与更多资料

最后，将 CONTRIBUTING.md 的完整流程浓缩为一张可对照执行的检查清单：

1. 已有 GitHub 账号；
2. 检索 Issue 列表，必要时以enhancement标签提交功能建议；Bug 则附上复现步骤与最早受影响版本；
3. Fork 仓库；
4. 基于 master 创建描述性 Topic 分支（如fix/master/my_contribution）；
5. 遵循两空格缩进、无尾随空格、a = b及既有代码约定完成修改；
6. 按逻辑单元拆分提交，并撰写清晰的提交信息；
7. 推送分支，向正确目标分支打开 PR；
8. 在提交信息/PR 中引用 Issue，但不自行关闭；
9. 等待团队成员 review 并批准合并，即使拥有写权限也不直接 push/merge。

如果对 GitHub 本身的操作流程不熟悉，官方文档（General GitHub documentation、GitHub pull request documentation）提供了更详细的平台使用说明；而本仓库 README.md 与 CONTRIBUTING.md 则覆盖了从构建（用 Visual Studio 打开 BorderlessGaming.sln 选择 Release 生成）到提交 PR 的全部项目级约定。遵循上述流程，你的第一个贡献就能高效、合规地进入项目。

• 桌面应用