Changes between Version 3 and Version 4 of UsingGitHub


Ignore:
Timestamp:
Mar 15, 2012 4:39:22 PM (10 years ago)
Author:
abarth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UsingGitHub

    v3 v4  
    77 1. Create a GitHub account (if you don't already have one)
    88 1. Fork https://github.com/WebKit/webkit
    9  1. $ git clone git@github.com:yourname/webkit.git
     9 1. `$ git clone git@github.com:yourname/webkit.git`
    1010
    1111== Writing code ==
    1212
    13  1. $ git checkout master -b awesomefeature
     13 1. `$ git checkout master -b awesomefeature`
    1414 1. Write some awesome code.
    1515 1. Commit locally and push to origin (your GitHub account) as you normally would with git.
     
    1717== Tracking upstream ==
    1818
    19  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
     19 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`
    2323
    2424If 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.
     
    2828 1. Find a reviewer who is interested in reviewing your awesome feature.
    2929 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.
    3131 1. Write a helpful description of your pull request and click "Send pull request".
    3232 1. Iterate with the reviewer as usual using GitHub's review tools.
    3333
    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.''
    3535
    36  
     36== Landing a patch ==
     37
     38If 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.)