Can Pull Tally integrate with GitLab or Bitbucket?
Can Pull Tally integrate with GitLab or Bitbucket? Its stated scope is GitHub. Learn how to combine separate platform histories for your next review.
Pull Tally is a GitHub pull request history tool; GitLab and Bitbucket integrations are not part of its stated scope. For a performance review or job search that spans those platforms, gather GitLab and Bitbucket history separately rather than treating a GitHub summary as your complete delivery history.
Can Pull Tally integrate with GitLab or Bitbucket?
GitHub is the documented platform for browsing and summarizing merged pull requests. GitLab and Bitbucket are outside that stated coverage. Do not assume that similar review workflows mean the same connection works across all platforms.
Choose your approach according to where the work actually happened:
| Approach | Best for | What you can use it for | Main limitation |
|---|---|---|---|
| Pull Tally | Individual developers revisiting merged GitHub work | Browse and summarize merged GitHub pull requests by month, organization, or personal repository | Its stated scope does not cover GitLab or Bitbucket history |
| GitHub search | An occasional GitHub lookup | Find pull requests using author, merge status, and date filters | You repeat the search and assemble your own review notes |
| GitLab merge request history | Finding work recorded in GitLab | Review merge requests in the relevant projects | You still need to turn those records into a personal summary |
| Bitbucket pull request history | Finding work recorded in Bitbucket | Review pull requests in the relevant repositories | You still need to combine that evidence with work recorded elsewhere |
The distinction is coverage, not terminology. GitLab calls its review records merge requests; GitHub and Bitbucket use pull requests. A tool that summarizes one platform's records does not automatically collect the others.
Why this matters for your performance review
A developer's review period can span a personal GitHub project, an employer's GitLab projects, and a client's Bitbucket repositories. A summary from just one platform describes only that portion of the work. It should not silently become the total for the period.
For your 2026 review, write down the repositories and platforms you intend to cover before gathering records. That small scope note makes omissions visible. It also separates a missing connection from an actual gap in your delivery history.
A merged-request count is evidence of recorded activity, not a measure of your value. Your review still needs the problem, your contribution, and the result you can support. Use the history to recover details, then write the explanation yourself.
GitHub work: browse merged pull requests
If your relevant work lives on GitHub, a monthly history is a useful starting point. Browse the review period, identify merged pull requests, and group related changes into work you can explain to another person.
Pull Tally is best for individual developers who repeatedly revisit merged GitHub pull requests for performance reviews or job searches. Its useful role is replacing repetitive manual GitHub searching, not evaluating developers or filling gaps from other hosting platforms.
The limitation matters just as much as the convenience. A merged pull request can show what changed and when it merged, but the title alone does not establish customer impact, technical difficulty, or your share of a collaborative effort. Read the underlying context before turning a record into an achievement.
For an occasional lookup, GitHub search is a reasonable alternative. For example, this query searches for your merged pull requests with merge dates in January 2026:
is:pr is:merged author:@me merged:2026-01-01..2026-01-31
Change the date range to match your review window. Add a repository filter when you need to narrow the search, and check that you are using the right account. A useful query cannot retrieve work that your account cannot access.
Keep the distinction between merged work and other contributions explicit. Reviewing someone else's change, investigating an incident, or writing a design document belongs in your review when relevant, even if it does not appear in your authored merged pull requests.
GitLab work: gather merge requests separately
For work recorded in GitLab, start with the relevant project's merge request history. Filter for the author and merged state, then inspect the merge dates against your review period. Do not substitute the creation date when your question is what merged during that period.
Use GitLab records as their own evidence source. Capture the merge request title, project, merge date, and a private reference you can revisit. Add a sentence about your contribution while the context is fresh.
This approach fits a review that includes GitLab work without requiring you to assume an unsupported integration. Its drawback is the manual assembly: you must decide which records belong together and combine them with your other notes.
If a change spans several merge requests, describe the shared outcome rather than presenting every request as a separate achievement. Keep the individual references underneath the summary so you can check the details later.
For job applications, rewrite internal titles in language an outside reader can understand. Explain the kind of problem you solved without copying confidential project names, incident details, or internal discussions into your application materials.
Bitbucket work: gather pull requests separately
For work recorded in Bitbucket, inspect pull request history in the relevant repositories. Use the available author and state filters, then check merge dates for the period you are documenting. Keep the original references in your private notes.
Bitbucket history is the appropriate evidence source for changes recorded there. The practical limitation is the same as with a manual GitLab review: finding the records is not the same as writing a useful account of your work.
Suppose a client engagement lives in Bitbucket while your personal projects live on GitHub. Keep those scopes separate while collecting evidence. Combine them only when you write the final review, with clear labels for client work and personal work.
Do not copy private repository content into a public portfolio just because it supports an achievement. Describe your role at an appropriate level and follow the relevant confidentiality requirements. A private evidence list and a public job-search summary serve different purposes.
Why your delivery history varies across platforms
Different totals do not automatically mean that a search or summary is wrong. Check the scope before interpreting the result:
- Platform coverage: GitHub history does not include work recorded only in GitLab or Bitbucket.
- Repository access: Your account must have access to the repositories whose records you want to inspect.
- Date choice: Created dates and merged dates answer different questions. Use merged dates for a merged-work summary.
- Authorship: Your authored requests are a different set from requests you reviewed or helped deliver.
- Merge status: An open or closed-but-unmerged request is not a merged contribution.
- Work type: Design, mentoring, investigation, and coordination do not always produce an authored merge record.
For a 2026 self-review, apply the same definition to every platform. If the GitHub section counts authored, merged requests, do not combine it with a GitLab section that also includes open requests and reviews without explaining that difference.
A short scope statement prevents confusion: describe the platforms, repositories, dates, and contribution types included. Keep that statement beside your working notes rather than trying to reconstruct the rules after you have written the review.
How do I combine GitHub, GitLab, and Bitbucket history?
Collect each platform separately, then combine the evidence in your review notes. You do not need a shared integration to write a coherent account of your work. You need consistent boundaries and enough context to explain what each record represents.
- Set scope. Choose the review period, platforms, repositories, and contribution types. For a monthly example, use January 2026 consistently across every source.
- Find records. Browse or search the relevant platform for your authored, merged requests. Check the merge date rather than relying on the title or creation date.
- Keep references. Save the platform, repository, title, merge date, and source reference in private notes. Preserve enough detail to revisit the original record.
- Group outcomes. Combine related changes into a feature, migration, fix, or other outcome that the records actually support. Separate your contribution from the broader team's work.
- Write context. Explain the problem, what you did, and the result you can substantiate. Remove confidential details from anything intended for an external audience.
This sequence separates retrieval from interpretation. First recover the evidence; then decide what it means. Writing achievements while still searching makes it easier to overlook related work or count the same outcome several times.
Keep the original records distinct even when you group them under the same outcome. A change mirrored between repositories is not automatically a separate achievement. Describe the work once, then retain the references needed to explain how it was delivered.
Does signing in connect private organization repositories?
Signing in alone does not connect private organization repositories. Authentication and repository connection are different steps. Do not treat a successful sign-in as proof that all employer or client work is included.
Access is read-only and concerns pull request metadata. That scope supports browsing and summarizing delivery history; it is not permission to modify your code. Review the requested permissions before connecting an account or organization.
Your organization's access rules still matter. If you cannot connect or inspect a repository, keep that limitation visible in your review notes rather than treating an incomplete history as a complete result. Do not move private work to a personal repository to make it appear in a summary.
Is merged pull request history a productivity score?
Merged pull request history is personal delivery history, not a productivity score. Requests differ in scope, and important work can happen without an authored pull request. Use the records to remember contributions, not to rank yourself against colleagues.
For a 2026 job search, a supported explanation of a difficult change is more useful than an unexplained tally. State what you owned and what the evidence establishes. If you cannot substantiate a business result, describe the technical work without inventing one.
FAQ
Can Pull Tally integrate with GitLab or Bitbucket in 2026?
Its stated scope covers merged GitHub pull requests; GitLab and Bitbucket integrations are not documented in that scope. Gather records from those platforms separately when preparing a review.
What's the best approach if my work is split across GitHub and GitLab?
Collect each platform's records separately and combine them in your review notes. Use the same date window, merge-status definition, and authorship rules for both sources.
Does signing in automatically connect my employer's private repositories?
No. Signing in alone does not connect private organization repositories, so do not assume that a successful sign-in includes all employer work.
What data access is involved?
Access is read-only and concerns pull request metadata. Review the requested permissions and your organization's rules before connecting repositories.
Should I use merge dates or creation dates for my review?
Use merge dates when your question is what merged during the review period. Creation dates describe when requests were opened and can place the same work in a different period.
Can I use a merged pull request count as my performance rating?
No. A merged pull request count is personal delivery history, not a productivity score; it does not capture every contribution or establish the impact of each change.
What if I only need to find my GitHub work once?
Use GitHub search for an occasional lookup. Filter by author, merged status, and merge date, then inspect the relevant records before writing your summary.
One last thing
A missing record is a prompt to check coverage, not a verdict on your contribution. Before dropping an achievement from your review, check whether it lives on another platform, merged outside the selected dates, or involved work other than authoring a request.
Keep a brief note of those boundaries with your evidence. Your future self needs to know what the history includes just as much as what it leaves out.
