Add and edit branches

Tip: Add and edit branches using the ALI Configuration wizard while configuring a related build job (recommended), or manually as described below.

If you are configuring branches manually, it is still recommended to start by configuring a related build job, as described in Add and edit build configurations.

  1. Click Configuration > Product > Code.
  2. Do one of the following:

    • To add a new branch: Select a repository, and click Add SCM Branch.

    • To edit a branch: Expand a repository, and click a branch.

  1. On the SCM Branch page, set the following branch properties:

    Path

    Last Change Read

    Locking Policies

    Branch

    Check-in Policies

    Release

    Application

    Path

    Perforce: Set the branch path without the Depot name. For example, if the branch is located at //depot/HelloWorld/releases/release-1.0/... then the path should be /HelloWorld/releases/release-1.0.

    TFS: Use the branch path to the project path without a leading $. For example, if the project is located at $/TestApp, then the branch path should be /TestApp.

    Note: Branch paths can contain sub folders.

    Git: Always set the branch path to /.The field name should be set to the real Git branch name.

    Note: After entering a value, click Validate Configuration to test the link.

    Branch

    CVS: A branch name only has meaning for some CVS repositories. Do not fill this property for SVN.

    Perforce: Do not use this field even if the branch is named.

    Git: Use only the simple branch name in the format master, and not refs/head/master.

    Note: After entering a value, click Validate Configuration to test the link.

    Last Change Read

    CVS: The date-time stamp for which the change sets are read.

    SVN: The last revision number for which change sets are read.

    GIT: The commit hash (revision), space, and branch name.

    Example:
    Master 00988ff4a833eea670feab6bcbcf5ed93f9add77 master
    A branch named 2.10 a12a5d41b0fba9934e9569cbae87e61599373ea2 2.10

    Note: Populate this field when creating a new branch to read changes only starting from branch creation. Leaving this field blank will include all changes starting from the beginning of the master/HEAD branch.

    Check-in Policies

    • Commit message must match defined pattern. Causes commits for which the commit message doesn’t match the predefined pattern to be refused by the agent.
    • Change Set refers to a user story. Enforces that every commit must refer to a user story. Optionally, set the priority levels user stories must have to allow users to check in associated changes.
    • Change Set refers to a defect. Enforces that every commit must refer to a defect. Optionally, set the severity levels defects must have to allow users to check in associated changes.
    • Add this note to the System message when Commit is blocked. Sends custom system messages that inform a user when a commit is blocked with the applied note.

    Note:  

    • Check-in policies require the installation of an agent in order to function. For details, see SCM agents.
    • Check-in policies do not work on Git repositories.

    Locking Policies

    Disallow commits except for the following. disallows all the commits coming to the given branch other than the following exceptions:

    A list of users allowed to commit to the branch can be specified though the branch is locked by applying the user name(s) of SCM users who are permitted to commit.

    A list of defects specified for which committing changes are allowed is created by clicking Add and providing the ID of the defect. Defects are removed from the table by clicking Remove.

    Add this note to the System message when Commit is blocked. Sends custom system messages that informs a user when a commit is blocked with the applied note.

    Note:  

    • Locking policies require the installation of an agent in order to function. For details, see SCM agents.
    • Locking policies do not work on Git repositories.

    Release

    You can associate a branch with multiple releases. Click Add and select the releases.

    The start and end dates of the releases are taken from the release settings. You can change these manually in the grid.

    Change sets from the branch are associated with a release during the time period specified for that release.

    Application

    Select the application with which the branch is associated.