GIT Branching Instructions

ficklin's picture

Audience: 

Tripal Version: 

Introduction

Tripal is now using the Drupal GIT.  The following documents the branching protocol for Tripal core developers, but these same protocols can be used by those who develop extension modules.   By default, all GIT repositories have a 'master' branch.  Drupal requires that We will not be using the master branch as we will have a development branch for each major release candidate.  Therefore, the master branch will remain empty with the exception of a README file.  There are  four types of branches that will be used for Tripal Development:

    Development Branches
    Task Branches
    Bug Fix Branches
    Release Branches

Development Branches

Each major version of Tripal will have it's own development branch.   These branches are named according to the following pattern:

[drupal major].[drupal minor]-[tripal major].[tripal minor]-dev

For Drupal, the minor version number can be replaced with an asterisk. For example, for the version 0.4 release of Tripal, the devellopment branch will be: 6.x-0.4-dev.  When work begins for Drupal 7, the version could be 7.x-0.5-dev.

Task Branches

Each time a task is to be performed within Tripal, the following protocol should be followed:

  • Open an issue or bug report on the appropriate project page in Drupal.  This will allow the developer to describe the task to be performed and also generate an issue number.  The issue number is simply the node number for the page after the issue is created.
  • Create a new task branch.  The naming schema for this new task branch is described below.
  • Often comments are added to an issue to clarify a problem, indicate a bug, or provide a solution.  If a fix is made to the code within a task branch which is the direct response to a comment on the issue, the comment number should be included in the comment when committing.
  • The task branch can be pushed to the Drupal git repository as needed.
  • Once the task is at a reasonable stopping point it may be merged with the main development branch.
  • Once the task is marked closed on the Drupal website, the task branch should be deleted to keep the branch list for becoming too cluttered.

Task Branch Naming

Tasks branches should follow this naming schema:

[drupal major].[drupal minor]-[issue #]-[task name]

where:

  •     [drupal major].[drupal minor] is the same as described above for the development branch
  •     [issue #] is the node number from the issue entered into the project on the Drupal website.
  •     [task name] is a short description of what is being done without having to look up the issue number.

Bug Fixes

When fixing bugs for released versions of Tripal, the same protocol should be used as described previously for task branching however, the naming schema is slightly different:

[drupal major].[drupal minor]-[tripal major].[tripal minor]-fix-[issue #]-[task name]

Here the naming schema is the same except that the Tripal version is included in the name to indicate that this is a bug fix for a specific release of Tripal.  Also the worf 'fix' is included to easily identify this branch as a bug fix.

Release Branches

Release branches are used to store the stable code used for release.  The naming scheme for a release branch is as follows:

[drupal major].[drupal minor]-release

Here only the Drupal major and minor versions are included in the branch name. When a new release of Tripal is to occur, the main development branch will be merged with the release branch and all the release branch will be tagged with the Tripal release name (e.g. Tripal-v6.x-0.4).   When bug fixes are made and a revision is to be relased, the revision release name will be used as the  tag (e.g. Tripal-v6.x-0.4.1).

Category: