Skip to content

Developer SOP

Jump to bottom
Paul Schwartz edited this page Nov 22, 2013 · 2 revisions

This is very much a work in flux and will likely change as we have more experience

If you are unsure how git works or what the git workflow is try it in Sandbox, that is why it is there.

Commiting

Always do a file compare before you commit any changes. No matter how trivial the edit is, you need to take a second look. If you are working with somebody else ask them to do a code review before you commit

Commenting

All commits need meaningful comments. To get a feel for what is meaningful read through existing comments and decide if from reading the comment you can tell what the change was. If the commit is linked to a Pivotal Tracker story then include a link to the story on the second line

Forking

All work should be done in a fork of the main openelisglobal github repository (or the sandbox). The purpose of this is to force pull requests from everybody, including those who might be considered core contributors. We encourage, but do not require, that you do not accept your own pull requests.

Note: a fork in github is different from what is usually thought of as a fork. Outside of github forking is thought of as “We are going to take your code and that is the last you will ever see of us”, within github forking is thought of as “We are going to take your code, make some changes and when we are done we would like you to look it over and merge it back into your repository”

Working in branches

We will be following this as our branching model. For an interesting discussion about bugs found in merged branches look here

Note the point that we are working from a model, not a mandate.

Branch naming

We will be using camelCase case for our branch names. Failure to follow this policy will result in extensive eye rolling :).

examples:

  • master branch - “master”
  • develop branch - “develop”
  • Release branch for OpenElis 3.4 - “release3.4”
  • feature branch for iSante interoperability - “ iSanteInterop”
  • bug fix to interoperability - “interopMissingGuidBug”
  • hot fix to interoperability - “hotfixRelease3.4.1”

Tagging

All merges to master should be tagged with a meaningful name. Most merges will be after releases or hotfixes so the tag should be similar to “oe3.3” If the merge is for something other than a release the suggested tags should be similar to:

  • releases - “oe3.3”
  • git configuration -- “gitConfigX”
  • installers -- “installer3.3” (the 3.3 being the latest release of OE)
  • build scripts -- “buildX”

etc. The rule is that if the artifact is tied to a release then use the last release number, otherwise just increment the last tag for that artifact

Clone this wiki locally