What syncs with GitHub

Short answer: Gitfence reads GitHub live and sends your allowed actions back through the Gitfence app. You see only the pull requests, issues and code your access allows. Hidden content is filtered out.

How fast changes arrive

Opening a pull request or issue reads GitHub live.
An open pull request page reads GitHub again every 30 seconds while the page is visible.
Webhooks usually update notifications and stored pull request details within seconds. Polling is a backup: it checks every 60 seconds when needed, with a five-minute safety net while webhooks are working.
A git fetch or clone updates Gitfence's private mirror from GitHub before serving your filtered view.

All text from GitHub is filtered for your access. Hidden lines and paths are replaced. Comments on hidden or types-only files are left out and only counted.

Pull requests

What	You see from GitHub	What you can do (and how it appears on GitHub)
Which pull requests	Your own pull requests. Also the team's open pull requests when every changed file is visible to you. If an admin allows partly hidden pull requests, those appear too, with hidden files only counted.	Push to `<name>/<branch>`. Gitfence opens the pull request through the Gitfence app, with the Gitfence checks and a risk label.
Merging	The merged state and merge box. The merge reaches your copy on the next fetch.	You cannot merge. A team member with GitHub access merges.
Conversation comments	Comments, including edits and deletions, filtered for your access.	Comment on an open pull request. The Gitfence app posts it, marked `<name> (via Gitfence)`.
Reviews	Review verdicts: approved, changes requested, reviewed or dismissed.	Choose Comment, Approve or Request changes. The Gitfence app posts a comment review marked `<name> (via Gitfence)`. It never counts as a GitHub approval. On your own pull request, you can only comment.
Line comments and replies	Review threads with their code context. Outdated threads are marked. Threads on hidden or types-only files are left out.	Comment on a changed line in a file you can read or edit, or reply to a visible thread. The Gitfence app posts it on the same line or thread, marked `<name> (via Gitfence)`.
Suggestions	A reviewer's suggested change, with the old and new lines. Suggestions on hidden or types-only files never appear.	On your own open pull request, choose Apply suggestion. Gitfence commits it to your branch with the same checks as a push. Then run `git pull`.
Resolved threads	Resolved threads are collapsed and say who resolved them.	On your own open pull request, resolve or unresolve any thread you can see. On someone else's, only threads you started. The Gitfence app makes the change on GitHub.
Reactions	Counts for each reaction on conversation and line comments.	Add a reaction to a visible comment. It is the Gitfence app's reaction on GitHub: one of each kind per comment across Gitfence members, and you cannot remove it.
Labels	Label names, filtered for your access.	On your own open pull request, choose from the repository's existing labels, except Gitfence's own labels. The Gitfence app updates them on GitHub, and Gitfence's own labels stay unchanged.
Assignees	The people assigned to the pull request.	On your own open pull request, choose only from people already on it: the author, current assignees, reviewers, requested reviewers and commenters. The Gitfence app updates the assignees on GitHub.
Review requests	People and teams in Review requested from. A request for you also asks you to review in Gitfence.	You cannot request reviewers. Gitfence can request CODEOWNERS when a change needs a human review.
Milestone	The milestone title, filtered for your access.	Read only in Gitfence.
Linked issues	Closes lists shared issues by number and title. Other linked issues are only counted, never named.	Read only in Gitfence.
Checks and CI	The latest check for each name and the latest commit status for each context. You see check names and summaries, not logs.	Gitfence posts its Gitfence and Gitfence review checks through the Gitfence app.
Mentions	A new mention of your GitHub login in a pull request description, comment or review can ask you to review and notify you, if you can see that pull request.	Mentions you write are posted as text in the Gitfence app's comment.

Issues

What	You see from GitHub	What you can do (and how it appears on GitHub)
Which issues	Only issues your admin shares: none, issues with a chosen label (by default `gitfence`), or all issues. Pull requests are not issues. An unshared issue looks the same as a missing one.	Ask your admin to change which issues are shared.
Open an issue	Shared issues are listed and read live, with their text filtered.	Open an issue through Gitfence. The Gitfence app opens it, adding the sharing label when label sharing is used, with a body marked `<name> (via Gitfence)`.
Comments and reactions	The filtered conversation and reaction counts on comments.	Comment on a shared issue; the Gitfence app posts it as `<name> (via Gitfence)`. You can also add a reaction to a comment as the Gitfence app's reaction.
Closing	Open or closed state.	You cannot close an issue through Gitfence.
Labels and assignees	Labels, filtered for your access.	You cannot set labels or assignees on issues through Gitfence.

Code (git)

What	You see from GitHub	What you can do (and how it appears on GitHub)
Commits	Every branch's history, rewritten without hidden files. Types-only files contain declarations or stubs. New GitHub commits reach your view on a fetch, webhook or poll.	Push with plain git. Gitfence checks access and secrets, keeps hidden files untouched, and pushes one atomic update through the Gitfence app. Merge commits are refused; rebase instead.
Branches	All branches, filtered for your access.	Push only to `<name>/...`, never to a protected branch. Gitfence opens a pull request for your branch. A branch changed outside Gitfence fails the Gitfence check.
Tags	Tags are not served in your view.	Tag pushes are refused. Only branches can be pushed.

What doesn't sync

Editing or deleting your own comments through Gitfence. These actions are not available because the comment belongs to the Gitfence app on GitHub. Edits and deletions made on GitHub still appear in Gitfence.
Reactions in your own name. GitHub records the Gitfence app's reaction, not yours. All Gitfence members together get one reaction of each kind per comment, and members cannot remove one.
GitHub approvals. Your approval is deliberately a comment review. An app approval must not count toward branch protection for someone who is not a GitHub reviewer.
Requesting reviewers, setting milestones, changing issue labels or assignees, and closing issues. These actions are not available to members.
Deletion notifications with polling only. Without webhooks, a deleted comment disappears on the next read, but the deletion does not produce a notification.
Immediate background updates for resolved threads on some installations. The Gitfence app must be subscribed to review-thread events. An admin may need to enable this for an existing installation. Resolution still appears whenever Gitfence reads the pull request.
Review threads and linked issues on some GitHub Enterprise Server installations. If the server does not support review threads, both are left out. Other pull request details still appear.
Some suggestions. A suggestion spanning a deleted line or referring to the old side of a diff cannot be applied. GitHub has the same restriction.

Next: Reviewing a pull request and AI agents and MCP.