Composer: how to use your github forks


Imagine you are using a github project in your composer file

"require": {
  "original-user/project": "dev-bugfix"

Now, this dependency does not do exactly what you want, so you want to change it and use your fork instead (and potentially submit a pull-request).

How to use your fork

Just add your repository into composer.json

"repositories": [
     "type": "vcs",
     "url": ""

Important: Do not change the “require” part, it must continue using original-user/project.
Run a “./composer.phar update” and composer will then download your fork (even though it echoes “installing  original-user/project” during the operation).

Go into “vendor/original-user/project” and run “git remote -v” for a double check, you’ll see the remote source “composer” that is your fork, and “origin” that is the original project. From there you can commit the changes to your fork and update it from origin (git pull origin master).




Loading a package from a VCS repository# There are a few use cases for this. The most common one is maintaining your own fork of a third party library. If you are using a certain library for your project and you decide to change something in the library, you will want your 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. For version constraint naming conventions see Libraries for more information. Example assuming you patched monolog to fix a bug in the bugfix branch:

Git rebase and remote operations

Taken from

When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.

GIT: discard local changes and commit after a merge/pull

git – How can I discard remote changes and mark a file as “resolved”? – Stack Overflow

git checkout has the –ours option to check out the version of the file that you had locally (as opposed to –theirs, which is the version that you pulled in). You can pass . to git checkout to tell it to check out everything in the tree. Then you need to mark the conflicts as resolved, which you can do with git add, and commit your work once done: