Scenario:
Author 'Alice' creates a pull request from Branch A -> master, the pull request contains 50 commits from 'Alice' as well as others. When 'Bob' merges this pull request after review using the squash merge into master, history in git shows that 'Bob' is the author of the changes which were merged. Merge is final part of the review and is generally done in 1 go.
How can 'Bob' do review and merge the changes and preserve both 'Alice' and his names in the pull request and git history? Microsoft TFS has a nicer option to see who was the committer and the approver of the pull request in GIT history - committer is the creator of the pull request.
Quick answer: use fast-forward-merge instead of squash-merge, and do the squash ahead of time so that you can control the metadata to suit your needs.
Try our Bitbucket Server add-on, Bit-Booster - Rebase Squash Amend, to carefully run the squash separate to the merge. It puts a "squash" button right on the PR screen, and the squash dialog lets you choose the "Author" metadata for the squashed commit. After squashing you would then hit the "Rebase" button, since a squash-merge is identical to a squash + rebase. The final step is to use the "Fast-Forward" merge strategy in Bitbucket - so you'll need a repo, project, or global admin to adjust the config to make sure that's available to users.
Our "squash" operation (as implemented by this Bit-Booster plugin) will store the current Bitbucket user clicking the button as the "Committer" metadata inside the commit object.
The nice thing about the "Fast-Forward" merge-strategy is that it merges whatever you've got exactly as-is. No additional commit objects are created, and the existing commits are left alone (since they are immutable).
Good luck!
If you want to enforce a mandatory squash and fast-forward policy, our free Control Freak add-on can do that (but you still need to adjust Bitbucket's merge-strategy to allow the fast-forward merge).
Thanks G. Sylvie Davies for your detailed solution. I will have a look at FF merge now, but it is not the same as Squash commit, it would preserve all the commits. I would be more interested in a Squash merge using an out of the box solution from bitbucket.
Best regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you pre-squash + rebase first, then do the merge using the "--ff-only" strategy, the end-result of these operations is identical to a squash-merge.
It can all be done via command-line git, too, of course, which is cheaper than buying a paid plugin.
Example (to squash a topic that branched from master):
git checkout topic
git reset --soft $(git merge-base HEAD master)
git commit -m 'squash' --author 'Original Author <name@email.com>'
git rebase master
git push --force
But personally I find our paid plugin (Bit-Booster - Rebase Squash Amend) much easier to use in this situation and less error prone. We also auto-generate a better commit message for the squashed commit, which can be further edited in the squash dialog.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I see what you mean, that looks like a good solution. The plugin also seems to do exactly what is required here. Thanks G. Sylvie Davies.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.