The Merge Request Is a Corporate Resolution

Parliamentary procedure and pull requests solve the same coordination problem: a group needs to propose, review, amend, and ratify changes to a shared body of work.

In governance, that process appears as motions, debate, amendments, votes, and ratification. In software, it appears as branches, reviews, approvals, and merges. Git adds something traditional board process often lacks: an exact audit trail of the proposed change itself.

Branches as motions

In parliamentary procedure, a motion is a formal proposal to change the state of affairs. It has a proposer. It has specific content. It exists in a pending state until the body acts on it.

When a director wants to propose a bylaw amendment in a version-controlled corporation, they don’t draft a memo. They create a branch. The branch contains the proposed changes — the specific diffs to the bylaw files, the updated governance configuration, any associated documents. The branch is the motion, rendered in precise, diffable form.

The difference between a motion and a branch is specificity. A motion says “I move that we amend Section 4.2 to allow asynchronous board votes.” A branch contains the amended Section 4.2. The proposal is the change itself, not a description of the change.

This eliminates an entire class of governance failure: the resolution that passes but is implemented differently than intended. In traditional governance, a board passes a resolution authorizing a stock option pool of 10% of outstanding shares. Then someone has to translate that resolution into cap table changes, update the equity plan, modify the certificate of incorporation if necessary, and file the appropriate paperwork. At each step, there’s room for error, delay, or misinterpretation.

In a git-backed system, the branch contains the amended cap table, the updated equity plan, and the revised certificate. When the merge happens, the corporate state changes. There is no translation step between authorization and execution.

Review as deliberation

Parliamentary debate serves two functions: it surfaces objections, and it refines the proposal. A motion might be amended, tabled, referred to committee, or withdrawn based on what emerges during debate.

Code review serves the same functions.

When a governance branch is opened for review, stakeholders can examine every proposed change in detail. They can comment on specific lines — “this vesting schedule doesn’t match what we discussed” or “this board seat allocation would violate the investor rights agreement.” They can suggest alternatives, rendered as concrete diffs rather than abstract preferences.

The review conversation is recorded. Every comment, every suggestion, every response is preserved as part of the governance history. When someone asks “why did the board change the equity plan in Q3?”, the answer isn’t buried in someone’s email. It’s in the pull request discussion, alongside the exact changes, the exact reviewers, and the exact approvals.

This is richer than minutes. Board minutes record what happened. A pull request shows how it happened, including the objections raised, the revisions made, and the final form that was approved.

Approvals as votes

In parliamentary procedure, a vote is a formal expression of each member’s position. The votes are counted. If the threshold is met, the motion carries.

In git, an approval is a signed attestation. A reviewer examines the proposed changes and, if satisfied, adds their approval. The approval is cryptographically bound to the specific version of the changes they reviewed — not a general endorsement of the concept, but a precise affirmation that these specific diffs have been examined and accepted.

When a board member votes “yes” on a traditional resolution, they’re approving a description of a change. When a board member approves a merge request, they’re approving the change itself. If the proposal is modified after their approval, the approval is invalidated and must be re-obtained. There is no ambiguity about what was approved, by whom, or when.

The approval threshold is configurable. A bylaw amendment might require approval from a majority of directors. An equity issuance might require approval from the CEO and the CFO. A routine compliance filing might require only the authorized agent’s signature. These rules are expressed in the repository’s governance configuration — code that can be inspected, tested, and enforced automatically.

When the required approvals are collected, the branch can be merged. Not before. The policy gate ensures that every corporate action meets its authorization requirements before it becomes part of the canonical record.

The merge as ratification

In parliamentary procedure, when a motion passes, the secretary records it and it becomes the official position of the body. In practice, this recording step is where errors creep in, where delays accumulate, and where the gap between decision and execution widens.

A git merge is instantaneous and atomic.

When the governance branch is merged into main, the proposed changes become the current corporate state. The cap table is updated. The bylaws are amended. The new officer is appointed. All of it, in a single commit, signed by whoever performed the merge, linked to the full history of the proposal, review, and approval process.

There is no recording step because the process is the record. The merge commit contains the changes, references the branch that proposed them, and links to the approvals that authorized them. The corporate minutes aren’t written after the meeting — they’re generated by the meeting itself.

Rejected proposals survive

In parliamentary procedure, a defeated motion can be instructive. It records what was proposed and why it failed. But in practice, defeated motions are often lost — mentioned briefly in the minutes, then forgotten.

In git, a rejected proposal survives as an unmerged branch. The proposed changes, the review discussion, the reasons for rejection — all of it is preserved, searchable, and available for future reference.

This creates an institutional memory that traditional governance lacks. When a new director proposes something similar to a proposal that was rejected two years ago, the prior discussion is available. The board doesn’t rehash the same debate. They can see what was tried, what objections were raised, and what has changed since then.

The protocol is the procedure

Henry Robert needed 700 pages to codify the procedures for collective decision-making. Git implements equivalent procedures in a protocol that any engineer already knows how to use.

This is more than a loose analogy. The structural mapping between parliamentary procedure and git’s collaboration model is precise enough to implement in code. Once governance procedures are implemented in code, the system can enforce review, approval thresholds, and merge conditions directly.

Parliamentary procedure was the best technology available in 1876 for governing collective decisions.

Git is the best technology available now.