= 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.) == Setup == 1. Create a GitHub account (if you don't already have one) 1. Fork https://github.com/WebKit/webkit 1. `$ git clone git@github.com:yourname/webkit.git` == Writing code == 1. `$ git checkout master -b awesomefeature` 1. Write some awesome code. 1. 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://github.com/WebKit/webkit.git` 1. Switch to master branch if necessary: `$ git checkout master` 1. `$ git fetch upstream` 1. `$ git merge upstream/master` 1. `$ 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. 1. `$ git checkout master` 1. `$ git pull upstream master` 1. `$ git checkout awesomefeature` 1. `$ git rebase master` 1. Fix merge conflicts through the rebase as you normally would with git. == Getting your code reviewed == 1. Find a reviewer who is interested in reviewing your awesome feature. 1. Push your lastest commits to your feature branch (e.g., `$ git push origin awesomefeature`) 1. Create a pull request by going to https://github.com/yourname/webkit/pull/new/awesomefeature 1. 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.'' 1. Write a helpful description of your pull request and click "Send pull request". 1. 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 https://github.com/yourname/webkit/pull/7.patch | git am` 1. `$ ./Tools/Scripts/webkit-patch upload --no-review` (Note: This will upload the current branch as one patch to a newly created bugs on https://bugs.webkit.org/.) 1. 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. 1. Go to the https://bugs.webkit.org/ 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.)