Pushing to main still needs a process

Pushing directly to main tells you where a change lands. It doesn’t tell you how carefully someone checked it.

A developer can review a small diff, test the affected flow, and push it directly. A team can also open a pull request and merge it after barely reading the description.

When I look at another team’s workflow, I want to understand what happens around that final Git operation.

Small changes make the conversation easier

Amp’s How We Build page describes keeping changes small enough to test and revert, and making the person who merges responsible for the result.

That gives me more useful information than a claim about shipping quickly. I can ask what a small change looks like, how it gets verified, and what happens when it breaks.

It still wouldn’t tell me every detail of the team’s access controls or internal review process. A public description of a development culture is only part of the picture.

For my own projects, I would start with a concrete example. Suppose a change lets people archive a saved article. Before it lands, I want to see what happens to ordinary search, archive search, and restoration. Whether the diff reaches me in a pull request or a local checkout, those behaviors need checking. The interface you use to make the change doesn’t settle that. I wrote about it in What changes when you stop opening the code editor?.

The drawing follows a change from its author to a running application. Being allowed to push is one part of that path. Checks and a record of the deployed revision provide different information.

Access needs an explicit answer

Who can update the production branch? Which credentials can deploy it? Can an unattended agent do either?

I would answer those questions before giving more tools write access. A workflow built around a developer reading every change can behave very differently when an agent starts pushing while that developer is asleep.

GitHub’s branch protection documentation describes controls for required checks and restrictions on branch updates. The rules you enable, including any bypass permissions, determine what the repository enforces.

An instruction to an agent and a repository rule can serve different purposes. I would check both rather than assume a written preference prevents an unwanted push.

A report doesn’t describe every development detail

SOC 2 sometimes enters these discussions as shorthand for having a serious process.

The AICPA describes SOC services as assurance reporting about controls. Its SOC 2 materials concern controls relevant to areas such as security and availability.

That description alone doesn’t establish whether a particular team’s direct-push workflow meets the commitments and controls examined in its report. I wouldn’t infer either approval or failure from the branch name. You would need the actual scope and relevant controls to assess that organization.

For a developer choosing a workflow, the practical questions remain concrete. Can you trace a production change to its author? Can you show which checks ran on it? Can someone change the checks or bypass them without that action becoming visible?

Plan for a bad change too

Even a reviewed change can fail.

I would want the deployed revision recorded and a recovery path I understand. Reverting code may restore a page, but it won’t necessarily reverse a database migration or recall an email already sent.

That is a reason to give different changes different treatment. A text correction and a billing change don’t need identical review, even if both eventually update main.

Before copying another team’s workflow, try describing one recent change from request to deployment. Identify who checked the behavior and what you could recover if it failed. If any part is unclear, improve that part before deciding whether another branch would help.

Want me to talk about your product? You can sponsor this site.