Version 4 (modified by, 10 years ago) (diff)


Contributing to WebKit using GitHub (Proposal)

TODO: Add an overview for what you might want to do this.


  1. Create a GitHub account (if you don't already have one)
  2. Fork
  3. $ git clone

Writing code

  1. $ git checkout master -b awesomefeature
  2. Write some awesome code.
  3. Commit locally and push to origin (your GitHub account) as you normally would with git.

Tracking upstream

  1. One-time setup: $ git remote add upstream git://
  2. $ git fetch upstream
  3. $ git merge upstream/master
  4. $ git push origin master

If you never modify your local master branch, merging upstream/master will always be a fast-forward merge (i.e., no merge conflicts). You can then merge these new commits into your in-flight feature branches as you normally would with git.

Getting your code reviewed

  1. Find a reviewer who is interested in reviewing your awesome feature.
  2. Create a pull request by going to
  3. Click the "Change Commits" button to select that reviewer's base branch of WebKit.
  4. Write a helpful description of your pull request and click "Send pull request".
  5. Iterate with the reviewer as usual using GitHub's review tools.

TODO: Investigate whether we can make reviewers members of the "WebKit" organization so you can just use WebKit/webkit@master as the base branch.

Landing a patch

If we're going to use this process, we'd want to teach webkit-patch how to automate this process.

  1. If you're landing a patch for someone else, first download and apply the patch: $ curl | git am
  2. $ ./Tools/Scripts/webkit-patch upload --no-review
  3. Fill in the ChangeLog description from the pull request, and fill out the "Reviewed by" line based on who reviewed your patch. (Please include a link to the pull request in case folks want to read the discussion.)
  4. Go to the bug for your patch and set the commit-queue+ flag. (If you're not a committer, you'll need to ask a committer to set that flag for you.)