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 your 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.)
- Create a GitHub account (if you don't already have one)
- Fork https://github.com/WebKit/webkit
- $ git clone firstname.lastname@example.org:yourname/webkit.git
- $ git checkout master -b awesomefeature
- Write some awesome code.
- Commit locally and push to origin (your GitHub account) as you normally would with git.
- One-time setup: /Tools/Scripts/configure-github-as-upstream
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
- Make sure all commits are complete on your awesomefeature branch.
- $ git checkout master
- $ git pull upstream master
- $ git checkout awesomefeature
- $ git rebase master
- Fix merge conflicts through the rebase as you normally would with git.
- Push rebased awesomefeature up to your fork: $ git push --force origin awesomefeature