This guide assumes your team is already using Git and has established working and branching practices for it, and aims to help you select the correct settings for these team practices during Behave Pro setup.

There are three common branching strategies we will be covering: trunk-based, feature branching and GitFlow. If you don't know the name of the branching strategy then these questions should help you identify your strategy and the most appropriate settings. Ask the development team if you are unsure about these questions.

If you are still unsure we provide more detailed information in the next three sections.

Trunk-based development is a strategy that uses no branches, all changes are committed directly to the main branch. The main branch is typically called master, trunk, or main. The standards of the team's practices around test automation and code quality are particularly high for this approach to work.

When Behave Pro is configured to use Trunk-based development it will work in the following way. When you create or edit a scenario it will commit the change directly to the base branch (master) and will not create a separate branch. If you have any branch rules configured that blocks commits directly to the base branch (master) then Behave Pro might not be able to save the changes.

After selecting your organization and git repository, choose feature branching under Branching Strategy

Select the master branch from the Branch field and enter a directory path if required before clicking finish.

In feature branching instead of committing directly to the base branch, often called master, a new branch is created and all the work is committed to the new branch. When this work is completed it is then merged back into the master branch using a merge command or more commonly a Pull Request.

When Behave Pro is configured to use Feature Branching it will work in the following way. When you create or edit a scenario it will look for a feature branch for the current Jira issue and commit the scenario changes to that branch. If a feature branch doesn't exist for the Jira issue then Behave Pro will create one for you and commit the scenarios changes there. This means Behave Pro is following the same rules and working practices as developers and testers, no special provisions are required.

After selecting your organization and git repository, choose feature branching under Branching Strategy

Select the master branch from the Branch field and enter a directory path if required before clicking finish.

Gitflow is closely related to feature branching and is a fairly popular branching strategy for teams who ship software to customers in versioned releases, possible after every sprint, rather than deploying/shipping every change immediately (Continous Delivery or Deployment).

Gitflow differs from feature branching because there are two important branches: master and develop, with develop being branched from master. In Gitflow when somebody starts work on a Jira Issues they create a feature branch just like in Feature Branching but instead of creating the branch from master, they create it from develop and merge it back into develop once the work has been completed. This merge back to develop could be a git merge or a Pull Request.

After selecting your organization and git repository, choose feature branching under Branching Strategy

Select the develop branch from the Branch field and enter a directory path if required before clicking finish.

There are many other branching strategies used with Git and if we haven't covered yours then start a support conversion using the widget on the right. Provide plenty of details about your strategy and we would be happy to make recommendations on how to configure Behave Pro.