Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-6907

Make the branching model of Atlassian Stash more flexible!


    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      The usage of branches and tags in combination with naming convention correspond with the development process.
      Gitflow is one of the possible solutions but it doesn’t suit to all development activities.

      We are using a model which differs from Gitflow. It is a “headless” branching modell which means that there is no master branch.
      The main reason is that we have to maintain several releases in parallel and we can’t always deliver changes in the newest version.

      Our model consists of development branches for all planned major releases as follows in this order:

      Feature branches are based on the corresponding development branches and are delivered as pull requests to Stash.
      When a feature-branch is merged, the resulting automatic merge will include only branches which are successors of the development branch to which the feature branch is merged to.

      Feature/release_2/Ticket_1234 is pushed to Stash and the Pull request is merging it to development/release_2
      Then there should be a merge to
      included in the Pull request.

      We would appreciate if the merging strategy of Stash could be configured or enhanced programmatically.
      The user could provided naming strategies for branches, comparators e.g.

      If needed then we can support the development and the prototyping of such a solution.

      If you have any further questions, feel free to ask.

            Unassigned Unassigned
            10dfe5b20cc4 Christopher Timm
            0 Vote for this issue
            2 Start watching this issue