-
Notifications
You must be signed in to change notification settings - Fork 0
Manually merging pull requests
This page serves as a simple "how to" for Spring committers when manually merging pull requests from contributors.
NOTE: Committers using Chrome or Firefox will want to install Phil Webb's handy user scripts that turn all SPR-1234 style JIRA ID's into a link and embed a div into the GitHub UI for all spring-framework pull requests containing the commands below, customized to the specific pull request in question.
Many of the git
commands used on this page contain placeholders as defined below.
-
<ACCOUNT>
: GitHub account for the author of the pull request -
<BRANCH>
: branch in pull request author's account (e.g., SPR-####) -
<PULL_REQUEST_NUMBER>
: spring-framework pull request number
To determine the values for these placeholders, let's take a look at pull request #111 as an example. From an open pull request page you should be able to find an example git
command for pulling the request into your local working directory. For example, if you click on the info icon in the "This pull request can be automatically merged" bar, you should see something like: git pull git://github.com/sbrannen/spring-framework.git SPR-9492
From this information we determine the placeholder values to be the following.
-
<ACCOUNT>
: sbrannen -
<BRANCH>
: SPR-9492 -
<PULL_REQUEST_NUMBER>
: 111
$> git remote add <ACCOUNT> https://github.com/<ACCOUNT>/spring-framework.git
$> git fetch <ACCOUNT>
$> git checkout --track <ACCOUNT>/<BRANCH> -b <BRANCH>
$> git rebase master
- polish and format the contribution as necessary, in line with the Contributor guidelines
- refactor code as necessary to comply with Spring practices (i.e., aim for uniformity with existing code, naming conventions, etc.)
- update and/or add Javadoc and reference manual documentation
- add a new entry in
src/dist/changelog.txt
if appropriate - once changes are finalized and committed to the local branch, you typically will want to squash multiple commits into a single commit -- for example, using
git rebase --interactive --autosquash
-- however, sometimes it gives a more complete picture of the work that was performed in you leave multiple commits as is. - if the author is a VMware employee, ensure that the author's email (i.e., in the
Author:
attribute of the commit) points to his or her actual@vmware.com
address -- for example, usinggit commit --amend --author="Firstname Lastname <flastname@vmware.com>"
$> git checkout master
$> git merge --no-ff --log -m "Merge pull request #<PULL_REQUEST_NUMBER> from <ACCOUNT>/<BRANCH>" <BRANCH>
$> git push springsource master:master
Note that the above git push
command assumes that you have configured a springsource
remote similar to the following:
$> git remote show springsource
* remote springsource
Fetch URL: git@github.com:SpringSource/spring-framework.git
Push URL: git@github.com:SpringSource/spring-framework.git
Once you have merged a pull request into master
, you should evaluate whether the change is a possible candidate for backporting. If so, create a Backport
sub-task for the JIRA issue corresponding to the pull request and schedule it for the appropriate Maintenance version (e.g., "3.1 Maintenance"). This is the 'fire and forget' model for backporting, in which someone else comes along later and processes backports in bulk (at which point they are slated for a concrete maintenance release, e.g. 3.1.3).
See JIRA for example backport sub-tasks.
This is only possible if you have write permissions for the remote repository -- for example, if you are merging your own pull request.
$> git push --force <ACCOUNT> <BRANCH>
This is only possible if you have write permissions for the remote repository -- for example, if you are merging your own pull request.
$> git push <ACCOUNT> :<BRANCH>
$> git branch -D <BRANCH>
$> git remote rm <ACCOUNT>