Version 19 (modified by, 11 years ago) (diff)


Using GitHub to Contribute to WebKit (Experimental)

Sometimes when folks are developing an experimental feature, they feel stressed by WebKit's current code review system because breaking their feature down into many small patches that land over a period of weeks makes it harder for them to iterate on the feature. This document describes an alternative process for contributing to WebKit that uses a more git-like approach based on GitHub's tools. This process is somewhat experimental, but it might work well for folks who are familiar with git-style development and are working on largely self-contained features.

Because this process is experimental, you'll probably want to line up a reviewer for you changes ahead of time to make sure they're interested in using this process.

Note: This document assumes that you're already familiar with git and GitHub. If you're interested in learning about git and/or GitHub, there are lots of great tutorials and blog posts around the web. (Please feel encouraged to add links that you've found helpful.)


  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. Switch to master branch if necessary: $ git checkout master
  3. $ git fetch upstream
  4. $ git merge upstream/master
  5. $ 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.

Rebase from upstream/master

  1. Make sure all commits are complete on your awesomefeature branch.
  2. $ git checkout master
  3. $ git pull upstream master
  4. $ git checkout awesomefeature
  5. $ git rebase master
  6. Fix merge conflicts through the rebase as you normally would with git.
  7. Push rebased awesomefeature up to your fork: $ git push --force origin awesomefeature

Getting your code reviewed

  1. Find a reviewer who is interested in reviewing your awesome feature.
  2. Push your lastest commits to your feature branch (e.g., $ git push origin awesomefeature)
  3. Create a pull request by going to
  4. Click the "Change Commits" button to select that reviewer's WebKit repo as the "base branch". TODO: Investigate whether we can make reviewers members of the "WebKit" organization so we can just use WebKit/webkit@master as the base branch.
  5. Write a helpful description of your pull request and click "Send pull request".
  6. Iterate with the reviewer as usual using GitHub's review tools.

Landing your code

TODO: If we're going to use this process, we'll probably want to teach webkit-patch how to automatically fill in the ChangeLog description and "Reviewed by" lines from the pull request.

  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 (Note: This will upload the current branch as one patch to a newly created bugs on
  3. Fill in the ChangeLog description and the "Reviewed by" line from the pull request. Please also include a link to the pull request so folks can read the full 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.)