2,231
edits
 |
Progress Continues
We've already had 21586 updates since Dolphin 5.0. Keep up with Dolphin's continuing progress through the Dolphin Blog: February, March, and April 2024 Dolphin Progress Report. |
 |
The Dolphin Emulator Wiki needs your help! Dolphin can play thousands of games, and changes are happening all the time. Help us keep up! Join in and help us make this the best resource for Dolphin. |
Contributor's Guide: Difference between revisions
add paragraph about squashing fixes
m (→General Development workflow: add link to Buildbot page) |
(add paragraph about squashing fixes) |
||
| Line 6: | Line 6: | ||
=== General Development | === General Development Workflow === | ||
Develop changes in local | Develop changes in local Git branches, publish them in GitHub forks. For quick overview on how to use Git and which remotes to use, read TODOGitIntroduction. Testing builds for most supported platforms can be created by [[Buildbot|buildbot-try]]. If there's a chance for regressions, make sure your changes get tested properly by others. Sometimes, it might be appropriate to create a testing request on the forums. If you think your branch is ready for merging, create a pull request on GitHub. | ||
=== Handling Pull Request Comments === | === Handling Pull Request Comments === | ||
| Line 18: | Line 18: | ||
* Sometimes the reviewer suggests something different that would be equally good. If it is a matter of preference only, feel free to ignore the proposed change. | * Sometimes the reviewer suggests something different that would be equally good. If it is a matter of preference only, feel free to ignore the proposed change. | ||
If you feel like one of these scenarios applies to you, explain your concerns and we’ll decide how to continue. So far people have shown understanding in this kind of scenario. However, bear in mind that if you're just reluctant to spend the time to follow general rules (cf. the section on Quality Assurance), chances are your branch indeed will just get rejected - our desire for preserving code quality and stability is higher than having random feature XYZ, regardless of how awesome it might be. | If you feel like one of these scenarios applies to you, explain your concerns and we’ll decide how to continue. So far people have shown understanding in this kind of scenario. However, bear in mind that if you're just reluctant to spend the time to follow general rules (cf. the section on Quality Assurance), chances are your branch indeed will just get rejected - our desire for preserving code quality and stability is higher than having random feature XYZ, regardless of how awesome it might be. | ||
=== Squashing === | |||
Once it seems like everybody is happy, clean up your pull request by squashing any commits that should be part of other ones: | |||
<pre>git rebase -i master # (or whatever commit your branch is based on)</pre> | |||
Don't squash your whole pull request into one commit! Only squash incremental fixes to your previous commits and stuff like that. Also, avoid unnecessary rebasing/squashing when there is an active discussion on a commit, doing so causes GitHub to delete comments. | |||
=== Quality Assurance === | === Quality Assurance === | ||
| Line 30: | Line 35: | ||
DO NOTs for commit messages: | DO NOTs for commit messages: | ||
* No "Fix stupid mistake from previous revision". a) Explain what the issue was b) don't refer to "previous revision", mention the actual | * No "Fix stupid mistake from previous revision". a) Explain what the issue was b) don't refer to "previous revision", mention the actual Git hash of the revision instead c) Actually, this commit shouldn't occur in the history at all - it should be squashed into "previous revision" instead. | ||
* No swearing or anything like that. We understand that development can be frustrating at times, particularly when you have to clean up other people's mistakes, but commit messages are not the place for that. | * No swearing or anything like that. We understand that development can be frustrating at times, particularly when you have to clean up other people's mistakes, but commit messages are not the place for that. | ||
* Do not write "Fix issue XYZ" without explaining what the issue was about or what you did to fix it. An issue tracker is not a replacement for a proper git log. | * Do not write "Fix issue XYZ" without explaining what the issue was about or what you did to fix it. An issue tracker is not a replacement for a proper git log. | ||
| Line 41: | Line 46: | ||
Coding Style: [[Coding_Style]] | Coding Style: [[Coding_Style]] | ||
=== Getting | === Getting Further Feedback === | ||
Come and join us on IRC! Our channel is #dolphin-dev on chat.freenode.net. This is generally a good idea, but it's particularly good to gather instant feedback on things. [[Who's_Who]] provides a list of active developers and their area of knowledge. If you're asking about something specific, it might be worth asking one of the listed developers directly. Note that some people, despite being shown as "online", might not actually look at IRC for various hours, so don't start raging when you don't get an instant reply after asking people directly. | Come and join us on IRC! Our channel is #dolphin-dev on chat.freenode.net. This is generally a good idea, but it's particularly good to gather instant feedback on things. [[Who's_Who]] provides a list of active developers and their area of knowledge. If you're asking about something specific, it might be worth asking one of the listed developers directly. Note that some people, despite being shown as "online", might not actually look at IRC for various hours, so don't start raging when you don't get an instant reply after asking people directly. | ||