Pull request workflow - changes post review and multiple heads
Sean Farley
sean at farley.io
Mon Jul 6 21:06:28 UTC 2015
Jaikiran Pai <jai.forums2013 at gmail.com> writes:
> Hello everyone,
>
> We have a workflow within our team which is as follows:
>
> - There's an "upstream" repo "foo" which is shared by the team. Only
> select members have push access to it
> - There are N developers in the team, each one working against a forked
> copy of the upstream repo, under their own account.
> - Each of them commit to their own repos and issue a pull request once
> they have their feature/bug-fix ready for review.
> - A reviewer goes through the commit "A" in the pull request and
> suggests any changes that are needed
> - The developer then fixes those issues in the pull request and adds a
> new commit "B" to the pull request.
>
> What we ideally want to do is "fold" A and B into one commit and have it
> pushed to the "upstream". It's straightforward to ask the developer to
> fold those 2 commits and *force* push the changesets to this own repo
> (which by the way isn't shared). The force push is needed since the fold
> ends up creating a new head. Of course, the (redundant) head can then be
> manually closed via a "hg commit --close-branch" but is there a better
> way of dealing with this? Perhaps auto-closing the redundant head while
> dealing with the fold?
>
> The end goal we are trying to achieve is having the commits from most of
> the developers come through via pull requests and once the changes are
> reviewed and approved, have them committed as one (in most cases)
> logical commits.
This is one of the goals of changeset evolution, so in a future world,
this use-case will be taken care of. Out of curiosity, is this repo on
Bitbucket?
More information about the Mercurial
mailing list