gitreflow doesn't seem to work well with BitBucket's pull request

[tanin47]

So, if we use it, BitBucket's pull request won't be closed because gitreflow merge the pull request manually into master. After master has the new change, the pull request will become empty.

I think the workflow can be changed to:

Assuming we want to merge the branch A into master.

1. Squash all commits in A into a single commit and force push. The pull request on Bitbucket will reflect this change.
2. Use BitBucket API to merge (instead of merging manually)

In this way, we won't have an empty pull request.

I understand this might be a lot of work though.

(This workflow works for Github as well.)

[codenamev]

So BitBucket's API is less than ideal to work with for closing out pull requests (see here for an update on where squash-merge stands).

I do like the clever workaround you've come up with, but it's still just a workaround. Some other git workflows prefer a rebase in favor of a squash-merge for the final delivery of the feature branch (see here for why we prefer to squash-merge). The reason we don't do this is to avoid a force-push to master. While force-pushing a feature branch isn't necessarily dangerous, we'd like to avoid it.

I think we'd rather wait for support from BitBucket's API then implement a work-around that would impact our process. If you'd like to implement this as a flag option I think we'd pull it in (@nhance thoughts?).

[nhance]

Sure, I think we could support this in a flagged option. Our paranoia is around developers throwing --force into a normal daily workflow and becoming numb to the danger inherent in it.. as long as it's hidden away behind a tool like reflow, it removes that danger IMO

[codenamev]

marking this as a TODO to add --squash to the review command for cases like this