diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a3b4692..ce5e60a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,10 +2,10 @@ 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: -- Submit your work in a new branch and make the PR to the `main` branch. +- Be nice. - [Write a short & descriptive commit message](http://chris.beams.io/posts/git-commit/). -- Rebase before committing the final change. -- Stick to [PSR-2](http://www.php-fig.org/psr/psr-2/). +- Rebase before pushing the final change. +- Stick to [PSR-12](http://www.php-fig.org/psr/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. @@ -15,7 +15,7 @@ Here are the steps to follow to contribute to this repository: - [Fork this repository on GitHub](#fork-this-repository). - [Clone your fork to your local machine](#clone-your-fork). - [Create a feature branch](#create-a-branch). -- [Add an 'upstream' remote](#add-a-remote). +- [Add an `upstream` remote](#add-a-remote). - [Regularly pull & rebase from the upstream remote](#pull-and-rebase). - [Work on feature branch](#working-on-branch). - [Make tests pass](#make-tests-pass) @@ -36,15 +36,27 @@ $ git clone https://github.com//.git $ cd ``` +### Determine what branch to target +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](https://svenluijten.com/posts/tagging-and-branching-strategy-for-libraries-and-packages). + ### Create a branch -Make your own feature branch in order not to clutter up `main`. +Make your own feature branch in order not to clutter up the target branch. ```bash +$ git switch +$ git pull origin # Think of a good name for your branch: # fix/typo-in-readme # feature/some-feature # bug/some-bug-you-are-fixing -$ git checkout -b +$ git switch -c ``` ### Add a remote @@ -74,7 +86,7 @@ Pull from upstream to stay up to date with what others might be doing in this re are your responsibility to resolve. ```bash -$ git pull --rebase upstream main +$ git pull --rebase upstream ``` ### Working on branch