All Collections
Git Integration
Feature Branching Configuration
Feature Branching Configuration

How does Behave Pro's Feature Branching configuration work?

Alan Parkinson avatar
Written by Alan Parkinson
Updated over a week ago

The Git Connector in Behave Pro will commit any changes (create, edit and delete) made to scenarios and features within Jira directly to the teams git repository. It will also synchronize any changes to scenarios and features pushed to the repository back into Jira. This allows Product the owner to continue to collaborate using BDD without having to have knowledge about Git or the team branching practices.

What makes Behave Pro unique amongst BDD tools is it natively understands common branching strategies so branching doesn't have been decided by the user. One of the most common branching strategies is Feature branching, so how does Behave Pro work when the git connection is configured to use this strategy?

What branch will Behave Pro commit to?

When Behave Pro is trying to commit changes to scenarios or features it will look for an existing feature branch to commit too. Behave Pro follows the same rules for branching name as Jira; a branch name that starts with the issue key followed by a description separated by dashes e.g. BPRO-1908-the-issue-summary. If Behave Pro can't find a matching branch it will create a new branch following the naming convention.

Once Behave Pro is using a feature branch for a particular Jira Issue, it will only use that branch for committing and publishing changes. If you were to create a second feature branch using the same issue key, Behave Pro will not try to commit to the new branch.

The Requirements Page

The Requirements page in Behave Pro is the central location to see all the documentation, features, and scenarios for your software project. When feature branching is enabled the requirements page will be in read-only mode, and you won't be able to create, edit, or delete scenarios and features on this page. Changes can only be made from Jira Issues because the issue keys are used to identify feature branches.

The features and scenarios displayed on the requirements page are from the repositories base branch, typically the master branch. This can be considered as completed or 'done' work as the feature branches are merged into this branch. Features and Scenarios that are located only on feature branches will not appear on the requirements page.

Did this answer your question?