I’ll start with the PR review process, that isn’t needed. If you have multiple people with permission to push to master, then you don’t need a PR. They just push. We have two projects on my current team that are doing that plus our DBA and a developer frequently work off the same branch and just merge/push code together.

The only problems comes when someone pushes up code that is later than what you have. Well, Git has protections to say you need to fetch or pull, resolve any conflicts, and then push up. The pull process covers most of the conflicts for you, it’s only when you have modified the same file that it insists you manually resolve the issue. Of the tools, the auto-merging Git does on a pull is pretty solid and gets you 90% of the way. As it happens, we use BeyondCompare and that gets us to 99% of the way with our team.

A more formal PR is good when you don’t have developers at the same level and you want a gatekeeper. This is where small teams of highly-skilled people have more trouble, in my experience, because they grow and improve by themselves but that also makes it much harder to bring someone new in. The new person has to be almost as good to mesh. Using the PR process allows more of a gradual breaking in of developers (“good job but… don’t reformat everything”). But, as I said, you don’t have to have it and it can be introduced later (we did manual reviews over Webex for years before we decided to implement a PR process).

Their example of “when did this task come in” is a matter of philosophy. Git allows merge commits and squashes. A merge basically grafts the entire development process into the main branch but still lets you see the history until the end of time. Squash basically takes all of that task work, squishes it into a single commit, and just inserts that into the main tree. I’ve seen teams that do both. As such, our team does squash commits because I do a local commit about every five minutes because that’s the way I work. There are other team members who write it entirely before doing a single commit.

You can also track task branches by commenting on the item. We use the “#3 - Fix this issue” a lot which automatically links up to the work item/issue/task. It can be done in Gitlab, Github, Jira, and Azure without a problem. It also gives you that linkage of a specific item to a commit in history.

As for smaller OSS projects, I think the PR process is actually more important. It lets someone contribute, have the more knowledge people comment or make suggestions, and work them through getting them into the project and handle the knowledge that the highly skilled person knows because of history but no new person would be able to guess.

I’ll use my dad for an example. He was on a small team of four scientists working on a control system for various experiments. All four of them were very skilled and capable. However, every time they tried to bring on a fifth, it didn’t work because the new person didn’t have that institutional knowledge and kept breaking things that the other four instinctively knew from the ten years they had worked on it. The fact they didn’t use unit tests didn’t help, but there is a difference when your control system causes a 4 GW capacitor to blow at the wrong time so… they just decided not to include others because it was easier. In this case, having a PR process would have been better because then the other four could have done the “what about…?” or the “oh, you probably didn’t know, but putting this across the line causes the magnet control system on the accelerator ring to over-correct and then it loses the photon.” (using a real example here.)

Going direct to main (no PR) also requires a high level of trust. We already have examples of people who have put in Bitcoin miners or malicious code into critical packages. In theory, a PR process gives one more barrier to prevent the “you say this is to fix tabs, but you seem to have an entire Etherum library included too…” In small teams, you can have that trust, but that adds another barrier to overcome in bringing a new person on.

I think these scale to even smaller packages. I’ve had PRs that didn’t fit my naming conventions or style guide (increases maintenance cost if not managed), weren’t aware of side conditions, or would prevent a future plan. If there wasn’t a PR process, it would have made me, as a maintainer, have more work to either clean it up or to work around it.

Finally (sorry, essay answer), I work on four different machines and one is rarely connected to the Internet. Having the push/pull infrastructure has significantly helped me not lose work. And I use Git… a lot being that I have a few hundred repositories these days (every novel and short story is a Git repo, my accounting, my OSS projects, etc.).

I agree that the PR process is bureaucratic, but that’s not the workflow that Git was made for. It’s a workflow popularized by GitHub.

The workflow that Git was made for was “make commits” + “export patches” + “send patches”. This typically happens over a mailing list. Under this workflow, sending a contribution is a two-step process: git commit and git send-email. The recipient could be a mailing list, or it could just be the developer’s email address you grabbed from a commit message. That’s part of the reason why Git has you include your email in every commit.