Can Pull Tally generate a yearly summary of my GitHub activity?

Pull Tally supports building a yearly summary from your merged GitHub pull requests by browsing and summarizing monthly history, with organization and personal-repository views. That is a record of merged PRs, not your entire GitHub activity or a finished annual performance review. For a 2026 summary, use the monthly record as evidence, then add the context and outcomes that pull request metadata does not explain.

Why this matters

When you prepare a performance review or job search, remembering the work is often harder than explaining it. A repository list tells you where you worked; merged pull requests help you find the specific changes behind that work.

Pull Tally is best for individual developers who want to replace repeated searches through their merged GitHub pull requests. Its role is to help you browse and summarize that history, not judge your productivity or supply outcomes that the repository record does not contain.

Use the PR history to recover evidence, then write the annual account around what changed and why. That distinction keeps a useful record from becoming an unsupported claim about your impact.

Can Pull Tally generate a yearly summary of my GitHub activity?

You can build a yearly account from the tool's monthly merged-PR summaries. Keep the scope explicit: a summary of merged pull requests is narrower than a summary of all GitHub activity, and monthly browsing is not the same as an automatic annual-report feature.

For a full calendar year, the coverage period is 12 months. If you are preparing your 2026 review before December ends, label the document as year-to-date and state the cutoff date rather than presenting it as a completed year.

These approaches serve different parts of the task. Monthly browsing recovers the record; search checks a specific slice; the written document explains what that evidence means.

What belongs in the yearly summary?

Start with merged PRs that explain meaningful work, rather than copying every title into a long list. Group related changes under the project, problem, or responsibility they support.

For example, several merged PRs might belong to the same migration. Present the migration as the main item, then attach the relevant PR references as evidence. Do not describe each PR as a separate achievement when the work is better understood together.

Keep maintenance work visible, too. Fixes, dependency changes, and internal cleanup can belong in the account when you can explain their purpose. A small change does not need a dramatic business claim to deserve an accurate description.

How do I turn monthly PR history into a yearly summary?

Build the document in a consistent order so you do not mix evidence collection with self-evaluation. The following workflow works for an annual review, a year-to-date check-in, or preparation for interviews.

1. Set the scope

Write down the reporting period before you browse. For a completed 2026 calendar-year account, that means January through December; for an earlier review, use the actual start and cutoff dates.

Then decide which organizations and personal repositories belong in the document. A performance review and a job-search preparation document can have different scopes. Keep those boundaries visible so a reader knows what the summary includes.

2. Browse monthly

Move through the selected months in order. Use organization or personal-repository views to keep unrelated work from being mixed together.

Record candidate PRs without trying to make every entry sound impressive. At this stage, the task is retrieval: find the changes you would otherwise have to search for repeatedly. Preserve enough identifying information to return to each PR when you draft the explanation.

3. Group changes

Combine related PRs under a short, descriptive heading. Use the problem or project as the organizing principle, not the number of pull requests.

A useful grouping answers a practical question: what work would a reviewer understand better if these changes appeared together? Keep unrelated fixes separate, even when they happened in the same month or repository.

4. Add context

For each group, explain the problem, your contribution, and the evidence supporting the result. These are 3 useful evidence fields, not a scoring system.

Separate what the PR proves from what you know through other records. A merged change supports a statement about implementation. A claim about adoption, reliability, or customer impact needs evidence appropriate to that claim.

5. Check boundaries

Read the draft for scope, attribution, and confidentiality. Confirm that each example belongs in the reporting period and that your wording distinguishes your contribution from the team's work.

For a job-search version, remove private repository names, customer information, and implementation details you are not authorized to share. Keep the explanation useful without copying confidential material into an external document.

Why does the yearly summary vary?

The usefulness of an annual account depends on its boundaries and explanation, not just the size of the merged-PR list. These factors change what the document represents:

• Reporting period. A full-year document and a year-to-date document cover different windows. State the dates instead of leaving the reader to infer them.
• Repository scope. Organization work and personal-repository work answer different questions. Include the repositories relevant to the review or job-search purpose.
• Access. Private organization repositories are not connected simply because you sign in. Do not assume an account login establishes complete coverage.
• Unit of work. A project can span several PRs. Group related changes so the account describes the work rather than treating each merge as equivalent.
• Supporting context. PR metadata helps recover the change history. Your explanation and other permitted evidence establish why a selected change mattered.

For your 2026 document, put the reporting period and repository scope near the top. That small editorial choice makes the rest of the summary easier to interpret without overstating its coverage.

What does read-only access mean for my PR history?

Pull Tally uses read-only access to pull request metadata to support browsing and summaries. Signing in alone does not connect private organization repositories.

Treat those as separate questions: what data the tool reads, and which repositories are connected. Read-only describes the access mode; it does not mean every organization repository is included in your personal history.

Before relying on a summary, check that its scope matches the work you intend to discuss. If your review concerns organization work, a record of personal repositories alone does not answer that question.

Keep repository access separate from permission to share. A private PR that you can read is not automatically suitable for a résumé, interview handout, or public portfolio. Follow the rules that apply to the source material and write a non-confidential explanation where needed.

Does a merged-PR summary show all my GitHub activity?

A 12-month merged-PR summary shows merged pull request history within its selected scope, not every kind of GitHub contribution. Keep code reviews, issue discussions, and other work separate unless you have the appropriate evidence for those activities.

This matters when your responsibilities extend beyond implementation. A developer who spends time reviewing changes should not describe a merged-PR list as the complete account of that work. Add a separate section with relevant records rather than stretching the meaning of the PR summary.

The same rule applies outside GitHub. Planning, incident coordination, mentoring, and other responsibilities need their own supporting material if they belong in your review.

Should I include every merged PR in my performance review?

A 1-year performance review does not need a separate achievement statement for every merged PR. Keep the fuller record for reference, then select and group evidence that explains your responsibilities and contribution.

A practical document separates the narrative from the supporting list. Lead with the work a reviewer needs to understand, and keep PR references close enough that the evidence is easy to check.

Do not use merge count as a substitute for explanation. Personal delivery history, not a productivity score, is the useful framing: the record helps you recall and substantiate work without ranking people by how they split changes into PRs.

How do I write the review without overstating the evidence?

Use direct verbs and distinguish implementation from outcome. Describe what you changed, why the change was needed, and what evidence you have for the result.

A drafting structure you can reuse is:

• Problem: Explain the condition or task that prompted the work.
• Contribution: State your role and identify the relevant changes.
• Evidence: Attach permitted references that support the statement.
• Outcome: Describe the result only as far as your evidence supports it.

Avoid turning an intention into a measured result. If a PR was intended to simplify a workflow, say what was simplified; do not invent time savings. If a change addressed a defect, describe the defect and correction without adding an unsupported reliability figure.

For a 2026 job search, translate internal project language into terms an outside reader can understand. Explain the technical problem and your responsibility without relying on private names or assuming the interviewer can open the repository.

FAQ

One last thing

The most useful annual summary is not necessarily the longest PR list. It is the account whose claims a reader can understand and check.

Before you finish your 2026 summary, read each achievement without its PR references. Does the sentence explain the work on its own? Then check the references: do they support what the sentence actually says? Keep both tests, and remove claims that fail either one.

Related guides

• Tools to generate self-review summaries from GitHub PRs
• Brag documents for software engineers
• PR summary tools for performance reviews
• GitHub PR dashboard tools for solo developers