最好的中文TTS项目Bert-vits2更新了中文特化分支，但可能由于时间仓促，代码中存在不少的bug，作为普通用户，有的时候也想为自己喜欢的开源项目做一点点贡献，帮助作者修改一些简单的bug，那么该如何开始？
本次我们以Bert-vits2项目为例子，分享正确提交PR(Pull Requests)的方式。
FORK项目
首先面对一个开源项目，作为普通用户我们有三个选项：
点击Watch可以关注该项目，项目有了更新会提醒关注者，点击Star可以给作者鼓励，类似点赞之类的操作，这里最重要的是Fork，可以把项目拷贝一份到自己的项目库中：
在项目列表中可以看到明确标出了该项目是fork自fishaudio/Bert-VITS2项目：
Forked from fishaudio/Bert-VITS2
至此，我们对自己项目列表中的Bert-VITS2项目就有完整的读写和提交权限了。
修改代码
Github默认显示的都是主分支代码，直接修改主分支代码是非常不理智的行为，一般情况下，我们需要修改的是开发分支，这里先切换到中文特化分支上：
随后开始修改代码，这里的bug是2.3版本去掉了clap特征，而中文特化版本又加了回来，但是代码没有正确回退，导致中文特化版本训练的时候会报错：
修改成功后，提交到自己fork的分支上，注意写清楚提交理由。
提交PR
当我们提交了修改后，在项目上方会自动弹出PR窗口：
此时点击Compare & pull request，正式提交PR
提交PR的时候，也可以描述一下此次pull request的具体理由：
这里描述的越清楚，越容易被作者采纳。
作者合并PR的分支
最后，就是等待作者查看PR请求，如果代码修改的比较合理，那么作者就会考虑合并到目标分支：
如果作者认为代码有可取的地方，那么就会手动合并两个分支，也就是把fork的代码，合并到正式项目的指定分支上，如上图所示。
结语
GitHub 中的 Pull Request（PR）合并分支的原理是通过创建分支保护规则来实现的。分支保护规则定义了非项目小组的协作者在推送更改到分支之前必须满足的条件，例如需要通过状态检查或者需要有一个线性的提交历史。这样可以确保在合并 PR 到受保护的分支之前，必须满足一定的条件。
在 GitHub 中，你可以通过创建分支保护规则来强制执行特定的工作流程或要求。这些规则可以限制谁可以推送更改到受保护的分支，以及是否允许强制推送或删除分支。
当你创建一个分支保护规则后，协作者在推送更改或合并 PR 到受保护的分支时，必须满足规则中定义的条件。这有助于确保代码的质量和安全性，特别是在团队协作的情况下。
总而言之，GitHub 中的分支保护规则可以帮助开源团队管理代码的流程和质量，确保在合并非开发小组的代码到指定分支之前，必须满足一定的条件和要求。
