# Autorest.Swift Contributing Guide Thank you for your interest in contributing to Autorest.Swift. - For reporting bugs, requesting features, or asking for support, please file an issue in the [issues](https://github.com/Azure/autorest.swift/issues) section of the project. - If you would like to become an active contributor to this project please follow the instructions provided in [Microsoft Azure Projects Contribution Guidelines](http://azure.github.com/guidelines.html). - To make code changes, or contribute something new, please follow the [GitHub Forks / Pull requests model](https://help.github.com/articles/fork-a-repo/): Fork the repo, make the change and propose it back by submitting a pull request. ## Pull Requests ### Submitting Pull Requests * **DO** ensure that your code is formatted and free of lint issues by running `swiftlint` and `swiftformat` before committing. * **DO** follow the [seven rules of a great Git commit message](https://chris.beams.io/posts/git-commit/#seven-rules) when writing your commit messages. * **DO** submit all code changes via pull requests (PRs) rather than through a direct commit. PRs will be reviewed and potentially merged by the repo maintainers after a peer review that includes at least one maintainer. * **DO** submit "work in progress" PRs using the GitHub [Draft Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests) feature. * **DO** give PRs short-but-descriptive names (e.g. "Improve code coverage for Azure.Core by 10%", not "Fix #1234") * **DO** refer to any relevant issues, and include [keywords](https://help.github.com/articles/closing-issues-via-commit-messages/) that automatically close issues when the PR is merged. * **DO** request reviews from -and- tag any users that should know about and/or review the change. * **DO** ensure each commit successfully builds. The entire PR must pass all tests in the Continuous Integration (CI) system before it'll be merged. * **DO** address PR feedback in an additional [fixup](https://thoughtbot.com/blog/autosquashing-git-commits) commit(s) rather than amending the existing commits, and only rebase/squash them once the PR is approved and ready to merge. This makes it easier for reviewers to track changes. * **DO** reply to PR feedback with the commit ID the addresses the feedback (e.g. "Fixed in 1234abc"). * **DO** assume that ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) will be used to merge your commit unless you request otherwise in the PR. * **DO NOT** fix merge conflicts using a merge commit. Prefer `git rebase`. * **DO NOT** mix independent, unrelated changes in one PR. Separate real product/test code changes from larger code formatting/dead code removal changes. Separate unrelated fixes into separate PRs, especially if they are in different libraries. ### Merging Pull Requests (for project contributors with write access) * **DO** use ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) by default for individual contributions unless requested by the PR author. Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit". Reasons that PR authors may request "Merge and Commit" may include (but are not limited to): - The commit history itself has semantic meaning, or the change is easier to understand as a series of individual commits. Each commit in the series should constitute an independent, isolated change, include a detailed description of the change, and be buildable so as not to break `git bisect`. - The contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash the commits manually before acceptance. ## Developer Guide ### Pre-requisites - Install Xcode 10.2 or higher. The project maintainers generally work on the latest Xcode release from Apple. - [Install autorest](https://github.com/Azure/autorest/blob/master/docs/installing-autorest.md). ### Building and Testing Open the `autorest.swift` folder in Xcode and choose the AutorestSwift scheme. Select an available Mac deployment target, and then run the *Build* or *Test* actions.