Changes between Version 3 and Version 4 of UsingGitHub
- Timestamp:
- Mar 15, 2012, 4:39:22 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UsingGitHub
v3 v4 7 7 1. Create a GitHub account (if you don't already have one) 8 8 1. Fork https://github.com/WebKit/webkit 9 1. $ git clone git@github.com:yourname/webkit.git9 1. `$ git clone git@github.com:yourname/webkit.git` 10 10 11 11 == Writing code == 12 12 13 1. $ git checkout master -b awesomefeature13 1. `$ git checkout master -b awesomefeature` 14 14 1. Write some awesome code. 15 15 1. Commit locally and push to origin (your GitHub account) as you normally would with git. … … 17 17 == Tracking upstream == 18 18 19 1. One-time setup: $ git remote add upstream git://github.com/WebKit/webkit.git20 1. $ git fetch upstream21 1. $ git merge upstream/master22 1. $ git push origin master19 1. One-time setup: `$ git remote add upstream git://github.com/WebKit/webkit.git` 20 1. `$ git fetch upstream` 21 1. `$ git merge upstream/master` 22 1. `$ git push origin master` 23 23 24 24 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. … … 28 28 1. Find a reviewer who is interested in reviewing your awesome feature. 29 29 1. Create a pull request by going to https://github.com/yourname/webkit/pull/new/awesomefeature 30 1. Click the "Change Commits" button to select that reviewer's base branch of WebKit. TODO: Investigate whether we can make reviewers members of the "WebKit" organization so you can just use WebKit/webkit@master as the base branch.30 1. Click the "Change Commits" button to select that reviewer's base branch of WebKit. 31 31 1. Write a helpful description of your pull request and click "Send pull request". 32 32 1. Iterate with the reviewer as usual using GitHub's review tools. 33 33 34 == Accepting a pull request == 34 ''TODO: Investigate whether we can make reviewers members of the "WebKit" organization so you can just use WebKit/webkit@master as the base branch.'' 35 35 36 36 == Landing a patch == 37 38 If we're going to use this process, we'd want to teach webkit-patch how to automate this process. 39 40 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` 41 1. `$ ./Tools/Scripts/webkit-patch upload --no-review` 42 1. 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.) 43 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.)