3 ms·

So the ‘additional stage’ works exactly like a branch then, right?

• Jach 7y ago
  Except without all the benefits of having real branches that might be desirable. To me OP's flow just reminds me of a particular way of doing development with perforce. You make your changes against one branch everyone works from, move them to a new 'pending changelist', then send the diff to another system for review. (You might even use perforce's own swarm tool by making a 'shelf' of your pending changes and starting a review from that.) Rework is done, you send over the new diff/overwrite the shelf, reviewers can see diff-of-diffs (tracked only by the review tool) and overall-diff. Eventually if all is well (or if your review has been in limbo and no one's going to argue if you merge without review anyway) you commit the pending changelist. (Which might involve in reality sending your diff again to another service, and that service tries to integrate and build/run tests using a new changelist in your name and only finalizing a commit to the master branch with that.) I wouldn't recommend it. Not that I think the popular pull request model is much better, but at least you have options, though that's more to do with using a DVCS. I'd like to sometime try Fossil with a team, which aims to have the technical benefits of DVCS but with the tradeoff of cathedral vs bazaar being given back to the cathedral style, which is what I see pull requests as popularly done on github as clumsily trying to accomplish.