Skip to content

Creating Pull Requests

Nick Airdo edited this page Feb 17, 2017 · 8 revisions

Ready to Contribute?

First of all, [sign our Contributor Agreement](https://rockrms.blob.core.windows.net/developer/Contributor Agreement - FORM.pdf) and send a copy to nick@spark... We're looking to avoid any unnecessary litigation and our lawyer said this is what we should do.

When you're ready to get involved by fixing an issue or submitting an enhancement (which you've discussed with the team via a proposed enhancement issue) below are the steps you will need to take. These steps are designed to create a clean pull request that is easy to read by the core team -- which means a higher likelihood that your change will be accepted.

Setting up your Fork and Syncing with Rock

Follow the steps outlined in this other document.

Creating an Issue Fix Pull Requests

If you have a tested fix for one of the issues that can fixed in an upcoming hotfix, do the following to create a clean, single commit Pull Request for the core team. The idea here is to avoid the What if... scenario described below.

  1. Using SmartGit...
  2. Pull the latest unpublished upstream (Spark) Rock "hotfix-x.y.z" branch and double-click it to create a local issuefix branch (and name it "issuefix-YOURINITIALS-####" ).
  3. Uncheck "track remote" when you checkout the branch (since you don't have rights to push to Spark)
  4. Apply your changes (see below**) to your local branch and then make a single commit (w/proper commit message).
  5. Click "Push" and SmartGit will create a branch on your fork with the updated changes.
  6. Go to GitHub and create a new Pull Request, comparing changes between SparkDevNetwork/Rock base:hotfix-x.y.z and YourFork/Rock base:this-pull-request.
  7. There should be a minimal number of files and lines changed so the core team can see exactly what's been changed.

Creating a Feature Pull Request

Once you've got some changes that have been developed and tested, here are the steps you can use to create a clean, single commit Pull Request for the core team. The idea here is to avoid the What if... scenario described below.

  1. Using SmartGit...
  2. Pull the upstream (Spark) Rock "develop" branch and double-click it to create a local feature branch (and name it according to the pull request).
  3. Uncheck "track remote" when you checkout the branch (since you don't have rights to push to Spark)
  4. Apply your changes (see below**) to your local feature branch and then make a single commit (w/proper commit message).
  5. Click "Push" and SmartGit will create a branch on your fork with the updated changes.
  6. Go to GitHub and create a new Pull Request, comparing changes between SparkDevNetwork/Rock base:develop and YourFork/Rock base:this-pull-request.
  7. There should be a minimal number of files and lines changed so the core team can see exactly what's been changed.

** Regarding Changes

  • When making changes keep the changes simple (i.e. don't refactor boldly) otherwise the git diff will obscure your change and make it difficult to quickly see the actual change.
  • Remember these Coding Standards
  • Remember these Committing Your Code standards
  • Use a tool like GhostDoc to help document your methods.
  • Try a tool like CodeMaid (free, in the online VS store). It will auto-align your code, add brackets to single-line if statements, remove unnecessary whitespace and more.

Thanks goes to David Stevens for providing these steps!

What if...

Q) What if I have to clean up a commit?

A) See Arran's "What to do if you need to clean up a commit" blog post.

Q) What if the upstream (Spark) Rock/develop code moves ahead while I am working?

A) If the files you are working on are modified in the upstream (if someone else's pull request is merged in, for example), you will need to update your feature branch to include these changes.

  • Make sure that you have committed your code changes to your feature branch by typing git commit -a -m "<message>" .
  • Switch to your develop branch by typing: git checkout develop .
  • Update your local develop branch in the same way as you did before you started your feature branch. Type git pull upstream develop , then update the origin by typing git push origin.
  • Switch back to your feature branch by typing git checkout <branchname>.
  • Now, we will merge the changes that we just pulled on to our develop branch to our feature branch. To do this, type: git merge develop.
  • If there are no conflicts, you should see a fast forward message. Your feature branch is now up-to-date.
  • If you do get a conflict message, you will need to manually resolve them. There is a helpful GitHub article which explains how to do this.
  • If you have already pushed your feature branch to the origin before updating, you will need to do this again. Type: git push origin <branchname>
Clone this wiki locally