The cost is real though and the flow isn’t necessarily optimal for in-house teams, other things might work better: post-push review, pair programming with no review or mob with no review, or just straight up no review.
Conversation
Replying to
Hmmm the thing is I feel that review makes it easier to pass on knowledge. Granted pair programming does that as well.
But I may just have been lucky with people I have worked with 😅
1
Replying to
Moving review to the “end” makes feedback come late, sometimes even too late. Having feedback early is extremely valuable, or even after. But that is very hard to do in this process. Also having early feedback be private can also be a feature.
4
17
85
This Tweet was deleted by the Tweet author. Learn more
There is still a lot you can do remote in a trust context, early and iterative feedback, pairing, mobbing, post-push review
1
8
This Tweet was deleted by the Tweet author. Learn more
PR isn’t really the right format for early rough ideas or experiments or “thinking out loud”, they are more a delivery mechanism. So having a review tool that is distinct from “push to main” that allows a more collaborative process would be better imo.
2
3
9
I really like Gerrit because it makes everyone feel as if they have commit access, even if they don't, because everyone just does `git push origin HEAD:refs/for/master` from their feature branch and has a branch in the main repository and a nice way to review / approve it.
1
2
You have people with approval access, and your choice of system for it, which could just be 1 approval including by the person who submitted it. Then, ideally, you have a nice CI bot that quickly tests + merges it within a couple minutes. Encourages linear history + always green.
1
This Tweet was deleted by the Tweet author. Learn more
Someone without commit access can't push to the main repository on GitHub. They have to make a remote fork of every project where they contribute. Even with commit access, you manage remote branches yourself.
It also can't properly handle rebasing proposed changes even in 2021.
CI really doesn't work well there. The review interface is also really bad aside from getting completely screwed up by rebasing. They really should have adopted Change-Id and not been against the culture of requiring a sensible set of commits split up logically before applying.
1
For a long time, they actually actively sabotaged the review interface if you used that approach instead of keeping the whole history of the feature branch.
They took an opinionated approach which was against how Git was actually designed / intended to be used by the developers.
1
Show replies