Skip to content

Latest commit

 

History

History
40 lines (29 loc) · 2.97 KB

CONTRIBUTING.md

File metadata and controls

40 lines (29 loc) · 2.97 KB
Raw

Steps

The following steps are based on a version of flutter/plugin's contributing guide.

Creating a fork

  • If you have not yet configured your machine with an SSH key that is known to GitHub, then follow GitHub's directions to generate an SSH key.
  • Fork this repository using the "Fork" button in the upper right corner of the repository's GitHub page.
  • git clone [email protected]:<github_user_name>/wakelock.git
  • cd wakelock
  • git remote add upstream [email protected]:creativecreatorormaybenot/wakelock.git
    This ensures that git fetch upstream is possible to fetch from this remote repository instead of from your own fork to get the latest changes.

Creating a patch

  • git fetch upstream

  • git checkout upstream/master -b <name_of_your_branch>

  • Now, you can change the code necessary for your patch.

    Make sure that you bump the version in pubspec.yaml and add an entry to CHANGELOG.md.
    The version format is r.M.m+p. You will want to increment one of these values and which one you increment depends on the impact of your patch: p for simple patches, m for minor versions, M for major versions, and r for released. Do not forget to reset the values to the right of the value you incremented to 0. You should omit +0.

  • git commit -am "<commit_message>"

  • git push origin <name_of_your_branch>

After having followed these steps, you are ready to create a pull request.
The GitHub interface makes this very easy by providing a button on your fork page that creates a pull request with changes from a recently pushed to branch.
Alternatively, you can also use git pull-request via GitHub hub.

Notes

  • You should remember to exclude all files and directories your IDE might generate using the .gitignore files (if they do not already contain them for your IDE).
    If you feel like you can make useful additions to any of the .gitignore files, you can include them in your pull request, potentially with an explanation.

  • It is probably easier for you to run the integration tests for the plugin locally using flutter drive --target=test_driver/app.dart in the example directory before opening a pull request (CI also runs the integration tests).
    This way you can ensure that any changes you have made work properly. Furthermore, you might also want to add some tests if you implement new functionality.

  • You should also run flutter format lib example --fix in the root directory and make sure that flutter analyze does not report any errors.