Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Document how to integrate pull requests from github

...

  • {{svn help }}sub-command
    git sub-command --help

GitHub Integration

GitHub is a popular commercial Git hosting service. The ASF GIT repositories are mirrored there to increase visibility and to encourage more collaborators. The Infra team is responsible for maintaining the Github Apache Organisation. As an Apache committer you can also get added to the Team on GitHub, but this has no function for access control, it is purely to show off your affiliation. Some Apache Commons projects chose to advertise the related GitHub project (to accept pull requests or even problem reports). For example the README.md and CONTRIBUTING.md files produced by the build-plginplugin describe this workflow. If you accept a pull request, you have to apply it as a patch to the Apache WIP repository, this commit will then be propagated to the GitHub mirror. In the comment of the commit/merge you should use GitHub syntax (closes #xx) to close the PR. There is no other way to close pull requests. So to reduce the INFRA teams workload (to work on your tickets with close requests) remember this procedure.

Since the GitHub mirrors are read only, the Web UI cannot be used for merging PR. This has to be done manually using the command line. The procedure differs depending on whether the component you want to apply the PR to uses SVN or git.

Applying Pull Requests (for svn based components)

If you accept a pull request, you have to apply it as a patch to the Apache WIP repository, this commit will then be propagated to the GitHub mirror. In the comment of the commit/merge you should use GitHub syntax (closes #xx) to close the PR. There is no other way to close pull requests. So to reduce the INFRA teams workload (to work on your tickets with close requests) remember this procedure.

Applying Pull Requests (for git based components)

First of all, make sure the the PR you want to merge does not contain merge conflicts. If that is the case you can start merging the PR by fetching it into your local clone of repository. To do this the GitHub mirror has to be defined as a remote in your local clone. This only has to be done once and you can check whether you already did it with:

No Format

$ git remote show

This will print a list of all remotes you have defined:

No Format

$ git remote show -n
github
origin

If you don't have an entry for the github mirror yet, you can add one with:

No Format

$ git remote add github git@github.com:apache/commons-foo.git

After that $ git remote show should list the new remote. You can check the configuration with

No Format

$ git remote show github

which should print something like:

No Format

$ git remote show github
* remote github
  Fetch URL: git@github.com:apache/commons-lang.git
  Push  URL: git@github.com:apache/commons-lang.git
  HEAD branch: master
  Remote branches:
    LANG_1_0_BRANCH new (next fetch will store in remotes/github)
    LANG_2_2_X      new (next fetch will store in remotes/github)
    LANG_2_X        new (next fetch will store in remotes/github)
    LANG_4_X        new (next fetch will store in remotes/github)
    LANG_POST_2_4   new (next fetch will store in remotes/github)
    LangTwo-1.x     new (next fetch will store in remotes/github)
    master          new (next fetch will store in remotes/github)
  Local ref configured for 'git push':
    master pushes to master (up to date)

After your remote is set up, you need to fetch the branch containing the PR changes. GitHub provides readonly branches for all PR. They follow the name schema: pull/ID/head:branch-name. So if you want to merge PR #72 and the branch which was initially created by the contributor is called fix-foo-in-bar, then you need to fetch:

No Format

$ git fetch github pull/72/head:fix-foo-in-bar

After this you can checkout the PR branch locally using $ git checkout fix-foo-in-bar. Now one thing is important: If you want the PR to be marked as merged on GitHub you must not change any commit hashes (no rebase or --squash). You can look around, run tests an even add additional commits, for example adding the corresponding jira issue to changes.xml. If you're satisfied, it's time to merge the changes back to master:

No Format

$ git checkout master
$ git pull
$ git merge --no-ff fix-foo-in-bar

The pull makes sure you have the lastest changes from the Apache repository in your local clone. Merging with --no-ff option will create a separate merge commit. This is why your $EDITOR will be started asking you to provide a commit message. The first line will be "Merge branch 'fix-foo-in-bar'". You should leave it this way so the fact that this branch has been merged can be seen in the history. Furthermore a reference to the corrensponding Jira should be added. For an example see https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=commit;h=640953167adf3580a2c21077d78e7e7ce84ead03