The review they’re talking about here comes later, as a way of keeping the team in sync. It’s not the main code review mechanism.
We operated this way back in the day building Canv.as and DrawQuest but without the snapshotting, that's a nice development
Wish more teams would explore this type of development. Everyone is stuck in the git kernel dev model practices. It probably sounds weird because it's unusual, not because it's a DevOps bad practice (it's quite on the leading edge).
My understanding and experience with "pairing" is that it pretty much has to be synchronous because generally at least two people should be looking at the same screen while generally one is providing inputs (mouse, keyboard) and the other is providing high level guidance and looking out for low level mistakes.
Doing it asynchronously seemingly would not dispense with sharing the screen and one person handling inputs which seems like it would be even less efficient.
What is wrong with just creating feature branches and PRing them to main? It's literally the default workflow.
Then when you merge to main you run the CI/CD just like this, but without having to go back and create a "snapshot branch" 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 "reverse PR" process.
You could have several acceptance branches with different PRs merged. Each PR can be included/excluded (labeled/unlabeled) back and forth from the acceptance branch (get a fresh one on every label attach/detach)
That's what companies I worked with do. And I even built a SaaS app for that, though they don't want to publicly advertise the app.
> Merged results pipelines can’t run when the target branch has changes that conflict with the changes in the source branch.
Yeah, the app I built even use git's `rr-cache/` (rerere feature) and have gui for resolving conflict and marking it as resolutions. Pretty neat.
> However, what was missing was wider visibility of changes being applied to the code.
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 "reverse pull request" Rube Goldberg scheme.
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 "progress".
More microservices than programming pairs.
Deploying straight to production.
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.
The real solution might be to create an after the fact feature branch and cherry pick 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.
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.
https://secure.phabricator.com/book/phabricator/article/revi...
Yeah, I do miss Phabricator :(
