Name who merged their change

A change is on the client's main branch, and the client is asking whose it is. Tonight, three proofs, in a repository the agency or the client can open. Name the account that merged it, and name the approval that account was acting on, or write that the history is a push with no review. Show that a push with no approval is refused on that branch. Then show a different person's change, one that did receive the approval the rule requires, still landing. If the name, the refusal, or the second landing requires the person who wrote the change, you do not know who is allowed to ship. You have a story about a pull request.

This is the permission on the branch. It is not the hour you spend reading the diff. Read their change before it ships is whether you opened the change and can say what it does, including a prompt or a tool. You can open a diff and still not be the account that merged it. You can be the account that merged it and not have opened the diff. The two proofs are not substitutes. It is not the digest that is running. Name the commit the client is running asks whether production's digest is the commit the pipeline built. A reviewed merge can still be the wrong digest on the cluster, and a matching digest can still have been pushed by an account the rule was supposed to refuse. It is not the secret sitting in history. Name the secret the history holds is a value a fresh clone can still resolve. Who moved the branch is a different sentence from whether a credential survived the move. It is not the license of a new package. Name the license the build added is whether a copy may ship. A license file does not name the account that clicked merge.

The study that describes who integrates a pull request, as a job, is not the Google review logs already quoted on the diff article. Do not import those medians onto this page. Gousios, Zaidman, Storey, and van Deursen surveyed integrators, the people who inspect a pull request and land it, using GHTorrent. They kept repositories that received at least one pull request every week in 2013: 3,400 repositories. A pilot emailed 250 integrators and received 21 answers, which they print as an 8% answer rate. The main round emailed integrators from the remaining 3,150 projects and received 749 answers, a 23% answer rate. 250 plus 3,150 is 3,400. 21 is not 749. 8% is not 23%. The survey was not limited to people they emailed: 35% of responses came through third-party advertising, which they found by comparing responses to the projects they had contacted. The survey ran from 14 April to 1 May 2014. Of the 749, 138 also wrote to thank them for a project report. 138 is not a response rate (Gousios, Zaidman, Storey, and van Deursen, Work Practices and Challenges in Pull-Based Development: The Integrator's Perspective, ICSE 2015).

275 of the 749 were, in the paper's clustering, project owners with more than seven years of industrial experience. The paper calls that share a third. 275 divided by 749 is the fraction they printed, and "a third" is their label for it. Do not replace 275 with 749 divided by three. Of those 275, 108 worked exclusively on the projects they answered about, which the paper calls around 40%. 108 is not 275. Around 40 is not 108, and it is not the pilot's 8. These are open-source integrators who answered a survey in 2014. They are not the contractors on a private repository in 2026, and they are not a headcount for an engagement.

What they use pull requests for is several questions, and the percents are not a pie. 80% use the pull-based model for code reviews. 80% use it to resolve issues. Those are two answers. A person can be in both, so the two 80s are not 160 and they are not one fact said twice. Half, which is the paper's word, use pull requests to discuss new features. 60% use them to solicit contributions from people with no direct commit access. Half is not 60, and neither 80 is 60. On a separate cut, of the projects that responded, 39% had received no pull request from outside the project. There is a 30% overlap between projects that said they do not use pull requests to solicit community contributions and projects that in fact received none. Another 28% said they had used pull requests to solicit contributions even though they had not received an external one. 39 is not 30 is not 28, and none of them is the 60, because the 60 is a share of integrators and the 39 is a share of projects. Only 4%, or 29 respondents, said they use pull requests for something else. 4 and 29 are their pair. Do not recompute a cleaner 4.

Review, in that sample, is also more than one sentence. 75% of the projects do explicit code reviews on all contributions. Only 7% of the projects do not review pull requests using GitHub, and the paper says those 7% specified another way of reviewing. 75 plus 7 is not 100. The 7% is not "projects that do not review," and it is not the complement of the 75. A second 75% is a different question: 75% of the integrators use inline comments on the pull request to do code reviews, and only 8% report that they use commit comments. 75 and 8 are not a partition either. Of the 7%, or 52 integrators, who review some other way, 20%, or 10, named a different tool. 10 is not 52. 20 is not 7. 42% delegate a review when they are not familiar with the code. Delegation, the paper says, is a convention, often an @-mention, not a permission the host enforces. At least 20 integrators said their project required more than one developer to review, typically two. At least 20 is not 42%. Typically two is a rule some of them described. It is not a median reviewer count, and it is not the median of one on the Google logs. That median stays on read their change before it ships. Do not quote it here as if this survey had measured it.

How the merge actually happens is a fourth set of numbers, and the paper is explicit that the platform it studied did not require an approval. "GitHub offers a more liberal code reviewing system" in which people can comment on the pull request, the code, or individual commits, "but imposes no approval process." That sentence is about GitHub as they described it, with a blog post they accessed in July 2014. It is not a description of a setting you can turn on now. In 79% of the cases, integrators use the GitHub web interface "often or always" to merge. Only in 8% and 1% of the cases do they resort to cherry-picking or textual patches. 79 is not 8 is not 1. "Of the cases" is their phrase for those answers. It is not a share of pull requests they counted in this survey. 4%, or 28 respondents, mentioned rebasing, including squashing and replaying commits onto the target. 28 is not 29. The other 4% was the "something else" question. Two fours, two integers, neither is a force-push on your client's branch. Some integrators also let continuous integration merge, or ran a script. A green build that merges itself is an account. Name it, or you have not named who merged.

The control that can refuse the unapproved push is a later setting, and it is off until someone turns it on. GitHub's current documentation on protected branches says you can require that all pull requests receive a specific number of approving reviews before someone merges into a protected branch. If you enable required reviews, collaborators can only push changes to a protected branch via a pull request approved by the required number of reviewers with write permissions. By default, a branch protection rule disables force pushes and prevents the branch from being deleted. Also by default, the restrictions do not apply to people with admin permissions, or to custom roles with the bypass permission. A separate setting, which the docs title as not allowing bypass of the above settings, is how those restrictions get applied to admins. Leaving that off means an admin push is not evidence the rule is missing. It is evidence you have not looked at the bypass (GitHub, About protected branches).

Two optional switches change what "approved" means, and neither is implied by the word. You can dismiss stale approvals when new commits affect the diff. GitHub records the diff at approval, and if the diff changes, the approval is dismissed and the pull request cannot merge until someone approves again. You can instead require that the most recent reviewable push be approved by someone other than the person who pushed it. The docs say that with this option, stale reviews are not dismissed, and the pull request stays approved as long as someone other than the last pusher has approved. Those are different rules. An approval of Monday's snapshot is not an approval of Tuesday's push when the first option is on. When neither option is on, an old approval can still be the approval the rule accepts. Write down which one you checked. The docs also say only a single branch protection rule can apply at a time, and that this restriction does not apply to rulesets. A ruleset is a different object. If the repository uses one, the branch-protection screen is the wrong screen, and a passing check there does not describe the rule that is actually evaluating the push.

The error the docs print, when someone tries to merge with pending or rejected reviews, is their example, not your log. It reads as a protected-branch update failed for the main ref, and then that changes have been requested. They label that sample GH006. Quoting GH006 in a status update, without the refusal from this repository, is a citation. It is not the proof. The same page says that if a reviewer requests changes, that person must approve before the merge, and that someone with write permissions can dismiss a blocking review. A dismissed review is a second event. Name who dismissed it. Restricting who can push is yet another switch, available on some plans, and the docs say people and apps with admin permissions are still always able to push when that restriction is the one you turned on. Read that beside the bypass setting, not instead of it. An allow-list that quietly keeps every admin is not a list of who can merge. It is a list plus an exception you have not written down.

Do the three proofs on one change that is already on the default branch. First, the account. Open the merge commit, or the push event, and write the account, the time, and the pull request it closed, if there was one. A bot that merged because checks passed is an account. "The team" is not an account. If the history is a direct push and the pull request is missing, write that, and do not invent a review. Second, the refusal. With an account that is not on the bypass list, push a commit that has no approval. The host refuses it. If the push succeeds, the rule is not what you were told, or the account you used is allowed to ignore it. Name which. Third, the other person. A second change, by someone else, that has the required approval, still merges. If it does not, you locked the branch. Locking can be the right emergency. It is not the same proof as a required review. If the second change merges with no approval, you did not test the rule. You tested that the branch accepts writes.

Three moves feel like the proof and are a second problem. A comment that says looks good, from the author, counted as the required review. The docs allow you to require that the latest push be approved by someone other than the person who pushed it. If you have not turned that on, the author's approval can be the only approval, and you should say so rather than call it a peer. A screenshot of a green check from last week, after new commits, when stale dismissal is on. The check is about a diff that is no longer the diff. And treating the 2014 sentence, that GitHub imposes no approval process, as a reason not to look. That sentence explains why a repository can still be open. It does not describe a repository where the requirement is already on. The Google median of one reviewer is the neighboring article's fact, about one company's logs. It is not a setting, and it is not permission for the subcontractor to be the only account that can push.

What a repository you can search looks like, as a product, is not a record of who approved a commit. Haystack is one search layer across documents, data lakes, and repositories. The shape that matters here is that a change in a repository can be found again after the author has closed the laptop. That case is not a merge policy. Nothing in the description is a headcount, a duration, or a result figure. If the only trail is a chat message, you cannot do these three proofs, and search will not invent the account.

There is a version of this question where hiring the path is the wrong purchase. The work is not sold, so there is no client branch to stand behind. The client has asked to meet the people writing the code. That is a disclosure decision, when to tell a client you subcontract, not a merge rule. The room only has a slide. There is no branch. The buyer only wants a template of a branch-protection screen. A template does not refuse a push. Or the buyer wants a legal opinion about who is liable for a merge. Hire the lawyer. A settings page does not answer that.

When the change is real and the host cannot name an account, the missing object is specific. A rule, on the client's default branch, that names who merged, refuses an unapproved push from an account that cannot bypass, and still accepts a different person's approved change. A white label software development partner that expects this will put the repository where you can open that rule before the first week is billed. One that can only offer a username in a standup is telling you who holds the branch. Where the next slice is a single capability, an AI integration sprint is the shape that can include the three proofs in the definition of done. If you do not yet know which host the client's code lives on, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a review median, and they are not a rate.

An address you can leave off a campaign, and a user message that replaced an instruction, are different stops: show the unsubscribe they sent and when the user rewrote the rule. Do not record either on this page. A mailing list is not a branch. A prompt is not an approval.

The owner a file records is a different object from the account that merged: who owns the file they changed. A merge by a person you trust does not say the file's rule named that person. An approval is not a CODEOWNERS line.

The check that had to pass before that account could merge is name the check the merge required. A person is not a status. Before you tell the client the change is theirs, do the three proofs and write the account. Name who merged. Show the unapproved push fail. Show someone else's approved change still land. Do not treat a comment as a permission, and do not borrow a median from a paper about a different company. The diff is how you know what shipped. The refusal is how you know who was allowed to ship it.