Reverse Pull-Requests

This is the worst process I&#x27;ve probably ever seen. Only one person (or pair) can work on the code (in main) at a time for this to work. It&#x27;s more effort than just making a branch and merging it to main, and it buys literally nothing.<p>What is wrong with just creating feature branches and PRing them to main? It&#x27;s literally the default workflow.<p>Then when you merge to main you run the CI&#x2F;CD just like this, but without having to go back and create a &quot;snapshot branch&quot; of main before you started. Also, as you scale you almost certainly have commits from multiple people in main by the time you do this breaking the whole &quot;reverse PR&quot; process.

Why do people try to come up with these byzantine git workflows?<p>&gt; However, what was missing was wider visibility of changes being applied to the code.<p>That is what is said to have been missing. The solution was not to use tags or feature branches, gitk or other visualization tools that could easily show changes being applied to code from any point to any other point. It was to make up this &quot;reverse pull request&quot; Rube Goldberg scheme.

This idea is ahead of it&#x27;s time.<p>By which of course I mean that I expected it to take a few more years before a new generation forgot where we all came from to arrive at git, and reinvents cvs for no other reason than to work the opposite of git, because by then git will be old and whatever is the opposite of something old is new and &quot;progress&quot;.

Just reading this article made me nervous.<p>More microservices than programming pairs.<p>Deploying straight to production.<p>Maybe I just like the old school simplicity, but this seems like a terribly convoluted process, to justify some sense of development momentum that people seem to be addicted to.

I’m not entirely sure if I got this right, but this system sounds a bit … weird. Everything is “tested” in production and then, at some arbitrary time, another team does a code review of the code that’s already in production and possibly broken? It just seems completely backwards.

Do people really want to work in pairs all the time? I feel like it would get tiring if not just an occasional thing. There&#x27;s also value in being able to be an &quot;individual contributor&quot;

This has one glaring problem (only works for one feature). The article mentions it, says “wasn’t a big problem for us” and that’s it.<p>The real solution might be to create an after the fact feature branch and <i>cherry pick</i> all the relevant changes. That has some risk of breaking under high churn, but the feature branch doesn’t even need to build or pass tests, only convey a design, I suppose.<p>But in the end: why not just use feature branches? As soon as the number of developers become big enough to worry about passing knowledge around, waiting 12 or 24h for changes to land in master is a tiny nuisance compared to broken master builds or reverse PRs.

You could merge PRs branches (not PRs itself) into a shadow-master branch. Every push to any PR creates a fresh shadow-master with selected (labeled) PRs&#x27;s <i>branches</i> merged. We call this an acceptance branch. Each acceptance branch could have its coresponding staging server.<p>You could have several acceptance branches with different PRs merged. Each PR can be included&#x2F;excluded (labeled&#x2F;unlabeled) back and forth from the acceptance branch (get a fresh one on every label attach&#x2F;detach)<p>That&#x27;s what companies I worked with do. And I even built a SaaS app for that, though they don&#x27;t want to publicly advertise the app.

This looks like a try in recreating audit workflow (in a bit overcomplicated way).<p><a href="https:&#x2F;&#x2F;secure.phabricator.com&#x2F;book&#x2F;phabricator&#x2F;article&#x2F;reviews_vs_audit&#x2F;" rel="nofollow">https:&#x2F;&#x2F;secure.phabricator.com&#x2F;book&#x2F;phabricator&#x2F;article&#x2F;revi...</a><p>Yeah, I do miss Phabricator :(