Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-17710

Gitflow Workflow unable to merge hotfix/ and/or release/ pull-request to both master and develop

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      A problem I am facing and a problem I am seeing others face is the inability for a 'hotfix/' branch to be merged to master and develop branches. I have seen many an unanswered StackOverflow question about this same issue.

      Many companies, including my own, use the git-flow or GitFlow WorkFlow (Atlassian Documentation). This requires that a hotfix is created based on the master branch and be merged back into the master and develop branch.

      Atlassian documentation on the matter alludes that this feature exists. See, Making a Pull Request - Tutorial, specifically the section titled: "Gitflow Workflow With Pull Requests". It describes exactly, and correctly, how the workflow should work. I can not find this feature anywhere in bitbucket.

      If it exists and I can not find the feature - I apologize, please point me in the right direction.

      Otherwise, a more succinct version of my request is:

      • When a branch is prefixed with either of the following prefixes it should be merged to master and then develop branch.
        • hotfix/
        • release/
      • Should only happen if you have the branching workflow enabled for your repository

      Please feel free to reach out to me with any other questions.

            [BCLOUD-17710] Gitflow Workflow unable to merge hotfix/ and/or release/ pull-request to both master and develop

            +1

            +1

             +1 We also need this feature.

            Deleted Account (Inactive) added a comment -  +1 We also need this feature.

            I agree with this.

            Bruce Daniel added a comment - I agree with this.

            Agreed, we need this.

            Mark Brodziak added a comment - Agreed, we need this.

            @fluthe

            If you look closely, SourceTree's GitFlow appears to be using the git-flow git extension (which is why I was pointing out with the command `git flow feature delete Test`) so in essences you are only using one tool.

            Perhaps this is the wrong place to add this request to SourceTree. Moved the request to here.

            TristenFielding added a comment - @fluthe If you look closely, SourceTree's GitFlow appears to be using the git-flow git extension (which is why I was pointing out with the command ` git flow feature delete Test `) so in essences you are only using one tool. Perhaps this is the wrong place to add this request to SourceTree. Moved the request to here.

            fkluthe added a comment -

            `..removes the GitFlow tracking status from the local System..`

            `git flow feature delete Test`

             

            This sounds like you expect Bitbucket GitFlow to work well with other GitFlow-Tools. From me, this is icing on the cake. In fact I would expect to use one or the other. If Bitbucket supports GitFlow, then i need one tool less on my machine..

            To clarifiy: 

            https://nvie.com/posts/a-successful-git-branching-model/ is the concept of GitFlow

            https://github.com/nvie/gitflow is a GitFlow tool

            https://bitbucket.org should be a GitFlow tool  

             

            fkluthe added a comment - `.. removes the GitFlow tracking status from the local System.. ` ` git flow feature delete Test `   This sounds like you expect Bitbucket GitFlow to work well with other GitFlow-Tools. From me, this is icing on the cake. In fact I would expect to use one or the other. If Bitbucket supports GitFlow, then i need one tool less on my machine.. To clarifiy:  https://nvie.com/posts/a-successful-git-branching-model/ is the concept of GitFlow https://github.com/nvie/gitflow is a GitFlow tool https://bitbucket.org should be a GitFlow tool     

            TristenFielding added a comment - - edited

            Dear Support,

             

            There might be an easy solution to this, in the "Finish Xxxx" dialog (as in Finish Feature) there are a set of options, like: Rebase on development branch etc. Just add another option called "Create Pull Request" which would pass the other options to the pull request page (so these options can be applied during the pull request stage). Then when the user clicks the OK button the pull request page is launched (almost like you get when using: Shift+Alt+P) and the dialog code clean up/removes the GitFlow tracking status from the local system. I understand it isn't perfect but at lest it is headed in the right direction.

            Edit: I notice that you track the gitflow status in .git\config. For example: if I have a feature called Test, then I would have the following added to my config file:

            [gitflow "branch.feature/Test"]
                base = dev

            So there would need to be an extra property called something like, pullRequested=true. This would allow a follow up dialog box to run something like git flow feature delete Test.

            Thus the gitflow steps change from 2 steps to 3 steps (if the pull request option was chosen). This, I think, is something we could live with.

            Any thoughts or suggestions?

            TristenFielding added a comment - - edited Dear Support,   There might be an easy solution to this, in the "Finish Xxxx" dialog (as in Finish Feature) there are a set of options, like: Rebase on development branch etc. Just add another option called "Create Pull Request" which would pass the other options to the pull request page (so these options can be applied during the pull request stage). Then when the user clicks the OK button the pull request page is launched (almost like you get when using: Shift+Alt+P) and the dialog code clean up/removes the GitFlow tracking status from the local system. I understand it isn't perfect but at lest it is headed in the right direction. Edit: I notice that you track the gitflow status in .git\config . For example: if I have a feature called Test , then I would have the following added to my config  file: [gitflow "branch.feature/Test" ] base = dev So there would need to be an extra property called something like, pullRequested=true. This would allow a follow up dialog box to run something like  git flow feature delete Test . Thus the gitflow steps change from 2 steps to 3 steps (if the pull request option was chosen). This, I think, is something we could live with. Any thoughts or suggestions?

            Yes, this is absolutely a needed feature. With proper branch permissions the only way to do gitflow with PRs now is to create two PRs for each hotfix, one for develop and one for master.

            Deleted Account (Inactive) added a comment - Yes, this is absolutely a needed feature. With proper branch permissions the only way to do gitflow with PRs now is to create two PRs for each hotfix, one for develop and one for master.

            +1

            No reaction from Atlassian yet?

            Olivier Vanekem added a comment - +1 No reaction from Atlassian yet?

              Unassigned Unassigned
              49a4fe705f44 robertg-ld
              Votes:
              24 Vote for this issue
              Watchers:
              18 Start watching this issue

                Created:
                Updated: