Read CODE_OF_CONDUCT.md first.
Before submitting a new GitHub issue, please make sure to:
- Read the
README
for this repo. - Read other documentation in this repo.
- Search the existing issues for similar issues.
If the above doesn't help, please submit an issue via GitHub.
Note: If you want to report a regression (something that has worked before, but broke with a new release), please label your issue with the regression
label. This enables us to quickly detect and fix regressions.
The Core Contributors usually tag issues that are ready to be worked on and easily accessible for new contributors with the “good first issue” label. If you’ve never contributed to PactSwift
before, these are a great place to start!
If you want to work on something else, such as a new feature or fixing a bug, it would be helpful if you submit a new issue, so that we can have a chance to discuss it first. We might have some pointers for you on how to get started, or how to best integrate it with existing solutions.
Use Homebrew to install SwiftLint:
brew install swiftlint
Install Carthage to test your changes and PactSwift builds successfully when distributing through Carthage:
brew install carthage
Install xcbeautify
brew tap thii/xcbeautify https://github.com/thii/xcbeautify.git
brew install xcbeautify
- Click the “Fork” button in the upper right corner of the repo.
- Clone your fork (consult GitHub documentation about managing your forks):
git clone git@github.com:<YOUR_GITHUB_USER>/PactSwift.git`
- Create a new branch to work on with
git checkout -b <YOUR_BRANCH_NAME>
.- Branch names should be descriptive of what you're working on, eg:
docs/updating-contributing-guide
,fix/create-user-crash
.
- Branch names should be descriptive of what you're working on, eg:
- Use good descriptive commit messages when committing code.
- Write semantic commit messages following this Conventional Commits spec. This is important because the change log is automated. Following these conventions allows us to avoid the tedious non-technical tasks that come with maintaining a project.
- Please write unit tests for your code changes.
- Run the unit tests with
⌘U
in Xcode before submitting your Pull Request. - Run tests in CLI
$PROJECT_DIR/Scripts/run_tests
When you are ready to submit the PR, everything you need to know about submitting the PR itself is inside our Pull Request Template. Some best practices are:
- Use a descriptive title.
- Make sure you're not re-committing existing changes made on merged branches.
- Link the issues that are related to your PR in the body.
Once a Core Contributor has reviewed your PR, you might need to make changes before it gets merged. To make it easier on us, please make sure to avoid amending commits or force pushing to your branch to make corrections. By avoiding rewriting the commit history, you will allow each round of edits to become its own visible commit. This helps the people who need to review your code easily understand exactly what has changed since the last time they looked. When you are done addressing your review, make sure you alert the reviewer in a comment or via GitHub's rerequest review command. See GitHub's documentation for dealing with Pull Requests.
After your contribution is merged, it’s not immediately available to all users. Your change will be shipped as part of the next release.
Help us keep this project diverse, open and inclusive. Please read and follow our Code of Conduct.
Thank you for taking the time to contribute to the project!
This project is licensed under the terms of the MIT license. See the LICENSE file.
All contributions to this project are also under this license as per GitHub's Terms of Service.
This project is open source under the MIT license, which means you have full access to the source code and can modify it to fit your own needs. You are responsible for how you use PactSwift.