Pull Request

Léo Colombaro edited this page Feb 1, 2014 · 4 revisions

Are you considering sending a Pull Request? You may make my day. But please read and follow these rules before you proceed.

Guidelines for Pull Requests

  1. Please ask first Before embarking on any significant pull request (e.g. implementing features, refactoring code... ), otherwise you risk spending a lot of time working on something that will not get merged into the project :-(
  2. Licensing
    By submitting a patch, you agree that your code will be licensed under the same hippie license that YOURLS uses, aka the "Do whatever the hell you want with it" license.
    See also MIT License terms.
  3. Coding Standards
    Please adhere to YOURLS Coding Standards. Make sure you've tested your patch under different scenarios (various browsers, non default installation path, etc...)

Pull Request crash course

  1. Fork the project, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
    git clone https://github.com/<your-username>/YOURLS
    # Navigate to the newly cloned directory
    cd YOURLS
    # Assign the original repo to a remote called "upstream"
    git remote add upstream https://github.com/YOURLS/YOURLS
  2. If you cloned a while ago, get the latest changes from upstream (aka "sync your fork")

    git checkout <dev-branch>
    git pull upstream <dev-branch>
  3. Create a new topic branch to contain your feature, change, or fix:

    git checkout -b <my-awesome-feature>
  4. Commit your changes in logical chunks. These git commit message guidelines are a great read. Use Git's interactive rebase feature to tidy up your commits before making them public.

  5. Locally merge (or rebase) the upstream development branch into your topic branch:

    git pull [--rebase] upstream master
  6. Push your topic branch up to your fork:

    git push origin <my-awesome-feature>
  7. Open a Pull Request with a clear title and description.