• Icon: Suggestion Suggestion
    • Resolution: Done
    • 5.5.0
    • Pull Requests
    • None
    • 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.

      As a developer
      I would like to have a way to quickly rebase my pull-request by pushing a button
      so that I
      find it easy to ensure I base my changes on the latest in the "to-branch"

      Detailed suggestion:

      • The rebase should be possible to initiate by pushing a button
      • If the rebase fails, inform the user that the rebase has to be performed locally. (Possibly also include what files that were in conflict)

        1. rebase.png
          rebase.png
          38 kB
        2. rebase-action.png
          rebase-action.png
          13 kB
        3. rebase-confirm.png
          rebase-confirm.png
          8 kB

            [BSERV-8252] Rebase button for Pull-Requests

            Bitbucket Server 5.5 adds a "Rebase" action to the dropdown on pull requests:

            If the rebase is completed successfully, the pull request is reloaded. We're still polishing that interaction, due to the asynchronous processing that updates a pull request's hashes in the database when they change on disk, but we feel it's better to get this functionality shipped so it can add value for those teams that use rebase workflows, rather than waiting for "perfect" polish. We feel like the current approach is still very usable, if not quite ideal.

            Further details about additional rebase actions supported in 5.5 can be found on BSERV-2874.

            Enjoy!
            Bryan Turner
            Atlassian Bitbucket

            Bryan Turner (Inactive) added a comment - Bitbucket Server 5.5 adds a "Rebase" action to the dropdown on pull requests: If the rebase is completed successfully, the pull request is reloaded. We're still polishing that interaction, due to the asynchronous processing that updates a pull request's hashes in the database when they change on disk, but we feel it's better to get this functionality shipped so it can add value for those teams that use rebase workflows, rather than waiting for "perfect" polish. We feel like the current approach is still very usable, if not quite ideal. Further details about additional rebase actions supported in 5.5 can be found on BSERV-2874 . Enjoy! Bryan Turner Atlassian Bitbucket

            My paid add-on (Bit-Booster - Rebase Squash Amend) puts a rebase button on the pull-request screen:

             

             

            Bit-Booster is smart about branch permissions, too.  The Rebase Button is automatically disabled if the from branch for the pull-request does not allow history rewrites.

            The end result is pushed to Bitbucket locally via "git push --force-with-lease" and so all hooks, permissions, and config are respected.  It doesn't circumvent anything.  It's exactly as if the user had done the rebase locally and pushed it, but more convenient.

             

             

            Julius Davies [bit-booster.com] added a comment - My paid add-on ( Bit-Booster - Rebase Squash Amend ) puts a rebase button on the pull-request screen:     Bit-Booster is smart about branch permissions, too.  The Rebase Button is automatically disabled if the from branch for the pull-request does not allow history rewrites. The end result is pushed to Bitbucket locally via "git push --force-with-lease" and so all hooks, permissions, and config are respected.  It doesn't circumvent anything.  It's exactly as if the user had done the rebase locally and pushed it, but more convenient.    

            Mikael Lepistö added a comment - - edited

            Mikael Lepistö added a comment - - edited This is also related to https://bitbucket.org/site/master/issues/6202/sync-feature-branches-via-rebase-bb-7369     And shouldn't this be closed as duplicate of  https://jira.atlassian.com/browse/BSERV-2874

            Thor Skaug added a comment -

            Yes, regardless of conflicts the merged result still needs review. But I don't know if that needs to be part of a rebase in pull request feature, as it happens anyway when there are more commits pushed to the source branch. We have chosen to use a plugin that un-approves when there are further changes.

            Thor Skaug added a comment - Yes, regardless of conflicts the merged result still needs review. But I don't know if that needs to be part of a rebase in pull request feature, as it happens anyway when there are more commits pushed to the source branch. We have chosen to use a plugin that un-approves when there are further changes.

            We, too, require that our source branches be up to date with the target before merging. That said, the question arises if this pure "rebase" action should invalidate reviews or, at least, retain the option to NOT revoke reviewer approvals for pure and clean rebase actions. If any conflict resolutions are detected, this would "change the game" for reviewers and reviewers should be allowed to decide if they want, generally speaking, to retain or revoke their reviews when pushing this proposed button.

            Matthew Korich added a comment - We, too, require that our source branches be up to date with the target before merging. That said, the question arises if this pure "rebase" action should invalidate reviews or, at least, retain the option to NOT revoke reviewer approvals for pure and clean rebase actions. If any conflict resolutions are detected, this would "change the game" for reviewers and reviewers should be allowed to decide if they want, generally speaking, to retain or revoke their reviews when pushing this proposed button.

            Thor Skaug added a comment -

            We use a workflow that requires the source branch to not be behind the target branch (that is, only fast-forward merges are allowed) when merged as part of a pull request. This forces the source branch to be rebased on the target branch before the merge.

            For our projects, the majority of the merges will be conflict free, so having a rebase feature in the Pull Request that could rebase the source branch onto the target branch IFF there are no conflicts would be very useful.

            I see this exact feature is now supported by GitLab.

            Thor Skaug added a comment - We use a workflow that requires the source branch to not be behind the target branch (that is, only fast-forward merges are allowed) when merged as part of a pull request. This forces the source branch to be rebased on the target branch before the merge. For our projects, the majority of the merges will be conflict free, so having a rebase feature in the Pull Request that could rebase the source branch onto the target branch IFF there are no conflicts would be very useful. I see this exact feature is now supported by GitLab.

            Merges should not be possible unless the pull request rebases cleanly on top of master. I could even imagine this to be automatic where pull requests would be always pinned on top of a rebased master and if that does not work anymore to mark them as stale and unmergable.

            Alper Cugun added a comment - Merges should not be possible unless the pull request rebases cleanly on top of master. I could even imagine this to be automatic where pull requests would be always pinned on top of a rebased master and if that does not work anymore to mark them as stale and unmergable.

            The merge strategies available in Bitbucket Server do not cover this case. This feature suggesting has actually nothing to do with the merge event at all. It is a feature to use while preparing a neat pull request.

            Typical use case when simple rebase is a good idea. Our developers are of course doing this, locally, already. I am only looking for a way to make development more efficient.

            Ex)
            Say I have written a new feature that is using the project custom thread class in branch "feat1". I have created a pull request, "feat1" => "develop", and all builds/tests has passed.
            During the time I worked with my threaded feature, a college has refactored the thread class (keeping interfaces compatible) and merged into our dev branch "develop".

            At this time a merge between "feat1" and "develop" is trivial, but I do not know if my new threaded feature is using quirks from the old thread class implementation. Hence it is a good idea to rebase my branch to test the new thread class implementation together with my new threaded feature.

            Fredrik Andersson (Inactive) added a comment - The merge strategies available in Bitbucket Server do not cover this case. This feature suggesting has actually nothing to do with the merge event at all. It is a feature to use while preparing a neat pull request. Typical use case when simple rebase is a good idea. Our developers are of course doing this, locally, already. I am only looking for a way to make development more efficient. Ex) Say I have written a new feature that is using the project custom thread class in branch "feat1". I have created a pull request, "feat1" => "develop", and all builds/tests has passed. During the time I worked with my threaded feature, a college has refactored the thread class (keeping interfaces compatible) and merged into our dev branch "develop". At this time a merge between "feat1" and "develop" is trivial, but I do not know if my new threaded feature is using quirks from the old thread class implementation. Hence it is a good idea to rebase my branch to test the new thread class implementation together with my new threaded feature.

            steve added a comment -

            Thanks for the suggestion - could you elaborate a bit on the types of cases you'd use this? Would you see this being selected ad-hoc, or set system wide?

            We currently support a squashed commit merge strategy as a system setting which would give you the rebase onto the target of the PR for all PR's on the system, but this is not exactly what you're after as it would affect every PR raised in the system.

            steve added a comment - Thanks for the suggestion - could you elaborate a bit on the types of cases you'd use this? Would you see this being selected ad-hoc, or set system wide? We currently support a squashed commit merge strategy as a system setting which would give you the rebase onto the target of the PR for all PR's on the system, but this is not exactly what you're after as it would affect every PR raised in the system.

              Unassigned Unassigned
              607955ea-3bfd-44e4-a615-31edeedef4ae Fredrik Andersson (Inactive)
              Votes:
              21 Vote for this issue
              Watchers:
              26 Start watching this issue

                Created:
                Updated:
                Resolved: