mirror of
https://github.com/citra-emu/citra.git
synced 2024-11-26 03:20:05 +00:00
A little more work on PR guidelines
parent
d395ec5a91
commit
7c33e82081
@ -18,7 +18,10 @@ When generating the native build script for your toolset, cmake will try to find
|
|||||||
If clang format is found, then cmake will add a custom build target that can be run at any time to run clang format against *all* source files and update the formatting in them. This should be used before making a pull request so that the reviewers can spend more time reviewing the code instead of having to worry about minor style violations. On MSVC, you can run clang format by building the clang-format project in the solution. On macOS, you can either use the Makefile target `make clang-format` or by building the clang-format target in XCode. For Makefile builds, you can use the clang-format target with `make clang-format`.
|
If clang format is found, then cmake will add a custom build target that can be run at any time to run clang format against *all* source files and update the formatting in them. This should be used before making a pull request so that the reviewers can spend more time reviewing the code instead of having to worry about minor style violations. On MSVC, you can run clang format by building the clang-format project in the solution. On macOS, you can either use the Makefile target `make clang-format` or by building the clang-format target in XCode. For Makefile builds, you can use the clang-format target with `make clang-format`.
|
||||||
|
|
||||||
# Pull Request Guidelines
|
# Pull Request Guidelines
|
||||||
Pull requests (PRs) are expected to have at least a minimal description of their intention. Pull requests with GUI changes are expected to have screenshots depicting the changes. Similarly, when fixing visual or audio issues it's nice to have sample images, video or audio.
|
[Pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (PRs) are expected to have at least a minimal description of their intention. Unless it's obvious, please try to explain the motivation behind it, what the change is, and what other consequences the changes may have (if any).
|
||||||
|
|
||||||
|
PRs with GUI changes are expected to have screenshots depicting the changes. Similarly, when fixing visual or audio issues it's nice to have sample images, video or audio.
|
||||||
|
|
||||||
If there's a specific issue that's fixed by the PR, you should mention it. If you believe the issue is completely fixed by the PR, you may also [link it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) so it's automatically closed when the PR is merged.
|
If there's a specific issue that's fixed by the PR, you should mention it. If you believe the issue is completely fixed by the PR, you may also [link it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) so it's automatically closed when the PR is merged.
|
||||||
|
|
||||||
# Code and Style Guidelines
|
# Code and Style Guidelines
|
||||||
|
Loading…
Reference in New Issue
Block a user