IGB Developer's Guide
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

To develop IGB, we use the Forking Workflow described in https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

The following sections describe how to use this workflow to develop IGB.

Fork the code on Bitbucket

To contribute a change to the IGB code base, create your own fork of the IGB repository.

To create your own fork:

Next, you'll see a form that let's you give your fork a name and description. Here's an example:

Fill in the fields and click Fork repository.

After a moment, the Overview page for your forked repository will appear. 

See Atlassian documentation Forking a Repository.

Clone your fork

Clone a copy of your forked IGB repository onto your computer. You will make changes to your local clone, commit them to your local repository, and then ultimately push your changes to your fork hosted on Bitbucket.

To clone your fork:

git clone <ADDRESS>

where ADDRESS is the address of your fork on Bitbucket. To get the address of your fork, look at the top the top right of your fork's Overview page on Bitbucket.

Make a branch

Before you start making changes to your local clone, you should first create a new branch for the changes you intend to make. This will allow you to issue focused, low risk pull requests that can be easily merged with other branches of development.

To make a branch:

  • First, you will need to switch to the latest development branch. Then you will be able to create a new branch from this context. For example, if the development branch is igb_8_6, you would execute:
git checkout igb_8_6
  • Next, create a branch for the changes you plan to make:
git checkout -b BRANCH

where BRANCH is the name of the branch, e.g., IGBF-203, the name of a story in the IGB JIRA issue-tracking system.

Edit code, push to your fork

Edit your code, test it locally, commit your changes to your local copy, and then push them to your fork hosted on Bitbucket. For example:

  • Commit a bug fix to your local copy:
git commit -m "Correcting a typo - joe instead of jeo"
  • Push to the remote repository, aliased to "origin"
git push origin BRANCH

 

Issue pull request

To request that your edits be incorporated into the main line of development:

  • Go to your fork's project Overview page
  • Select Create Pull Request

A pull request form will appear. Fill in the fields:

  • Select your branch (see above) as the pull request source (left side).
  • Select the current development branch as the pull request target (right side).
  • Fill in the Title and Description fields 
  • Click Create pull request

 

Synchronize with the main repository - development branch

If the main development branch changes, you should merge in those changes to your fork. Bitbucket has utilities that make this easy -  see https://blog.bitbucket.org/2013/02/04/syncing-and-merging-come-to-bitbucket/. 

To bring a remote fork up-to-date with a development branch:

  • Add the original, main IGB repository as a remote git repo with the alias "upstream"

 

git remote add upstream git@bitbucket.org:lorainelab/integrated-genome-browser.git

 

  • Fetch and merge changes from upstream for a development branch (e.g., igb_8_5) using  pull or rebase commands

 

git pull upstream DEVBRANCH

or

git pull --rebase upstream DEVBRANCH

 

  • Push these changes back to your fork (aliased to "origin" in this example)

 

git push origin DEVBRANCH

 

GenoViz Software Development Kit

IGB makes heavy use of graphical user interface components in the GenoViz Software Development Kit.  Normally, when you build IGB, you'll use a copy of the GenoViz SDK downloaded from our maven repository at http://eos.transvar.org/nexus/. However, if you clone and build your own copy, your version will automatically get added to your local maven repository.

Build the javadocs

 

To build javadocs, run

mvn javadoc:javadoc
  • No labels