Can Pull Tally show pull request trends over multiple months?

Yes. Pull Tally lets you browse and summarize merged GitHub pull requests by month, so you can compare monthly delivery history across a review period. Keep the organization or personal repository scope consistent, and treat the comparison as a record of merged work—not a productivity score. Monthly summaries alone do not explain changes in workload, project difficulty, or impact.

Can Pull Tally show pull request trends over multiple months?

Yes—by comparing merged pull request history month by month. The useful distinction is between seeing which work merged during each month and explaining why the monthly record changed. The first comes from the history; the second requires your context.

For an occasional lookup, GitHub search is a direct way to find merged pull requests. For repeated monthly browsing, Pull Tally provides a month-based way to review that history without repeatedly reconstructing the same searches.

Neither approach makes a merged-PR count a measure of individual effectiveness. Use the count to locate work, then inspect the relevant changes before writing a review statement.

Why this matters

A performance review asks what you contributed across a period, not just what you remember from the last busy week. Monthly browsing gives you a repeatable route back to completed changes. It also helps you separate ongoing work from work that actually merged during the period you are describing.

For a job search, the same history serves a different purpose: finding examples you can discuss without exposing confidential information. You are looking for evidence of your decisions and contributions, not a total that needs to impress a recruiter.

Consider a review covering January through March 2026. Comparing those 3 months gives you a structure for reconstructing the period. It does not establish that the month with the most merged pull requests contained the most valuable work.

How do you compare monthly merged pull request history?

Use the same sequence each time you prepare a review. The goal is a comparison you can explain later, with a clear time period and a stable repository scope.

1. Choose months

Choose the months that match your review or job-search preparation. For a January–March 2026 review, examine January, February, and March separately before writing a summary of the whole period.

Keep the comparison at 1 month per interval. Comparing a full month with part of another month answers a different question, so label an incomplete month explicitly rather than treating it as equivalent.

If your review covers 6 months, follow the same process across all six. Do not shorten the window simply because the most recent work is easier to remember.

2. Fix scope

Decide whether you are reviewing an organization's repositories or a personal repository. Keep that scope consistent across the selected months. Otherwise, a difference in the tally can reflect a different collection of repositories rather than a change in your activity.

For example, a personal project and an employer's repository belong to different contexts. You can discuss both in a career document, but label them separately so the reader understands what each summary covers.

3. Browse merges

Browse the merged pull requests for each selected month. Use the merged history to recover the work itself rather than relying on memory or treating every title as a finished review bullet.

A pull request title is a starting point. Read enough of the underlying change to explain your contribution accurately, especially when the title uses internal shorthand that will not make sense outside the repository.

4. Add context

Write a short note beside the work you intend to discuss. Describe the problem, your contribution, and the result you can substantiate. Keep outcomes separate from assumptions: a merged change establishes that the change merged, not that it produced a particular business result.

For a February 2026 entry, for example, record what changed and why it mattered to the project. Add an outcome only when you have evidence for it.

5. Write summary

Group related changes into a contribution narrative. Several pull requests can belong to the same piece of work, so avoid turning every merge into a separate achievement merely to make the list longer.

Write about the contribution first; use the monthly history as supporting evidence. This keeps the final review readable and prevents a useful retrieval tool from becoming a scorecard.

Why monthly pull request comparisons vary

A monthly tally answers a narrow question: which pull requests merged within the selected month and scope? Before interpreting a difference, check the boundaries and the underlying work.

• Month boundaries: A pull request belongs to its merge period, which is not necessarily the period when you began working on it.
• Repository scope: Comparing an organization-wide selection with a personal repository changes what the tally includes.
• Merge status: Work that has not merged is outside a merged-PR summary, even when you have spent substantial effort on it.
• Change grouping: Separate pull requests can represent parts of the same contribution. Read them together before writing separate achievement claims.
• Contribution type: Reviews, design discussions, investigation, and other work do not become your merged pull requests simply because you contributed effort.

These checks do not explain every change in a monthly total. They establish what the record includes and what additional context you need.

For a March 2026 review, do not turn a difference from February into a claim about improvement or decline without examining the work. The tally is evidence of merge activity, not a conclusion about performance.

Can I use monthly PR history in a performance review?

Monthly PR history is useful for finding review evidence. Start with the period your review covers, then select contributions that show what you changed, decided, or completed. You do not need to include every merge in the finished document.

A practical review note contains these elements:

• Problem: What needed to change?
• Contribution: What did you personally implement or help decide?
• Evidence: Which merged changes support the description?
• Outcome: What result can you substantiate?

Keep the distinction between contribution and outcome. Implementing a change and demonstrating its effect are different claims. If you cannot support an outcome, describe the completed work precisely rather than attaching an invented percentage or business benefit.

For a 2026 self-review, use the monthly record to check your memory before drafting. Then organize the final text around meaningful work rather than forcing the reader through a chronological list of pull request titles.

The limitation remains important: a review built only from your merged pull requests leaves out contributions that do not appear in that history. Add those separately, with their own evidence.

Can I use monthly PR history for a job search?

Monthly PR history is useful for recovering interview examples. Browse the relevant months, identify work you understand well, and prepare an explanation of the problem, your role, and the decisions involved.

Do not copy private repository details into a public résumé or portfolio. Access to work history does not grant permission to publish employer code, internal titles, customer information, or confidential project context.

Instead, turn the underlying experience into an appropriate description. Explain the type of problem and your contribution at a level you are authorized to share. Keep private evidence private.

A job-search summary also needs selection. A complete merge history is a reference, not a résumé: choose examples that match the role and that you can discuss accurately under follow-up questions.

What permissions does monthly browsing involve?

Pull Tally uses read-only access to pull request metadata to support browsing and summarizing merged history. Signing in alone does not connect private organization repositories. Treat account sign-in and private organization access as separate questions when deciding what to connect.

Read-only describes the access involved; it does not mean repository metadata is public. Titles and descriptions can contain internal context, so handle information from private repositories according to your organization's rules.

Before connecting organization repositories, check the access request and your organization's authorization requirements. Do not assume that successful sign-in means all of your employer's repositories are connected or should be connected.

The practical benefit is focused: retrieving merged-PR history for your own review. You still decide which information belongs in a private performance review and which information is appropriate for a job application.

How should I describe a trend without overstating it?

Describe the observation before interpreting it. A month-by-month comparison can show where merged work falls across the selected period; your explanation should identify the scope and the work behind that pattern.

For a January–March 2026 comparison, state that the summary covers those months and the selected organization or personal repository. Then describe the contributions you found. Do not present the record as all work completed during the quarter.

Prefer statements about identifiable work over statements about personal worth or speed. A useful summary explains what you delivered and why it mattered, while keeping unsupported conclusions out of the document.

A merged-PR tally is a retrieval aid, not a productivity score. That distinction makes the history more useful: you can use it to recover evidence without asking it to measure work it does not contain.

FAQ

One last thing

Before writing a review bullet, ask whether you are describing a merge, a contribution, or an outcome. Those are different claims, and only the first follows directly from a merged-PR record.

Pull Tally is best for individual developers who need to revisit monthly merged-PR history without repeating manual GitHub searches. Use it to recover the evidence; write the explanation from what you can substantiate.

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