@ -205,7 +205,7 @@ project to use the patched version. If the library is on GitHub (this is the
case most of the time), you can simply fork it there and push your changes to
your fork. After that you update the project's `composer.json`. All you have
to do is add your fork as a repository and update the version constraint to
point to your custom branch. In `composer.json`, you should prefix your custom
point to your custom branch. In `composer.json`, you should prefix your custom
branch name with `"dev-"`. For version constraint naming conventions see
[Libraries](02-libraries.md) for more information.
@ -300,18 +300,17 @@ Please note:
The BitBucket driver uses OAuth to access your private repositories via the BitBucket REST APIs and you will need to create an OAuth consumer to use the driver, please refer to [Atlassian's Documentation](https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html). You will need to fill the callback url with something to satisfy BitBucket, but the address does not need to go anywhere and is not used by Composer.
After creating an OAuth consumer in the BitBucket control panel, you need to setup your auth.json file with
After creating an OAuth consumer in the BitBucket control panel, you need to setup your auth.json file with
the credentials like this (more info [here](https://getcomposer.org/doc/06-config.md#bitbucket-oauth)):
```json
{
"config": {
"bitbucket-oauth": {
"bitbucket.org": {
"consumer-key": "myKey",
"consumer-key": "myKey",
"consumer-secret": "mySecret"
}
}
}
}
```
@ -518,7 +517,7 @@ Typically you would leave the source part off, as you don't really need it.
> reference you will have to delete the package to force an update, and will
> have to deal with an unstable lock file.
The `"package"` key in a `package` repository may be set to an array to define multiple versions of a package:
The `"package"` key in a `package` repository may be set to an array to define multiple versions of a package:
```json
{
@ -708,7 +707,7 @@ You can disable the default Packagist.org repository by adding this to your
You can disable Packagist.org globally by using the global config flag:
@ -74,7 +74,7 @@ correct location in your `vendor` directory.
### Branches
If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special `dev-*` prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to *work* on the branch and Composer actually clones the repo into the correct place in your `vendor` directory. For tags, it just copies the right files without actually cloning the repo. (You can modify this behavior with --prefer-source and --prefer-dist, see [install options](../03-cli.md#install).)
If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special `dev-*` prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to *work* on the branch and Composer actually clones the repo into the correct place in your `vendor` directory. For tags, it just copies the right files without actually cloning the repo. (You can modify this behavior with --prefer-source and --prefer-dist, see [install options](../03-cli.md#install).)
In the above example, if you wanted to check out the `my-feature` branch, you would specify `dev-my-feature` as the version constraint in your `require` clause. This would result in Composer cloning the `my-library` repository into my `vendor` directory and checking out the `my-feature` branch.
@ -201,7 +201,7 @@ setting. All available stability flags are listed on the minimum-stability
section of the [schema page](../04-schema.md#minimum-stability).