Child pages
  • Git Workflow for Committers
Skip to end of metadata
Go to start of metadata

For developers (people with push access) the following workflow is strongly recommended.

Project Setup

See for information on how to create a fork, clone it and add a reference to the repository.

On This Page

Keeping Up To Date

These instructions can be applied to any branch by replacing master with the branch you're interested in keeping up to date, rel-3-2-patches for example.

Making a Minor Change

Use these instructions when making a change that only requires one commit.

  1. Follow the steps in Keeping Up To Date 
  2. Make your changes
  3. Commit your changes

  4. Push your Changes 

Making a Major Change

Use these instructions when making a change that requires multiple commits or review by others

  1. Follow the steps in Keeping Up To Date 
  2. Create a Topic Branch 

  3. Make your changes
  4. Commit your changes 

  5. Push your Topic Branch 

  6. Repeat from Step 3 until the Topic work is complete
  7. Follow the steps in Keeping Up To Date
  8. Merge your topic branch into master 

  9. Push your Changes 

Updating Patches Branches

Use these instructions when making a change that is required on multiple branches. For example fixing a bug in 4.1.0 (master) that also exists in 4.0.6 (rel-4-0-patches)

  1. Follow either the Making a Minor Change or Making a Major Change steps above
  2. Record the commit ID(s) involved in the change. A tool such as gitk or the commit log on GitHub can be used as well.

  3. Checkout the branch to apply the change to

  4. Follow the steps in Keeping Up To Date for the target branch
  5. Cherry-Pick the commit(s) for the change into the branch

  6. Push your Changes 

Merging Pull Requests

When a pull request from a non-committer comes in the following review steps need to be taken before and after the merge


Pre-Merge Steps

  1. Verify that all commits in the pull request reference the Jira Issue ID that the pull is addressing
  2. Do a code review of the changes 

Merge Steps

  1. If the Pre-Merge steps all look good you can use the green Merge Pull Requestbutton.
    1. Once the request has been merged it is your responsibility to pull down the changes locally and verify they actually work.
    2. If there is a problem with the merge do a local revert and then push that to GitHub

  2. If there are problems with the commit messages either close the pull and request the user to rework the commits or do a local merge and use rebase -i to rewrite the commit messages. These steps are available from the info icon on the left edge of the Merge bar on the pull request page
    1. Check out a new branch to test the changes — run this from your project directory

    2. Bring in user-name's changes and test

    3. Interactive Rebase to rewrite the commit messages by following the steps here:
    4. Merge the changes and update the server

Post-Merge Steps

  1. Update the JIRA issue to resolved.  Make sure the Fix Version is correct.

Releasing artifacts

To release artifacts perform the following steps.  You will also need to setup your account with Sonatype first.  See Sonatype documentation.

If you have a single repository, or your origin repository is the Jasig repository, 
release:prepare and release:perform commits will be pushed to github automatically.

Additionally, it is helpful to do the following:


  1. Insure all issues referenced in the git commits since the last release are marked as resolved with the correct release version (especially if you did a major or minor release and not a patch release).
  2. Request the JIRA project owner to mark the version # you released the portlet as released and create a new patch version #

Wiki Documentation

  1. As best you reasonably can, review the uportal or portlet Wiki document and update it as appropriate, especially any configuration additions/changes.  Ideally this was already done by the individual committers.