Can Pull Tally track PRs across multiple GitHub orgs?

Pull Tally lets you browse and summarize your merged GitHub pull requests by organization, month, or personal repository. For work across multiple GitHub organizations, repository access is the boundary: signing in alone does not connect private organization repositories, and access is read-only. Treat organization-based history as a record of your merged work, not proof that every repository you have worked in is connected.

Why this matters

A performance review follows your work, not necessarily a single GitHub organization. You might have contributions in an employer’s repositories, a separate open-source organization, and personal repositories. Searching each place separately makes it easy to forget a useful contribution or mix unrelated work into one summary.

Pull Tally is built around individual developers’ merged pull request history. The useful question is not just whether you can filter by organization. It is whether the history you are reviewing covers the repositories and dates you intend to describe.

For a 2026 performance review, define that scope before writing your summary. A clean list of merged PRs helps you find evidence; it does not establish business impact or explain everything you contributed.

Can Pull Tally track PRs across multiple GitHub orgs?

Pull Tally supports browsing and summarizing your merged GitHub pull requests by organization, alongside monthly and personal-repository views. Organization-based browsing is not automatic access to every private organization. Signing in alone does not connect private organization repositories.

When your work spans organizations, keep repository access separate from the way you group the results. An organization filter describes which organization’s work you want to review. Permission determines which private repository metadata is accessible in the first place.

There are also two different tasks here: finding your delivery history and interpreting it. A merged PR is evidence that a change was merged. Its title and associated context help you remember the work, but the count alone does not explain its difficulty, importance, or outcome.

Use the approach that matches the task. Repeatedly reconstructing the same personal history calls for a history tool; checking one contribution does not require a separate workflow.

Organization history: keep access and scope separate

Suppose you are preparing a 2026 review after contributing to repositories in different organizations. Start by identifying which repositories belong in the review. Do not assume that every organization associated with your GitHub account is part of the same reporting scope.

Keep these questions separate:

• Access: Is the private repository connected with the required permission?
• Scope: Does this organization belong in the review you are writing?
• Timing: Was the PR merged during the review period?
• Meaning: What does the PR demonstrate about your contribution?

Read-only access to pull request metadata serves the history-browsing task. It does not grant permission to change repository content. It also does not make private work appropriate to share outside its intended audience.

For an internal review, repository names and PR references can help a manager verify your examples. For a job search, write an account of your contribution that respects confidentiality. Access to a record and permission to disclose its contents are different questions.

Monthly history: use the merge date consistently

Monthly browsing helps you reconstruct work in the order it was merged. That is useful when a review period is long enough that recent work crowds out earlier contributions in your memory.

For a calendar-year 2026 review, January through December covers 12 months. Use the same date boundary across every organization you include. Mixing a full year from one organization with a shorter period from another produces a summary with an inconsistent scope.

Use the merge date when you are describing merged work. A PR opened before the review period but merged during it belongs to a different date-based view than a PR opened during the period but still unmerged.

That distinction matters when you explain an ongoing project. The merged-PR history records completed merges, while your review narrative can separately describe work still in progress. Keep those categories explicit rather than trying to make one count represent both.

Personal repositories: separate them when the audience changes

Personal-repository history serves a different purpose from an employer-specific review. It can help you remember projects for a portfolio or interview, but those contributions do not automatically belong in an internal delivery summary.

For a job search, choose examples that demonstrate the work you want to discuss. An employer contribution and a personal project can both be relevant, provided you explain their context and keep confidential details out of the public version.

For an internal review, start with the repositories relevant to your role. Include outside work only when it belongs in the review’s agreed scope. A broader history is useful for recall; a narrower selection is usually easier for your reader to evaluate.

How do I review work across organizations without mixing it up?

Use a repeatable sequence that separates collection from interpretation. The goal is a traceable summary, not the largest possible tally.

1. Define scope. Write down the review period and the organizations or personal repositories that belong in it. For a 2026 review, use the same start and end dates throughout.
2. Check access. Confirm the private repository connections relevant to that scope. Signing in alone is not evidence that private organization repositories are connected.
3. Browse history. Review merged work by organization and month. Keep excluded repositories separate rather than silently changing the scope while you browse.
4. Select evidence. Choose PRs that support a clear account of what you contributed. Open the underlying records when you need context beyond a title.
5. Write outcomes. Explain the change and its significance using evidence you can support. Do not treat the number of merged PRs as a productivity score.

A useful check is to find a merged PR you already know belongs in the period. Look for that record in the scope you are reviewing before treating the history as complete. If you do not find it, check the dates, repository, organization, and access rather than immediately interpreting the gap as missing work.

Keep a separate note for contributions that do not fit a merged-PR record. Design discussions, review feedback, incident response, and coordination need their own evidence. A delivery history is a starting point for recall, not a substitute for your whole review.

Why organization totals differ

A difference between organization totals needs context before it means anything. Start with these factors:

• Repository access: Private organization repositories are not connected merely because you signed in.
• Selected scope: Different organization or repository selections include different bodies of work.
• Date boundaries: A monthly view and a full review-period view answer different questions.
• Merge status: Merged-PR history excludes work that has not been merged.
• Contribution type: PR counts do not describe design work, review feedback, or other contributions on their own.

Do not use those totals to rank the value of work across organizations. A count is a count of records within a scope. Explain the actual changes when you want a reader to understand your contribution.

Is GitHub search enough for an occasional lookup?

GitHub search is enough when you need to find a particular merged PR or review a bounded set of contributions. Search qualifiers let you make the author, organization, repository, and merge period explicit.

For example, is:pr is:merged author:@me merged:2026-01-01..2026-03-31 describes your merged PRs within that date range. Add an organization or repository qualifier using the actual organization or repository you want to review. The search does not grant access to repositories you cannot otherwise view.

The manual approach gives you control over the query. Its cost is maintaining that query and repeating the work when you need another period or organization. Pull Tally is best for individual developers who repeatedly review merged-PR history for performance reviews or job searches.

Neither approach writes a substantiated career narrative by itself. You still need to decide which examples matter and explain what happened.

How do I turn merged PRs into a useful self-review?

Start with the contribution, then attach the evidence. A list of PR titles is a useful memory aid, but it leaves your reader to infer why each change mattered.

For each selected example, record 3 fields: the change, your role, and the supported outcome. If the outcome is not established, describe the delivered change rather than adding an unsupported result. Keep the PR reference as evidence, not as the entire explanation.

A brag document for software engineers gives you a place to retain that context between reviews. During 2026, add notes while the details are fresh rather than reconstructing the whole story at the end of the year.

For a job search, rewrite the same evidence for an external audience. Remove confidential implementation details and describe your responsibilities plainly. Do not imply that a personal tally is an independent evaluation of your performance.

FAQ

One last thing

Before you trust a total, find a contribution you already know should be included. That check tests the scope you actually care about: the right repository, the right period, and accessible history.

Then write the review from the evidence, not from the tally. A precise explanation of a selected contribution tells your reader more than a larger count without context.

Related guides

• Tools for generating self-review summaries from GitHub PRs
• PR summary tools for performance reviews
• GitHub PR dashboard tools for solo developers