Thank you for considering to contribute to this repository! This file will walk you through all the steps to ensure both you and I have a good time submitting and reviewing your contribution. First off, some basic rules and reading material:
- Be nice.
- Write a short & descriptive commit message.
- Rebase before pushing the final change.
- Stick to PSR-12.
- Add tests if necessary and ensure all the tests are green on the final commit.
- Make sure the CI tools used by the repository are all in order. If one fails, you should make it pass.
Here are the steps to follow to contribute to this repository:
- Fork this repository on GitHub.
- Clone your fork to your local machine.
- Create a feature branch.
- Add an
upstream
remote. - Regularly pull & rebase from the upstream remote.
- Work on feature branch.
- Make tests pass
- Submit a pull request to the master branch.
Fork the repository right here on GitHub. To learn more about forking a repository, visit GitHub's help article.
Clone your repository on your local machine to start work on your pull request.
$ git clone [email protected]:<USERNAME>/<REPOSITORY>.git
# Or if you prefer HTTPS:
$ git clone https://github.com/<USERNAME>/<REPOSITORY>.git
$ cd <REPOSITORY>
If your pull request contains a feature, it should be submitted to the latest version branch. Say the latest version
is v2.3.8
, you should target your pull request to the 2.x
branch.
If your pull request contains a bug fix, target it to the earliest version that bug is present in. So if version
v1.2.0
introduced a bug, submit the bug fix to the 1.x
branch, even if v2.0.0
is already out. If you're not sure,
target the latest version (2.x
, in case of this example).
I go into detail about this in my blog post.
Make your own feature branch in order not to clutter up the target branch.
$ git switch <TARGET_BRANCH>
$ git pull origin <TARGET_BRANCH>
# Think of a good name for your branch:
# fix/typo-in-readme
# feature/some-feature
# bug/some-bug-you-are-fixing
$ git switch -c <BRANCH_NAME>
Add an upstream
remote to pull from and to stay up to date with the work being done in there.
# List all current remotes
$ git remote -v
origin [email protected]/<USERNAME>/<REPOSITORY>.git (fetch)
origin [email protected]/<USERNAME>/<REPOSITORY>.git (push)
# Add a new remote called `upstream`
$ git remote add upstream [email protected]:svenluijten/<REPOSITORY>.git
# Or if you prefer HTTPS:
$ git remote add upstream https://github.com/svenluijten/<REPOSITORY>.git
# The new remote should now be in the list
$ git remote -v
origin [email protected]/<USERNAME>/<REPOSITORY>.git (fetch)
origin [email protected]/<USERNAME>/<REPOSITORY>.git (push)
upstream [email protected]/svenluijten/<REPOSITORY>.git (fetch)
upstream [email protected]/svenluijten/<REPOSITORY>.git (push)
Pull from upstream to stay up to date with what others might be doing in this repository. Any merge conflicts that arise are your responsibility to resolve.
$ git pull --rebase upstream <TARGET_BRANCH>
Do your magic and make your fix. I can't help you with this 😉. Once you're happy with the result and all tests pass, go ahead and push to your feature branch.
$ git push origin <BRANCH_NAME>
You can run composer check
to see if the tests & static analysis pass. Feel free to only run the static analyses at the
very end, this could take a while on bigger projects. To only run the tests, run composer test
.
Now head back over to this repository on GitHub and submit the pull request!